Formalized Blazor Wasm Capacitor/Cordova Support

[jhancock4d]

Is your feature request related to a problem? Please describe.

Right now Blazor WASM is difficult to get working in Capacitor/cordova so using Blazor to create a cross platform environment including web is almost impossible. It would be nice if the Blazor team wored with the Capacitor team to create a great story in the short term while we away MAUI etc. as this would create a viable bridge without having to use Xamarin Forms.

Describe the solution you'd like

I'd like the Blazor team to work with the Capacitor team on the following Make Capacitor work with Blazor

In a perfect world, this would also add the Xamarin emulator support directly into the Visual Studio pipeline for cordova and capacitor so that we could debug iOS against simulators on Windows Visual Studio and android as well but that would be a stretch goal.

Additional context

This is really close to working with a lot of hacking as it is right now. Authentication is the biggest hurdle to overcome. It would be great if the authentication system could "just work" in Capacitor/cordova and be extended so that it would work on web, and within capacitor automatically and then have at least formalized documentation on docs.microsoft.com for how to make this all work. Otherwise there are minor issues with Electron under Capacitor but nothing too huge and javascript interop for native device support is difficult which would be nice to wrap in a bow as a nuget package that makes all of the capacitor plugins functionality available in Blazor but that would be a stretch goal too.

[javiercn]

@jhancock4d thanks for contacting us.

While this sounds interesting we are currently focused on delivering a web experience, so this is not something that we plan to do in the immediate future.

From what I can tell based on your comment here and the issue you described, you got everything to work but for the authentication bits.

If you are interested in supporting this scenario for your apps (and maybe offer it to others) you could consider creating your own package to add support for it. From what I can tell you need to disable a couple of things from the build pipeline (which should be easy to do putting your own propsfile in a nuget package), call some command as part of publish (which you can do by adding a target file in a nuget package) and maybe modifying some paths in blazor.boot.json and moving some files to avoid "_". All of which you can already do through MSBuild extensibility today (although not straightforward).

With regards to authentication, our current support is designed for Web environments and we are unlikely to change that. If you can't make it work, you can replace the AuthenticationService.js on the index.html with your own version to support this scenario. You might be able to leverage oidcclient to that effect.

I hope you understand that we already have a pretty big backlog and that our focus for this release is on making Blazor a great platform for web development and we don't have the resources necessary to pursue other integrations.

[jhancock4d]

The issue for authentication (the #1 roadblock) is that capacitor has an event for when a custom url is called back from the idp for the redirect_uri.

I can get that to fire, and can even bind it in blazor, however what I can't do is convince the authentication pipeline in blazor wasm (which I have working fine in standard blazor) to then handle that custom url (which has all of the same stuff on the URL as the standard blazor wasm would get back).

So if someone could tell me how to tell the blazor authentication library to handle the return_url by hand, then I could work around that and get this going at least has a hack. (it would obviously be far better if you guys made it work because you would then have a complete cross platform story with a single code base instead of having xamarin bindings and completely separate code from web. Even a single developer with knowledge into the guts of Blazor probably could make this work in a few days.

[javiercn]

You can try and replace the JS code for handling auth with your own version here. You could store the URL you have, redirect to authentication/login-callback and have your implementation in JS process that stored custom url and complete the authentication flow.

[jhancock4d]

@javiercn Ok, so I was able to intercept the calls and redirect them in and get it to authenticate.

But there is a REALLY long delay until it's ready for authentication.

I'm seeing in the logs the following:

com.store.app://localhost/authentication/login-callback?error=login_required&...(state and stuff)

Now if I just redirect it to /authentication/login-callback?error=login_required the app goes into an endless loop on start up. Does the authentication system need this error and how do I get it to stop doing an endless loop?

On web, the delay isn't short either (shows authorizing for quite a while before the page loads fully when it should be pulling it from localstorage and immediately returning, some with checking authorization state). Is this a known issue?

[javiercn]

@jhancock4d the code in the library is optimized for Web scenarios, I can't tell what can be going on with Capacitor/Cordoba.

Silent sign-in is meant to authenticate the user without requiring interaction and to renew the access token, if you are willing to live without that, you can remove them.

I suggest you don't try and reuse the AuthenticationService.ts as it is because it is optimized for web scenarios, so I don't expect to work smoothly in other areas.

[javiercn]

We've moved this issue to the Backlog milestone. This means that it is not going to happen for the coming release. We will reassess the backlog following the current release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources.

[JohnGalt1717]

Any updates on this?

[javiercn]

We don't have any updates at the time. This is not a current focus for the team in the short term.

[LukeTOBrien]

Hello,

I am also interested in packaging my web app using Cordova.
I have searched on the internet and I have found some solutions, but all require hacks and are pre-.Net 5 of course.

What is needed I think is a section on your Host and Deploy documentation (or perhaps a another doc page), similar for the section on Github Pages you could have another section for Cordova.

What do you think?

[sorainnosia]

I have made a repository for enabling Blazor on Cordova platform, visit this https://github.com/sorainnosia/CordovaMudBlazor

[danroth27]

We don't have any immediate plans to further enable Blazor WebAssembly in Capacitor/Cordova. Instead we are executing on integrating Blazor directly into native apps with .NET MAUI. Since we don't expect to carry forward this issue, I'm going to go ahead and close it.

[sorainnosia]

@danroth27, the problem with .NET MAUI is that it is only for mobile apps and not web. The .NET MAUI might use native mobile components mix with web based component and so it is not able to support web, however people such as me is trying not to do another development specifically for mobile and able to turn Blazor web into mobile app with careful responsive design. Progressive Web App is good but it will become even better with native mobile capabilities such as when coupling with cordova. So please reconsider this, such as time spent on developing on two platforms.

[danroth27]

Hi @sorainnosia. You can reuse your entire Blazor web app implementation in a .NET MAUI Blazor app. That's what I do in the https://github.com/danroth27/BlazorWeather app. All of the Blazor web UI components are in a single common library that is used by both a .NET MAUI Blazor app and a Blazor Server web app (Blazor WebAssembly would work too). The HTML, CSS, and Blazor rendering logic is exactly the same.

The benefit of the .NET MAUI Blazor setup over using Blazor WebAssembly with Capacitor or Cordova, is that your components run directly in the .NET process on the device instead of on WebAssembly. This means your Blazor code runs fast and has full access to the native capabilities of the device through .NET platform APIs. No need to punch out of the browser sandbox.

I hope this resolves your concerns, but please let me know if I've misunderstood them.

[JohnGalt1717]

@sorainnosia @danroth27 All of this goes to the core problem with .NET and all of these insane implementations all over the place instead of a cohesive package.

You're losing because Flutter has one language, one layout engine, and consistent rendering across all platforms which minimizes testing.

IE what Uno does, but doesn't have enough support (i.e. buy them) from Microsoft to create a stable, consistent product.

Adding Blazor to Xamarin Forms/Maui (which is now late by 5 months), is a hack on top of a hack. I'm at a loss as to why anyone would seriously recommend it for any project. (and if they ever did, it would be a good indicator to me that they should not be in an architect role)

There is endless evidence if Microsoft wants to listen, from developers, The Windows ecosystem that is legacy apps dying by attrition and being replaced by PWAs which provide no value prop for Windows, all of which is harming the Windows platform, to even eventually Azure as .NET's market share shrinks and shrinks and a major driver of Azure dries up and makes it identical to AWS and everyone else. Even your Office team has dumped .NET and uses React (As does VS Code!) specifically because of your failures here.

We've abandoned all .NET on client side specifically because .NET and the .NET team continue to fail to recognize that MAUI is a mess and just a rebuild of Xamarin Forms with no new real fundamental abilities that allow it to compete with Flutter, AND uses its own bastardized dialect of XAML itself a relic of the past that the world has changed to code defined UI.

We didn't want to do this, but you forced us to specifically because you (as in all of Microsoft.) refuse to see reality and declare the emergency that this now is (you had time 4 years ago when people started complaining, now you've hit the iceberg and you need to start welding or the ship is going to sink).

I strongly suspect that Steve Sanderson was trying to tell you this 3 years ago when he did the demo of blazor running on the flutter engine which has since been disappeared because of what it represents. I strongly suggest you start listening to him and everyone else and come up with a plan, and intelligently communicate it at Ignite and the .net conference when .NET 6 is released as a looking forward session to what you're committing to for .NET 7 (i.e. 6 platform pixel perfect rendering using code first instead of XAML with plugins for all root capabilities across all platforms (geo location, video playback, sensors, device info etc.) And if you were wise you'd be giving away iOS simulator and build time on Azure for all VS.net subscription holders so that they don't need to own a Mac.

I really hope that what I'm saying to you isn't a surprise. If it is, then the problem internally is way worse than I imagined. So the only question is, are you (Microsoft) finally admit you have a problem, and build the flutter competitor that out flutters, flutter, or if you're going to continue to ignore the problem while the .NET ship sinks into server only oblivion and with it, all mass appeal because small and medium teams don't have the budget to have developers that are specialized in a single part of the stack so you're losing 60% of the market as a result even on server.

[danroth27]

Hi @JohnGalt1717. I appreciate the feedback and I sympathize with your frustration. It's been a long journey evolving .NET to run cross-platform, and support for cross-platform UI has been limited. I think .NET MAUI, however, does address the concerns you are raising. I welcome your thoughts on how we can make it better!

You're losing because Flutter has one language, one layout engine, and consistent rendering across all platforms which minimizes testing.

Flutter is a great offering, and I think their growth is well deserved. Having one way to do certain things is simplifying and convenient for many scenarios. But it's also limiting. Flutter doesn't make it easy to use the native UI capabilities of the device, and favors its own rendering. This makes it difficult to leverage specific platform investments.

.NET MAUI on the other hand is all about giving you full access to the device's capabilities, so you can use whatever native platform UI controls you want. But .NET MAUI isn't stopping there. .NET MAUI is also working on cross-platform drawing capabilities and custom drawn UI controls. So with .NET MAUI you will be able to have pixel-perfect consistency and be able to use any native UI controls you want. No need to sacrifice one for the other.

If you're a web developer, you can also take advantage of .NET MAUI using Blazor. .NET MAUI Blazor apps let you reuse your Blazor web UI components in .NET MAUI apps so that you can reuse the same web based UI across mobile, desktop and web. No need to learn XAML if your skills are with HTML and CSS. But you're still free to add native controls alongside you're web-based UI.

For XAML devs that want to take their apps to the web, we have the option of adding support to .NET MAUI of targeting the web directly, just like you can target mobile and desktop. The web is just one of the additional platforms that we're considering adding support for to .NET MAUI in the future, along with Linux and others. We'll work with the .NET community to figure out which additional platforms are most important to tackle first after we get the first set of platforms done (Windows, macOS, Android, and iOS).

That all said, I don't think competing with Flutter is really the goal. Having multiple development platform options is good for developers. It's good to learn from other developer platform offerings, but our focus should be on delivering the best cross-platform UI story with .NET that we can so that software development is easier and more productive for everyone.

code first instead of XAML with plugins for all root capabilities across all platforms

We support XAML in .NET MAUI because that's what our existing users are using and we wanted to enable them to use .NET MAUI. But we agree that a code-first model would likely have broader appeal. We've already started experimenting with code-first models for .NET MAUI with Comet and I expect we'll add something along these lines to the platform.

as .NET's market share shrinks and shrinks...

I have to disagree with you here! .NET is a rapidly growing developer ecosystem now with over 5M devs. You can build pretty much any kind of software with .NET, and we continue to expand its platform capabilities, including investing in cross-platform UI with .NET MAUI. It's a great time to be a .NET dev! :smile:

[sorainnosia]

@danroth27 I think Microsoft is trying to be vague and allow developers to be creative and giving the option to developers to create their own design philosophy/principle that is not much available on Flutter that sticks to its rendering. It sounds great for big players with resources available to invest on their own custom controls/components but leaving out small developers whom needs an easy to use and readily available components with minimum design changes.

This is good because there are many community efforts is publishing their free open source components and allow small players to use them for free ever since Blazor is out. But there are things developers want such as Native AOT compilation of .NET executable (not wasm) for entire program but it seems currently even with option to publish into native x86/x64, only the startup of program is Native AOT and not the loaded DLLs, and there are still some IL here and there (correct me if I am wrong).

From my opinion, Microsoft is now listening more to the developers and gaining more developers into it's platform, this has been very positive especially with Blazor gaining popularities. It will be more convincing and firm when Microsoft publishes its own design philosophy components (maybe FluentUI) for Blazor/MAUI which will give developer confidence that their app design comes straight out from a firm standard.

[sorainnosia]

Hi @sorainnosia. You can reuse your entire Blazor web app implementation in a .NET MAUI Blazor app. That's what I do in the https://github.com/danroth27/BlazorWeather app. All of the Blazor web UI components are in a single common library that is used by both a .NET MAUI Blazor app and a Blazor Server web app (Blazor WebAssembly would work too). The HTML, CSS, and Blazor rendering logic is exactly the same.

The benefit of the .NET MAUI Blazor setup over using Blazor WebAssembly with Capacitor or Cordova, is that your components run directly in the .NET process on the device instead of on WebAssembly. This means your Blazor code runs fast and has full access to the native capabilities of the device through .NET platform APIs. No need to punch out of the browser sandbox.

I hope this resolves your concerns, but please let me know if I've misunderstood them.

Glad to know this, thanks

[JohnGalt1717]

@danroth27 Great marketing talking points that form an excuse.

The fact remains that Xamarin Forms is in the low 100s of thousands of apps in the stores over its entire lifetime of 10+ years.

Flutter, in less than 4 years and only 1 on web has over 2 MILLION apps in the stores and as many active websites as all of asp.net core does.

"We support XAML in .NET MAUI because that's what our existing users are using and we wanted to enable them to use .NET MAUI. But we agree that a code-first model would likely have broader appeal. We've already started experimenting with code-first models for .NET MAUI with Comet and I expect we'll add something along these lines to the platform."

Meanwhile you're building WinUI which is a different thing with a different dialect. If you really wanted to serve customers while maintaining backwards compatibility (and really, Silverlight, WPF, UWP, Win UI itself amongst countless others shows that Microsoft doesn't care about backwards compatibility and is happy to reinvent the wheel every few years), you'd have a WPF to WinUI converter and a Xamarin Forms to WinUI converter and everything being done on Maui would be about getting WinUI XAML syntax and WinUI itself rendering properly and natively on MAUI. It wouldn't be about iterating on James Montenegro's personal pet project Frankenstein.

"I have to disagree with you here! .NET is a rapidly growing developer ecosystem now with over 5M devs. You can build pretty much any kind of software with .NET, and we continue to expand its platform capabilities, including investing in cross-platform UI with .NET MAUI. It's a great time to be a .NET dev! 😄"

You're growing slightly and only on server side and only from the depths of the disaster of ignoring Linus for a decade and not making .NET run on Linux. Your actual user base according to all metrics shows that there is less than 1/5th the developers on .NET that there was 15 years ago.

It isn't a great time to be a .NET dev because small and medium sized teams have to maintain Blazor code for web, Android/iOS code (no your Frankenstein solution isn't going to fly for anyone sane), WinUI (because MAUI even when it finally comes out will still have the same problem of lack of 3rd party support for Windows, and Linux. Which is exactly why the Office team doesn't even believe you and the data shows conclusively that no one else does either. You're listening to internal IT people in enterprises that are not your customers. End users producing things in profit centers are your customers. IT departments are obsticles to selling to those people that you have to win over, nothing more. They harm your ability to innovate and respond to the market. Chrome is THE example of this. The IT people you were listening to demanded that IE development slow down, and be serviced in windows with no new versions outside of Windows versions. You listented to them. Chrome didn't. In fact they told the IT departments to go pound salt and subverted their wishes and allowed end users to install Chrome and avoid the IT staff. They intentionally put Chrome into places on windows where even non-admins on machines could install it. It was a willful subversion. It wasn't by accident. Guess what? Because they innovated and gave the actual customers what they wanted, they won, and the IT departments went along with it, which is why now the joke is that IE/Edge is used once on most machines to download Chrome. Only when Joe Belfiore figured out what had happened and through some sheer force of will convinced people to go to the Chromium engine and the Chromium servicing model did it turn around IE/Edge's Collapse. .NET's, especially on client side IS EXACTLY THE SAME PATH and I'm asking you to stop repeating marketing slogans designed to appeal to IT staff in your enterprise customers and recognize exactly where IE/Edge would have ended if Joe Belfiore hadn't won that battle.

Meanwhile there is virtually no new native app development for windows (Xamarin Forms, UWP, WPF, WinForms, and WinUI combined) occurring. Old apps are being maintained and slightly updated, and a very few applications that have-to-have hardware and software deep linking is all you've got. Even the vast majority of Microsoft itself is gone. And even the deep integrations to hardware are now done on iOS and Android. Look at Ubiquiti gear as an example: You have to use iOS or Android to setup most of their stuff. You can't do it on windows, and because the web browser doesn't support mDNS you can't do it there at all, so you can't do it on windows. I can name 100+ products that you can't setup or manage on Windows specifically because Microsoft is even losing that reason for existence.

This is conclusive proof that the entire rest of your argument is wrong. You and the marketing team can spin this however you want but the reality is that .NET usage for web servers is down from 28% 10 years ago to 2.8% now according to StackOverflow and several other companies that track this. Windows is dead on mobile and even the Surface Duo is a niche of a niche product because developers don't care about Microsoft's offerings AND just as importantly, they have to run Macs to build iOS which actually makes them money, so windows is largely irrelevant to them.

The position about apps looking like the platform is obviously false. Look at the top 100 apps in both the Google and iOS stores. Tell me if ANY of them actually don't look virtually identical between platforms. Why? Because companies value THEIR BRAND, not Google and Apple's. Look at Outlook, Word, Excel etc. on iOS and Android. They are virtually identical. No one cares about platform specific anymore. That's a crossed bridge and no one is looking back.

And, because you fail to see these realities, and have yet another rebuild of Xamarin Forms with no new functionality, itself with Windows support that is DOA on every attempt because no one cares and doesn't build plugins for it, .NET itself is dying and it's killing Windows with it.

(And seriously, the VAST MAJORITY of developers HATE XAML. With a passion. It's HTML done badly with horrific usability, awful binding syntax and compiles to C# code anyhow which it very often gets wrong. The only reason why anyone uses XAML is because they have legacy code and you haven't provided them with a conversion tool that will get them away from XAML so they have no choice.)

But you raise excellent other issues about Flutter that gives Microsoft a MASSIVE competitive advantage if you built it right:

1. Xamarin lets you write cross platform low level code to each platform meaning you don't need to know that platform's language of choice.
2. Xamarin lets you deploy with a few clicks directly from Visual Studio without hassle.
3. Xamarin lets you dev on windows for iOS through the emulator bridge.

So USE THAT:

1. Adopt the flutter rendering engine just like Edge adopted Chromium. (you very likely don't have time to create your own, but if you insist on creating your own, buy Uno and dump all of your resources there.)
2. Put C# on it and do code first UI like Flutter but C# with none of the horrors of the Dart language.
3. Let C# and mono build native plugins for each platform so that you can more easily cross compile.
4. Give away free iOS simulator time for all C# developers writing C#lutter.
5. Make sure deploy to all stores is 1 click.
6. Build all of the root stuff as I mentioned as first party with full functionality on all 6 platforms and make sure that Windows is the best client of all. And make sure that flutter itself runs, works and is more compatible with all root os stuff on Windows so that you attract both groups.
7. Create a WinUI set that is better than Material. Let regular flutter users use it too and out innovate Google on this just like Edge is out innovating Chrome.
8. Make sure you create a Bootstrap like set of controls for responsive design that Google refuses to do so that it's easy to write apps that scale from phone to desktop to web.

Volia, you have a shot at recovering Windows, because you've eliminated the need for developers to use a Mac, you've created an environment where it's easier to debug and test on Windows while being cross compatible everywhere with 0 friction.

This is what the Windows team desperately needs from you. This is what all of the development inside Microsoft needs from you. This is what Azure needs from you. This is what your actual customers (i.e. not Enterprise IT departments that are leading you astray) need from you.

It may already be too late. You may have lost Windows, Surface, and be relegated to IBMland with Azure that then has to compete on cost because it doesn't have the .Net tie in that makes it better. That data sure is flashing warning signs that you're looking in the rear view mirror but...

You have to try instead of these empty excuses and marketing claims that are obviously false and are causing .NET and Windows to self-destruct. The data doesn't lie. Your narrative is false, and obviously so and everyone knows it but the people inside the .NET team because the people are voting with their feet. They're choosing React and React Native and they're choosing Flutter. They are not choosing Microsoft platforms or .NET AT ALL. In fact, they're fleeing .NET as fast as they can legacy old apps and move on and at best providing PWAs. And that absolutely includes virtually every single development team outside of the .NET group INSIDE MICROSOFT. And hell, all of .NET code, code spaces, and more is all react native with typescript on Electron (nea soon WebFrame or whatever you want to call it) NOT .NET explicitly because of what I just outlined above. (and PS even VS Code looks like VS code with virtually no evidence of the root OS.)

You guys really need to sit down and be honest with yourselves instead of cherry picking data carefully crafted to convince yourselves that you don't have a catesrophic problem on your hands.

[JohnGalt1717]

@sorainnosia Please be aware of what he's actually instructing you to do:

Run Xamarin Forms that is bloated compared to native code, and inject javascript hooks into a WebView on platforms so that you can run a web browser which then uses WebAssembly to render Blazor which then thunks back to javascript to call Maui injected hooks into the web view that the browser is running inside of a bloated application.

Think about that for even 3 minutes and you'll understand why that is possibly the worst decision in computer science since 640k.

Plus, if you do as he instructs without major platform specific additional functionality, you'll get rejected from the iOS store because it explicitly bans you from doing exactly what was suggested.

[sorainnosia]

@sorainnosia Please be aware of what he's actually instructing you to do:

Run Xamarin Forms that is bloated compared to native code, and inject javascript hooks into a WebView on platforms so that you can run a web browser which then uses WebAssembly to render Blazor which then thunks back to javascript to call Maui injected hooks into the web view that the browser is running inside of a bloated application.

Think about that for even 3 minutes and you'll understand why that is possibly the worst decision in computer science since 640k.

Plus, if you do as he instructs without major platform specific additional functionality, you'll get rejected from the iOS store because it explicitly bans you from doing exactly what was suggested.

is the MAUI WebView also uses webassembly and javascript? if yes, that's make little difference from publishing it into full WASM and run in Cordova

maybe someone should benchmark performance of full WASM compare with mixed of Native + WebView + WASM + javascript (MAUI)

[sorainnosia]

If an app loads a lot of webview, does it consume more memory or cpu?

Mobile phone has limited cpu and memory

[JohnGalt1717]

MAUI is Xamarin Forms with all of the overhead of Xamarin Forms to start the app. Roughly 3x-5x larger than the same native app at startup.

For your scenario of running your blazor app on Android and iOS, what is being suggested is that you use 3x-5x larger app including memory to load up a WebView which will then run your blazor Web app, which is running the mobile WebAssembly runtime from the platform and thunking Xamarin Forms C# functions through Javascript between WebAssembly and Xamarin Forms which itself is an abstraction on the platform code.

So your app will use WAY more memory than Cordova, because Cordova does all of that with native code for all supported platforms. I.e. the initial app is WAY smaller, and the javascript thunking layer is to native code, not to Xamarin and then to native code.

So unless you plan on having native code that Cordova doesn't already have plugins for that you can write in MAUI/Xamarin Forms, there is absolutely no upside to running a Blazor web app inside of MAUI/Xamarin Forms.

AND if the resulting app doesn't have significant additional platform specific functionality, Apple will reject your app submission if it looks like the website. (i.e. you're fine if you build an actual app with identical functionality that doesn't look identical to the website, but the second you use any type of Wrapper like what is being suggested or Cordova that is loading the web site itself directly or through caching in the app it must have "significant additional functionality" compared to the web site or you'll get rejected.

[danroth27]

to load up a WebView which will then run your blazor Web app, which is running the mobile WebAssembly runtime

That's incorrect. .NET MAUI Blazor apps don't use WebAssembly at all. With .NET MAUI, you already have a native app that can run .NET code directly on the device, so there's no need to use WebAssembly. The Blazor components run in your app along with the rest of your .NET code, and then render to the WebView using an in-process communication channel. A Cordova/Capacitor based solution would require WebAssembly, which is what this issue originally requested, but we think the .NET MAUI approach is a better solution for the reasons I listed above.

[JohnGalt1717]

@danroth27 If that's the case, then it's slightly better than I outlined. But it still is far more bloated than Cordova running the webview with native app code that is just shelling the webview and injecting the javascript for the native calls. (I have extensive commentary with people on the Xamarin Forms team when the original test version of this was released showing exactly that)

The webview forces the load of the browser runtime, it's a sunk cost in both solutions. But the native app is 3-5x smaller on initial load than the Xamarin Forms version both on disk and to a lesser extent in memory. I have yet to see anything from anyone inside Microsoft claiming that this is addressed in MAUI and that indeed this makes sense from the memory/app size perspective. If there is data proving otherwise, I think a blog article is in order. If it was even remotely close you'd have at least a hack to fill in the major gaps until you get a real Flutter competitor at least.

[danroth27]

@JohnGalt1717 Sure, including .NET is going to have some overhead, but that's beginning to sound like a rehash the old managed code vs native code arguments. This is a standard tradeoff of efficiency vs productivity. Including .NET adds overhead, but can also dramatically increase productivity, especially if you already have a .NET skillset and .NET assets. Using a WebView also adds overhead, but it enables you to reuse web skills and assets. For many apps the overhead of using .NET or adding a WebView is far outweighed by the productivity gains. For other apps, this tradeoff might not be appropriate. It's our job as framework authors to make the overhead as small as possible so that you can get the productivity gains in as many use cases as possible.

[danroth27]

@JohnGalt1717 In you comment above you make a bunch of data-based claims, but don't cite the data sources. Would you mind adding links to where you pulled the data from so that we can take a look?

I like many aspects of what you propose: C# code-first programming model, great tooling and publishing support, ecosystem of native plugins, beautiful control libraries, etc.. I think we share many of the same goals. We don't specifically plan to build on Flutter. Steve's Flutter experiment showed that we can replace Blazor's rendered with a custom implementation, but Flutter's dart based engine would bleed into the development experience, which I don't think either of us want (imagine seeing Dart specific errors showing up during dev). However, we are looking at leveraging Flutter's graphics library, SKIA, as a potential backend for MAUI Graphics.

[sorainnosia]

@danroth27 If Microsoft to implement SKIA engine with Flutter UI (design), I think it would appeal to many other developers to learn C#, especially considering blazor popularities

[JohnGalt1717]

@sorainnosia Check out https://platform.uno

Which is what I think everyone expected MAUI to be. It has great potential, the people involved are FANTASTIC and they work hard and move very quickly. Unfortunately, because of the constant changing landscape of MAUI and other difficulties because they aren't first class citizens in the .NET ecosystem, it can be difficult to get setup, and breaking changes in my experience are an issue. I.e. it's like using Xamarin before Xamarin was bought by Microsoft.

But, on the plus side, their stuff is most of the time more stable than Xamarin Forms even though they use Xamarin as a basis for at least part of it. (i.e. I went 2.5 months 2 years ago without being able to publish to the Windows, Google and Apple stores using the same build of Xamarin and Visual Studio and while things aren't that bad now, they're are still tons of face palms.)

I'm really hoping that Microsoft, either buying Uno outright or promote it to a first class citizen and devote major resources to ensuring that it can be a best of class experience. (And doesn't decide to compete and kill them, when they've done what Microsoft should have years ago)

[JohnGalt1717]

@sorainnosia Check out https://platform.uno

Which is what I think everyone expected MAUI to be. It has great potential, the people involved are FANTASTIC and they work hard and move very quickly. Unfortunately, because of the constant changing landscape of MAUI and other difficulties because they aren't first class citizens in the .NET ecosystem, it can be difficult to get setup, and breaking changes in my experience are an issue. I.e. it's like using Xamarin before Xamarin was bought by Microsoft.

But, on the plus side, their stuff is most of the time more stable than Xamarin Forms even though they use Xamarin as a basis for at least part of it. (i.e. I went 2.5 months 2 years ago without being able to publish to the Windows, Google and Apple stores using the same build of Xamarin and Visual Studio and while things aren't that bad now, they're are still tons of face palms.)

I'm really hoping that Microsoft, either buying Uno outright or promote it to a first class citizen and devote major resources to ensuring that it can be a best of class experience. (And doesn't decide to compete and kill them, when they've done what Microsoft should have years ago)

[JohnGalt1717]

@danroth27:

https://w3techs.com/technologies/details/pl-aspnet - Expand it out to all data.

Different view with different methodology: https://trends.builtwith.com/framework/ASP.NET but largely the same conclusion dropping fast and while only about 6 months of data, looks like it's dropping off a cliff.

https://www.jetbrains.com/lp/devecosystem-2020/ - This one is really telling in the forward perspective.

https://visualstudiomagazine.com/articles/2021/08/03/so-survey-2021.aspx - Why? Inertia and not redeveloping. Why? Because there's no reason to do so.

https://insights.stackoverflow.com/survey/2021#section-most-popular-technologies-web-frameworks - Unfortunately it's difficult to look at this over time, but you'll see the massive drop if you go back in history in market share for asp.net core.

https://www.simform.com/blog/xamarin-vs-ionic/#:~:text=Xamarin%20Statistics&text=14%25%20of%20developers%20worldwide%20used,of%20Xamarin%20apps%20is%201.74%25 - I apparently was mislead by people internal to Microsoft on the actual number of Xamarin apps (in total, not just Forms!!!) in the stores. It's just 15,000 apps not hundreds of thousands. Versus 2 million for Flutter in 1/4th the life span.

While I don't have the exact data for the Windows Store versus Google and Apple, I think it's no secret that it's an abject failure, which means by definition that UWP is an abject failure, which is why it's also DOA being replaced again with WinUI which itself (it's unclear the messaging is absolutely horrific) is just a retread of WPF with UWP apis. And now the store is being opened up to PWAs and Windows Installer apps (without upgrade support making it annoying at best!).

https://medium.com/codex/just-how-productive-is-the-surface-duo-1107293361a7 I think the complete collapse of the price to less than half long before the new one is announced should tell you the abject failure of Duo. That's just a sampling, the reviews are all the same, and for the same reasons: No app support outside Microsoft because no one cares because there's no reason to develop for Windows and thus no reason to develop for Microsoft in the vast majority of companies.

There's one article on medium from last week that had the data analyzed over the past 15 years based on market share, loves versus will use, but I can't find it at the moment from where I'm at right now. Once I find it, I'll update this.

The rest of my data is directly from Microsoft insiders that are just as angry about this as I am (probably more so because their futures depend on it, mine doesn't, I have options). If I divulge any more information about where it came from, I'll be outing them which I won't do. But yes, there is a very large group of people internally that are very frustrated, and are telling people about it behind closed doors.