MAUI is just a SCAM

[Sebosek]

I tried Dotnet MAUI in version 6 for the first time, but back then I decided to go back and backport back the application in Xamarin.Forms. I've released the app in Xamarin, does the app suffer from the fact it was written using the Xamarin.Forms? No. Not at all. Sometimes it only required more typing, because I'm used to relying on the dependency injection and writing unit tests and Xamarin.Form is full of static calls, so I have to wrap it.

A little bit of background about myself, I'm a contractor, working with from small fintech startups to global tech companies and banks, but from time to time I'm helping non-profit organizations for pro-bono. I've worked on several such projects, usually for a couple of months, and then a little bit of maintenance. I've developed 2 apps in Xamarin.Forms and one React Native. The React Native base was the bigger so far. For the current project, I've decided to give a shot MAUI for the second time. I did a prototype, to verify that the required features are supported (Lottie animations, local notifications, database, ...). Sure, my prototypes worked, it wasn't perfect, but it somehow worked (the first warning sign, #14911), so I prepared CI/CD for the project, agreed with the client, and finally started working on implementation.

The application is very simple, with a very simple design.

Regarding the custom navigation, I was a little bit worried, and after reading the documentation about Shell navigation I got the feeling like, it would be quite problematic to use it with my navigation, so I gave it a day and a half and create my own including the animation, it worked like a charm until I hit the wall for the first time. The data binding between View and ViewModel does work only for buttons, using gesture recognizers it just does not work, #15147.
Along the way, I also found that the border control is broken on Android and it renders 1px space around, so the green background is visible on edges, but it was already reported and planned for a fix in version 8, a second warning sign.

I tried a different approach, using the Shell. It "worked", but the animation does not. I should describe the animation, once you tap on the icon, the active page (the one with the green color and title in the menu) becomes blackish and slowly hide the text (text width becomes 0) on changing the page and the icon for a new active page becomes green and shows the title. The animations were broken by changing the page. You can't put in the shell something other than page content, so every page has to have the same menu control. Bummer.

What other options do I have... After some research, I found, that some ppl are using Carousal View and I was like: "Oh, why I haven't occurred to me before." I was a little bit ashamed of myself.
So, I created the DataTemplateSelector, and prepare views, the menu worked, and the animations worked, but the data binding in views are completely broken. Even the controls aren't bound to the view model properties, it is just completely broken. Kick into the face.

I'm losing hope, but let's it take from a different angle, let's create an observable collection with content views and render them in the content view in the carousal view, similarly for the very first attempt. IllegalStateException. Kict into the nuts.

Let's use the Content presented, exactly like the very first attempt. IllegalStateException. What the hell?!

I'm giving up.

💩

[Vroomer]

MAUI is free open source project. Calling it SCAM because it has some bugs is ridicoulus. The team is working hard to fix issues one by one, but it takes time. It is still a new platform that hasn't matured yet. It's up to debate whether it should have been marked production ready so early in the process and whether enough resources were comitted to the developement, but it certainly isn't SCAM and I'm sure it will become really great technology by .NET 8 release.

[LexaGV]

@Vroomer: You miss the logic line, that's why final word "scam" looks too heavy for you. Look: MS tries to play "multiplatform" (and obviously fails here). Having DECLARATIVE(!) GUI, they gave up, saying "it's unportable" (WHAT!?!? I remember, it's DECLARATIVE thing, how the hell it become non-portable??). Brave M$ managers took open source project Xamarin (sorry, what?? Big company cannot write "portable WPF", but one enthusiast can?? ), renamed it to MAUI and presented it from their own name. THIS is the main scam point: completely unprofessional "home-made" Xamarin they present as "MS' made GUI"! TOTAL LIE. MAUI never was written by MS. Moreover: it's not (and never was) production ready. FOSS - it is not about quality at all! But MS keeps good face with poor game and continues to "fix on the fly" STREAM of found issues. Not even checking that Xamarin is architected properly. Just "home-made" library and bunch of mediocres in MS, trying to make it "work". THIS is what we name SCAM!

[Vroomer]

@LexaGV Well, name it whatever you want, but you are clearly clueless. Microsoft acquired Xamarin in 2016, when Xamarin.Forms were pretty much useless for any complex task. Since then they turned Xamarin.Forms into stable, polished and production ready platform. In 2020 they decided to change it into MAUI, completely rework its architecture and enable desktop development. The whole abstraction layer was overhauled into lighter handler based architecture. Loads of core mechanisms were also reworked, including meassuring, bindings etc. New features like Shell navigation and Dependency Injection were imlemented. Calling proffesional software engineers with in some cases over a decade of cross platform development experience "mediocres" creating "home-made library" speaks volumes about your judgement.

[dotnetian]

btw welcome to .NET 8

[mhamann]

Well, we've got .NET 8 and MAUI still has an incredible number of shortcomings. Things that worked "fine" in Xamarin.Forms just don't work in MAUI, even after rewriting code to conform to new and recommended paradigms. I wouldn't recommend that anyone build an app with this tech.

[ChrisONZ]

Yes, some are paying Microsoft for other services. MAUI is a product they offer to make you enticed to pay for their other services, such as Visual Studio license, etc. Just because they have a business model where you don't pay for the framework directly doesn't mean they have fewer obligations. Well, legally maybe, but not in the eyes of people.

I completely understand the OP's frustration. Many people here said "It's not production ready, but it's not a scam", what is Microsoft's "production ready" advertising if not a scam then? :)

@pikausp - you do realise you can do .net maui on free VS community right?

[JohnHSE]

@Sebosek I completely agree with the sentiment of your post and support your right to vent at the substantial issues that we have with .NET Maui. I vent on a daily basis in fact!
I disagree with calling it a scam though, it isn't a scam, it is free software with quite a few bugs and regressions. More bugs than we would like, with less quality improvements than we would like everyone month, with too many regressions every month, but its not a scam.
This is however a safe place, so vent Vent VENT! Just don't get personal, the people working on .NET Maui are real people and they are doing their best.
So as I said, I agree with the sentiment in your post and the frustration you feel. Just not with the title.

[Xyncgas]

Resolve severe performance issues.

Although relying on Microsoft too much is at least to me a bad way to do programming, to this day input in their webview can't handle a lot of text typed into it or the input is going to lag everytimes you type something, so you can't expect to finish your novel on your brand new application that's using BlazorWebView or Webview 1 2 3... Instead you find out in the end when you are almost finished with your app that there's a performance issue that removes the use case for your application

[RobTF]

@Xyncgas not relying on Microsoft? hope you're using Linux! In fact worse; Linux is open source; they owe you nothing so you'd better write your own OS quickly! ;)

[williambuchanan2]

allow me to put up the bar :People are not paying microsoft for .NET,

Wait... what? There's me paying Visual Studio license fees all these years, and you are getting it for free? How?

[mchouchane-enedis]

@williambuchanan2 , our company also pays huge amounts for VS Studio licenses and assistance. I think @janseris uses the community version which we cannot use in our company

[LexaGV]

@JohnHSE : I explained in details why it's scam in reply to @Vroomer. But I can repeat: Xamarin itself is not a scam, while it's presented as FOSS, made by enthusiasts. But once MS hide the name "Xamarin" and present GUI library as MAUI, company completely takes RESPONSIBILITY for design, architecture and quality of the code. Needless to say, how many bugs and "incompleteness" were found in Xamarin! So when MS says "you have .NET Core and can make GUI with MAUI", they simply LIE! Because MAUI/Xamarin never was properly designed and implemented for production use. Whatever "beta1", "beta2"... status you put on library, it will be "beta forever", since wasn't designed by professionals. That's why MAUI is a scam. It's "cork" in .NET platform just to say in public "we have GUI for .NET Core". Period.

[DDHSchmidt]

I don't think profanity is doing anyone a service but I do understand there's a lot of frustration pent up and certainly some miscommunication.

Let's see if I can present my view in a comprehensive way.

Me & my 2 colleagues we're coming from a former non-trivial Xamarin.Forms app. We have lots of Html&Javascripts to interact with (Hello HybridWebViewRenderer), need to support background-syncing of resources, need to display several documents in a tabbed view, need to switch between list- & grid-representations on-the-fly (Lots of DataTemplateSelectors) and much more...
We needed support for iOS, Android & Windows and at the time the Flutter-support for Windows was still in Alpha.
Also we had experience with .Net so Xamarin.Forms seemed like a natural choice.
The road was bumpy. With the last version 5.0 we achieved a somewhat okayish result. Sluggish in certain views and crude workarounds for certain scenarios but usable.

Gotcha #1: End of life for Xamarin

May 2024 sounds like a lot of time is still left but that is only if you are content with the current target platforms ("Android 13 and Xcode 14 SDKs (iOS and iPadOS 16, macOS 13) will be the final versions Xamarin will target"). If iOS 17 or Android 14 break compatibility with Xamarin.Forms 5 for whatever reason, then good luck requesting a new service release.
Judging by the past months, it only has gotten minor fixes and I don't expect anyone to assemble resources for additional OS support.

Gotcha #2: "production ready"?

Ok, that one has been pointed out to death so let's summarize:
Due to Gotcha #1 we accelerated our plans to migrate to MAUI. We started when there was still only .Net 6 available and oh boy was the breakage real, even for the trivial parts in our app...
It feels like marketing kicked in pretty hard here, so let's leave it at that.

Gotcha #3: Migration best practices?

As I mentioned: We had/have a pretty complex app (Personal opinion: Anything more complex than a ToDo-app in Xamarin or Maui requires deviation from the standard templates) and couldn't really rely on any migration tools.
Biggest problem was a replacement for our HybridWebViewRenderer. While that was an official, documented extension for Xamarin.Forms, there was nothing of that sort for MAUI.
We fumbled a lot to get the previous logic of the Renderer working in the new Handler-construct.
Maybe if I understood Handlers better or probably the internals of MAUI I would get what made Handlers better than Xamarin's Renderers, but from my "consumer's" perspective they seem like a needless hassle to make things work like they did before :/
Fun fact: Only by accident I stumbled upon a dotnet blog that made me realize that there is a HybridWebViewHandler-repository for MAUI!
Unfortunately it apparently uses the Microsoft.Maui.Handlers.WebViewHandler base class for Android, which for us is a breaking no-go but I will certainly study it! :)

Gotcha #4: Regressions

With .Net 7 we finally felt like the framework was getting better. We had our own HybridWebViewHandler ready, got lots of the views to display something meaningful.
We found lots & lots of workarounds to deal with the most pressing issues and were looking forward to the next service releases in order to remove them again... or so we thought.
To this day we have to stick around with 7.0.59 from 4 months ago since all following .Net SRs had regression bugs that would have caused us to invest more time into mitigations for bugs that are "actually" fixed already :/

Gotcha #5: So fix it yourself, you nagger. It's open source!

Excellent point! And that I haven't succeeded at this is likely due to my lazyiness and/or incompetence.
The last time I pulled the MAUI source was maybe 2 months ago or so. I read the Development.md and watched Javier Suarez video
To my shame: My experience was nothing like in his video: He installs Visual Studio prerequsites, workloads, etc. opens Visual Studio and bam! He can compile the solution right away!
After I followed his steps the only thing that greeted me were hundreds of cryptic compiler errors in Visual Studio and I couldn't progress :(
I'm sure I must have done something very stupid but couldn't spot it after repeating over and over.
Plus point: I gave feedback about my experience and received helpful advice from a MS developer and I will try to redeem myself asap! :)
But in researching that, the next question mark popped up...

Gotcha #6: Dotnet... beta?

From the recent PullRequests and monitoring the Service Releases it seems like .Net 7 is already considered stale and all improvements happen on .Net 8.
Since that version is still in beta I'm a bit confused. I thought developing main against stable versions should be preferred?
Anyway: If I were to try to develop for MAUI right now, would I need to install the beta of Visual Studio and .Net 8 in order to contribute? That's where I'm struggling at the moment.

In hindsight: I experienced a lot of helpful remarks in issues, discussions, blog posts, etc. and I see skillful people commiting to the project!
Still: After the lackluster experiences of the .Net 6 & 7 - releases I'm losing hope that there will be a salvation for us and that we're retroactively punished for having bet on Xamarin :/
What adds to my frustration is the uncertainty of the "real" deadline of Xamarin and if my time is better spent in developing workarounds for the latest/next regressions or if I can justify putting more hours into understanding the MAUI sources?

[JohnHDev]

"From the recent PullRequests and monitoring the Service Releases it seems like .Net 7 is already considered stale and all improvements happen on .Net 8."

This is something I only recently became aware of. .NET 7 is production, and yet any issues found are fixed in .NET 8 and back ported 'if deemed high importance'. Which means we could be waiting until November before seeing some fixes, even fixes for regressions that were introduced in .NET 7. I don't understand this at all. We cannot and will not release apps built against a beta .NET, and we cannot begin migration to a beta .NET.

[xtuzy]

i also feel must use net8 is very strange

[RobTF]

Yes, where MAUI is concerned the .NET 6 to 7 to 8 story is strange in that it feels very fast. MAUI 6 was never a stable release and we avoided it on our team bar numerous experiments whilst we assessed its suitability. We're well within the MAUI 7 support window but it does feel like support is fading fast, as many important improvements and bug fixes are seemingly being saved for .NET 8 in November. It concerns me that the moment .NET 8 is released most new changes will begin to be targeted at .NET 9.

[Xyncgas]

If you had used other technology for cross platform app you would've made 5 instead of 0 app

[RobTF]

Well we have 2 production apps on Xamarin and 1 on MAUI today, so not 0 ;) then again, not 5 either to be fair.

[LuohuaRain]

I don't consider MAUI to be a scam, but I am a little disappointed that after three years since the blog post (https://devblogs.microsoft.com/dotnet/introducing-net-multi-platform-app-ui/#mvu), there is still no official support for MVU or Comet framework(https://github.com/dotnet/Comet).

[xtuzy]

comet's developer have go to facebook, so official mvu have died

[LuohuaRain]

I‘d like to give some hope on Comet

[rogihee]

Comet is dead, take a look at MauiReactor: https://github.com/adospace/reactorui-maui

[giuseppenovielli]

dotnet/Comet#281
https://github.com/flyperstudio/Comet

[RobTF]

I agree MAUI doesn't fit the definition of a scam, but I do feel for the OP as our team has been in the same boat.

Whilst the framework is financially free, you pay for it with your time - either as an individual or as a business. The reason many dev teams use a cross platform tool is to save time, especially those of us who are heavily invested in the .NET ecosystem. Having inaccurate or confusing statements from the project maintainers, bugs etc. can make people feel robbed of that time.

Our team are in the late stages of porting a non-trivial Xamarin app over and overall I'd say MAUI works, and the fact it works at all is nothing short of a miracle. I dread to think of the complexity and number of man-hours that have gone into the glue layer between the native platform APIs and .NET and it's a feat of engineering they've got it working as well as they have. Despite my own complaints it has still saved our team countless hours we would've spent battling with native tooling and keeping multiple app versions at feature parity.

That said, they did initially promote it as something it was not, which was much a product much less flawed than it actually is. This perception has led to misplaced expectation from developers and in turn lots of frustration, but I'd ask anyone reading this to stick with it as what I'm hearing more recently seems to be the right message.

[Xyncgas]

or you can use progressive web app that runs on any platform

[RobTF]

The impression we have of PWA apps is lack of lower level platform API and having to bring in reams of stuff just to render a button. Maybe that isn't the case and we should look more closely at it, but it feels like too much of a compromise to us to reduce the UI down to a set of essentially web pages.

[RobTF]

In XAML I do <Button /> and get a native platform button in one line of code though. Your solution looks like an F# based homebrew of React concepts, and whilst I appreciate what you've done it's hard to justify becoming a maintainer of a UI and data binding library (even an internal one) as well as trying to add business value.

There are pros and cons to every approach - would you write a 3D engine from the ground up to make a game? Some would, but many don't.

[Ghevi]

I'm sorry for your experience. I've developed one app in Maui Blazor so I didn't encounter so many issues even tho I agree it's a struggle. I feel lucky to have witness this so early on in my career.
Spending sometime to read opinions and playing a bit with the features of a technology, it's so important to (try) getting a feel of how it could be using it seriously.
The Maui team members have been open to help tho!

[Xyncgas]

Blazor is a safe heaven because you are not using XAML and data binding the way they are using, also you don't have to deal with gesture control etc

[williambuchanan2]

It's not a scam, but it is an absolute shambles. It wouldn't be so bad if there was some kind of response or accountability from Microsoft, but it's like they are all asleep at the wheel, and nobody is around to wake them.

[williambuchanan2]

I just want to understand, if you're not happy with what you're using, why are you using it? (And I'm with you, it is not stable)

You make it sound easy, so can I get you to tell my CEO that all the work the entire team have done in the last 12 months has been a complete waste of time, and we're now just going to start again?

That said - every day that goes by makes me think that is exactly what will happen...

[liebki]

I don't know what sounds easy, I just asked why you're using it? As I stated earlier, I am on your side but we can't expect that they put the whole resources into this one framework, it would be better for everybody but it's not the case.

Maybe if Xamarin is discontinued and the support is dropped, the remaining developers switch over to MAUI. I just think that's how they will handle it, even though it's a bit late then.

[liebki]

I just don't want this thread to explode, summarized we all are not happy or satisfied. Microsoft should rethink how they handle the resources and put a lot more manpower into MAUI

[janseris]

I get the frustration, I did encounter problems and work arounds but if you're not satisfied, why not choose another product?

I just want to understand, if you're not happy with what you're using, why are you using it? (And I'm with you, it is not stable)

The problem is that if you are doing everything in .NET, it's much easier to integrate .NET mobile app than any other mobile app.
Think of consuming REST API. You can share classes between the server and client when C# client for REST API is generated.
Then another thing when you want to use complicated constructs in serialization, you better have C# and C# on client and server on REST API, else it's not very doable.
Then next thing, when your mobile app developer leaves and the app is written in .NET, you can somehow make someone else from the company do some small edits on the app with little effort compared to if it was written in another technology.
And because .NET MAUI in 1 year will be the only supported technology for mobile apps in .NET, there is not much choice.

[DDHSchmidt]

I get the frustration, I did encounter problems and work arounds but if you're not satisfied, why not choose another product?

I just want to understand, if you're not happy with what you're using, why are you using it? (And I'm with you, it is not stable)

As I elaborated earlier: We had a prior investment in Xamarin.Forms and a migration to a completely different technology stack would have been a substantial effort.
Had there been a communication along the lines like "We're discontinuing cross platform altogether" we would have jumped ship.
But we were left in a confusing state where we were supposedly given "production ready" tools and a wildly different perception on our own machines.
At this point we're afraid that we have missed the point of no return and hope that the next major version of .Net will really be the one to convince us :/

[AlleSchonWeg]

Q&A at Build 2023: https://www.youtube.com/watch?v=_IxzKLFNMWA
Fazit: All great, fast and amazing stuff 👍

[ziomek64]

The video is private, what did you post?

[janseris]

Lol they hide the video as well. It was just. NET MAUI presentation on latest. NET Build conference - questions and answers session but I haven't watched much because in first 10 minutes they haven't said anything useful.

[AlleSchonWeg]

The second session with David and Maddy: https://youtu.be/arxsDF__uFA
Highlights:

• Goal is not to reduce numbers of issues. Goal is to prioritize issues based on comments and votes.
• Nightly Maui nuget builds coming
• include native libraries in Maui via platform channels
• At the end they share an email address to contact the Maui team to share upgrade User stories, replacements for non upgraded libraries etc.

[janseris]

Interesting, historically, voting for issues was applied only for feature requests and not for fixing bugs. Bugs should be fixed all

[ziomek64]

Nightly Maui nuget builds coming - that's what I was talking the other day lol That might help a lot

[hez2010]

I totally understand your feelings and frustrations because currently MAUI does have a lot of bugs that need to be fixed before it can be really used in the production.

IMO the current quality of MAUI doesn't meet the bar of "production-ready". It may suit for demo apps and prototypes but once you start to put it in real use, you will encounter endless issues including but not limited to memory leaking, binding bugs, slowness (though it may be due to the bad performance of mono and mono-aot), and AOT-related (especially while using AOT with LLVM, which is almost unusable) issues. It is also why I haven't use MAUI in my apps but instead choosing Avalonia or Xamarin.Forms. Microsoft really shouldn't have rushed a GA version of MAUI instead of baking it until the real mature.

I even haven't mentioned about MVU/Comet because there are just too many fundamental issues before we can start to talk about patterns and features on a higher level.

While the quality of MAUI does become better and better every year, so I would like to expect the next year MAUI in .NET 8 can finally meet the production-ready bar for extensive app development.

[janseris]

Seeing how all the issues are going and have been going so far, it's not possible that it just improves out of nowhere by November 2023 (.NET 8).
I highly doubt that MAUI will be any different in November 2023 compared to what it is now based on my own daily analysis of .NET MAUI issues since March 2022.

[mohachouch]

if MAUI is not stable in November 2023. I think that will be the end of this framework. It's their last chance

[HuaFangYun]

What I want to say is that no matter how good the tools are, there are projects that are not suitable. No matter how bad the tool is, there is a suitable position. Choose to use it, but not blindly. It is hoped that maui will speed up the repair speed, and at the same time, better optimization, blooming sunshine.

[dagadson]

I'm not sure why all the complaints with Maui. I've been using Xamarin since it first appeared over a decade ago and yes, after MS took it over the path got a little more rocky with each iteration. But having developed over 45 apps/platforms since the launch of Xamarin over the last decade+ (ios/android native, forms, and 3 new ones in Maui set to launch over the next 2 months), the biggest thing I've found with devs having issues is because many apps are "over-engineered". What I've seen is they try to throw in every code structure and methodology into every component of the app. Believe it or not, you can create an app that has some components that use MVVM and some that don't. Not every page needs a view model, dependency injection is great but if you don't plan it ahead it will be painful to implement properly (hence all those memory leaks everyone complains about). It's ok to let the back-end do some of the work (servers were designed to do the heavy lifting so the app doesn't need all the biz rules and algorithms inside). Sometimes you don't need layered services (save the "I" service implementations for another day - maybe you don't need the structure). Yes, MAUI has issues but so far, I've been able to work through every issue I've had with it in some way or another and not experiencing the many complaints that everyone is seeing. My biggest recommendation with Maui now is that before writing a single line of code, take a good look at the structure, architecture, and pre-plan ahead. Because as devs, once we start running with the code it gets hard for us to change direction. I'm guilty of this and have learned over the last 10 years that my best dev work comes when I've 80% planning and 20% coding. I wish it was something they taught in these bootcamps, coding classes, and videos. But they focus purely on the code aspect and functionality versus the "how", and "why" of doing something. So is MAUI a scam? No, not in my opinion. Does it take some work to make it "work"? Well, yes, start the coding with understanding what needs to be built and then answering the question "what's the best way to build it?"

[Xyncgas]

Because for me I created a custom solution that can do things like having one or more rendering engine and you make request to the engine like open window or put this layer behind another one or whatever and the rendering engine does it for you while rendering the screen in parallel, without using Xmal, works with MAUI / MAUI.Blazor / truly cross platform

[williambuchanan2]

I'm not sure why all the complaints with Maui.

Actually, you make some valid points here. I've been guilty of this, and see it at work every day. I think going forward i'm just going to find workarounds rather than try to get things working like they are supposed to.

That said, my main gripe is the lack of response or accountability from MS, which has lead to lots of lost hours.

[hez2010]

Yes, MAUI has issues but so far, I've been able to work through every issue I've had with it in some way or another and not experiencing the many complaints that everyone is seeing.

You also said you have been able to work through many issues. Yes, we can definitely work around many issues, but shouldn't MAUI just work as it is supposed to?

Many developers don't continuously check issues every day to see what workaround should be applied to what issue, and when it comes to a new developer, this will become a huge waste of hours. What's worse is that MAUI is quite new so the documents and answers to issues in forums (such as StackOverflow) are few, which makes it really hard to find those workarounds without hours of searching and experimenting.

MAUI tends to be a native cross-platform GUI framework, but the most stable, polished and production-ready part of MAUI is using Blazor for a hybrid app which is actually running a web app and totally not native. What a shame.

As I said above, MAUI is a great framework and it is actually improving every year. However, currently, the quality of MAUI just doesn't meet the bar of "production-ready" unless you want to use blazor-hybrid for a non-native app. I would like to expect MAUI to be a polished GUI framework in the future (maybe in .NET 8), but not now.

[Hooterr]

Do you know how demotivating and demeaning it is to work with this stuff? Instead of progressing with your work for the client you constantly need to fix broken things that should just work. Fighting with things that you know nothing about and shouldn't know anything about. Imagine if the String class was broken and you had to do some crazy workaround to make it work. Then you look to the side and see Flutter guys or native android/iOS devs having fun and working with no issues, occasionally complaining that the new SDK was only in 98% documented not 99%. That's career-questioning depressing sometimes...

[williambuchanan2]

Do you know how demotivating and demeaning it is to work with this stuff?

You hit the nail on the head here. It is utterly demotivating.

[Xyncgas]

A lot of features inside MAUI is tricky to use, for example the point of providing a bunch different component out of the box is for people not having to implement the wheels based on positions and dimension on screen and drawing the UI and handling input events themselves, but if you can't put a StackLayout Inside a ScrollLayout or things will break or many other situations that we are familiar with that's a mine field to walk through it is kinda counter productive. It's ok to provide options, but the way it's done was causing problem, look at the web you can put img in div or style the img directly nothing would go wrong you can put div in img too

[RobTF]

of corse html supports binding how do you think all those web framework...

Javascript.

The difference is that in XAML databindings are a first class feature. Note syntax such as {Binding} which has no equivalent in HTML.

[Xyncgas]

data-* attribute is the equivilent, you can parse it like you can parse XAML {Binding}

https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes

[hez2010]

XAML gives me a bad taste, I like the taste of html better

HTML is over-bloated and not very suit for UIElement rather than Document.

HTML is not designed for template usage and its layout system is also not suited for GUI development. Not to mention the CSS styling system consists of non-orthogonal APIs and makes it a pain to work with layout and styling.

If you have any experience with Angular/React/Vue/Svelte/Solidjs/Blazor, they are definitely not using the original HTML but a XAML-like templating system with a customized binding syntax.

As for XAML vs HTML, I would like to use XAML rather than HTML.

[Hooterr]

XAML is not the problem, nor is the Binding system. It's the controls that are bugged as hell, and instead, they try to do everything else but fix them.

[RobTF]

data-* attribute is the equivilent, you can parse it like you can parse XAML {Binding}

https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes

Nope.

[nextcodelab]

I tried Dotnet MAUI in version 6 for the first time, but back then I decided to go back and backport back the application in Xamarin.Forms. I've released the app in Xamarin, does the app suffer from the fact it was written using the Xamarin.Forms? No. Not at all. Sometimes it only required more typing, because I'm used to relying on the dependency injection and writing unit tests and Xamarin.Form is full of static calls, so I have to wrap it.

A little bit of background about myself, I'm a contractor, working with from small fintech startups to global tech companies and banks, but from time to time I'm helping non-profit organizations for pro-bono. I've worked on several such projects, usually for a couple of months, and then a little bit of maintenance. I've developed 2 apps in Xamarin.Forms and one React Native. The React Native base was the bigger so far. For the current project, I've decided to give a shot MAUI for the second time. I did a prototype, to verify that the required features are supported (Lottie animations, local notifications, database, ...). Sure, my prototypes worked, it wasn't perfect, but it somehow worked (the first warning sign, #14911), so I prepared CI/CD for the project, agreed with the client, and finally started working on implementation.

The application is very simple, with a very simple design. Regarding the custom navigation, I was a little bit worried, and after reading the documentation about Shell navigation I got the feeling like, it would be quite problematic to use it with my navigation, so I gave it a day and a half and create my own including the animation, it worked like a charm until I hit the wall for the first time. The data binding between View and ViewModel does work only for buttons, using gesture recognizers it just does not work, #15147. Along the way, I also found that the border control is broken on Android and it renders 1px space around, so the green background is visible on edges, but it was already reported and planned for a fix in version 8, a second warning sign.

I tried a different approach, using the Shell. It "worked", but the animation does not. I should describe the animation, once you tap on the icon, the active page (the one with the green color and title in the menu) becomes blackish and slowly hide the text (text width becomes 0) on changing the page and the icon for a new active page becomes green and shows the title. The animations were broken by changing the page. You can't put in the shell something other than page content, so every page has to have the same menu control. Bummer.

What other options do I have... After some research, I found, that some ppl are using Carousal View and I was like: "Oh, why I haven't occurred to me before." I was a little bit ashamed of myself. So, I created the DataTemplateSelector, and prepare views, the menu worked, and the animations worked, but the data binding in views are completely broken. Even the controls aren't bound to the view model properties, it is just completely broken. Kick into the face.

I'm losing hope, but let's it take from a different angle, let's create an observable collection with content views and render them in the content view in the carousal view, similarly for the very first attempt. IllegalStateException. Kict into the nuts.

Let's use the Content presented, exactly like the very first attempt. IllegalStateException. What the hell?!

I'm giving up.

💩
From .net maui to flutter... flutter is fast 300x maybe compared to .net maui...
.NETMaui to FLUTTER

[Xyncgas]

so you created new application using flutter, congratulations, better making something than making nothing

[williambuchanan2]

I feel your pain!

[ToolmakerSteve]

Calling it a scam is not appropriate. But I agree that it is still not production ready. And that Microsoft should have dedicated more development resources to it. Feels like people high up in Microsoft don't understand that one of their key assets is superior developer tools and technologies. Or they are under the delusion that "Blazor" and "Maui Blazor" means they have an adequate response to ReactJS/ReactNative and to Flutter. Nope.

Personally, I pulled my current client out of both Maui and Xamarin Forms. Even though I pray that Maui eventually manages to become robust.

We rolled our own UI, on top of Xamarin Native (will switch to .Net 8 cross-platform at some point). Similar to Uno Platform, AvaloniaUI, and Unity 3D, not to mention Flutter, we don't attempt to map to native controls on each platform. That way lies madness. SkiaSharp FTW.

[cacaelmas]

Could not agree more, it's a shitty framework. It does not even properly check audio privileges, it simply relies on the OS (for iOS). What I've encountered so far does not display any kind of capacity for mid to enterprise level applications. It's basically Xamarin, which was shitty as well. I cannot understand why would a company like Microsoft would want to deal with the same problems even after the failure of Xamarin. MAUI still uses Xamarin libraries which in itself proves the stability will never arrive to MAUI. I'm sad that they do not choose a technology similar to Flutter. Even Microsoft has a lot of things to learn.

I hate MAUI, would never suggest it, try to use Flutter which is far better on all aspects.

[DDHSchmidt]

Is that an official, guaranteed endorsement that all Xamarin apps will continue working on the next OS versions?
Because the phrase
Android 13 and Xcode 14 SDKs (iOS and iPadOS 16, macOS 13) will be the final versions Xamarin will target.
sure sounded like we should better get our migration going.
In that case I apologize and suggest to update the official site with that wording.

At least that makes the waiting time more worthwile, when .Net/MAUI 10 will maybe finally be as stable as Xamarin.Forms 5 used to be 🙂

[RobTF]

I think the situation is this;

• Xamarin will support targeting up to Android 13 and iOS 16 and no further.
• Devices which run Xamarin apps will still run your Xamarin app as there is backwards compatibility built in (for example, the moment you update iOS it doesn't kill all of your existing apps). Eventually they will probably break, but not for quite some time. The takeaway is that even if your app targets iOS 16, it will run on iOS 17, so your app will be safe.

However...

• Android 14 and iOS 17 are due out around fall 2023. This is months away from this time of this post at the most.
• You will have to target Android 13 and iOS 16 when building/updating Xamarin apps. This means you will be building against older/unsupported platform SDKs.
• Apple and Google will at some point change their store policies such that you must submit apps and updates targeting the newest SDK. This will block Xamarin apps from being created or maintained. Your existing app might run, but you will not be able to update it anymore. This is the crux of the problem.
• We do not know definitively when the above will happen. Some users think it will be around April 2024 (a link to any supporting evidence on this would be good). @davidortinau has simply said we will need to refer to "store guidelines". The Xamarin/MAUI teams can't be any more specific as they likely know as much as we do regarding the Google or Apple policies.

Therefore I the official line is "get updated to MAUI ASAP or you cannot maintain your app".

If you do not update your Xamarin app to MAUI you will be left in a situation where your app is on the store and runs, but you cannot submit updates anymore, in effect making your app somewhat "orphaned".

The friction with the community is that many of us with existing production Xamarin apps are finding porting an uphill struggle as MAUI was released too early and has many showstopping bugs. The promise is that .NET 8 will resolve this situation but developers have to largely go on faith, as the two stable released (.NET 6 and .NET 7) are fairly woeful.

For example, we've taken 9 months to port our main app from Xamarin and testers are reporting issues with the app just displaying a blank screen from time to time - we have traced it to a side effect of Android image loading being broken which was raised in March, fixed in .NET 8 in June and is pending a possible backport to .NET 7. This is the sort of thing that is making developers sweat and feels like being stuck between a rock (Xamarin EoL) and a hard place (MAUI issues).

[mohachouch]

Thanks for the summary @RobTF. To complete, regarding Android. It will no longer be possible to update a Xamarin Forms app from August 2024.

@davidortinau, timing is not possible for many compagnies. You should review the end of support date and accept Android 14.

As said just before we are stuck between an end too close to Xamarin Forms and a still unfinished version of MAUI.

Thanks

[williambuchanan2]

I think the real problem is we have all lost faith. I'm more inclined to believe the bad news than the good (not that there is much in the way of good news when it comes to Maui).

[Xyncgas]

There is generally a cost to having faith, if a person speaking of problems to be address don't take it as making people lose faith in fact the person is helping the society to understand the cost for people to have faith, by not addressing the issues one may never pay the cost and by ignoring the issues one doesn't know where to pay the cost even if one intends to.

Different people have different values, which means some loses faith more difficult than other, because we all have some fundamental value. For example components in MAUI being buggy is unacceptable to some people, xamarin support dropped might be unacceptable to mobile developers, for me I don't care because I use MAUI.Blazor so if there is anything that drives me stop using MAUI it might be how competing framework can produce smaller faster program that's more useful.

A stronger belief was obvious good for marketing but it needs competency to respond to people who believes in you, saying you love linux but no visual studio on linux for example is ok but how do I know what you mean by you love linux is anything more than forking linux to make your own OS. It seems Microsoft needs to prove themselves with good product for example tool tips in Visual Studio to help one learn a 'Visual' langauge (C/C++, C#, F#, Basic) while a developer doing programming and using AI and documentations to point out "Hey, you can use System.Threading.Monitor here" is all you need to get back to the top and if making programming like playing a video game with new player tutorial is going to get a lot people liking Microsoft and reputation higher than other industry leader why couldn't they do it ten years ago

[DaveBrask]

I'm a solo developer, very experienced, I have 2 patents and an ICP million-in-one award. I was able to get my first app working and distributed on Android and iOS, and expect windows this spring. Moderate complexity, not trivial but not pushing the envelope at all It was very difficult. Things not working for no apparent reason, some issues took me a week to figure out, some things I had to redesign around, debugging 3 times for windows then android then iOS. Many hours online searching for resolutions to issues.

I developed on Windows then transitioned to android, then to iOS. I had to carefully retest everything using a detailed test plan for each environment, and for both light and dark theme. Not what I wanted to do but going thru end-to-end testing many times made it a better app.

I'm about to implement notifications and images so these items noted by RobTF are scary:
-Tapping android notifications in app where the process is already running due to a foreground service crashes the app.
-Image rendering on Android not working if loaded from an asynchronous source.
I'll reply when I find out if I can get these to work.

[RobTF]

@DaveBrask if you'd like any conversations on these items offline just drop me a PM. It would be useful to swap ideas with someone like yourself.

[Xyncgas]

Github should implement End-to-End PM directly in the comment sessions

[FM1973]

We did a bigger project for a customer using Maui native. So far, ok, we are still stuck at 7.059 because of later bugs - and there are a lot of them. The app is available in the Apple App-Store and on Google Play. We have more than 10k users and there are only a few problems.
Currently we are doing a project for another customer using Maui hybrid. If you don´t need native UI, this is much better! Razor / Blazor is easy to handle. And if done right, you can create a Web- and Windows-Version of your app with no additional effort. I agree with @Xyncgas - Maui hybrid shoud be the standard.

[vanka78bg]

I think. NET MAUI hybrid is the only way to continue at this point. Microsoft can go on fighting with the bugs in the native cross-platform controls for the next few years. Maybe we'll get a stable framework within 3-5 years. Maybe not. By that time, everyone would have lost interest, moving on to other UI frameworks, possibly leaving the .NET stack entirely.

History tends to repeat itself. Let me remind you of other popular technologies like Java and Delphi that tried the same cross-platform native approach in the past, only to abandon it at some point, to replace it with their own rendering. This is what Flutter and Qt are currently doing (and some third-party .NET UI frameworks) and what .NET MAUI could do from the start, but it is too late now.

The next best thing is to rely on the browser to do essentially the same. Not ideal, but at least it relieves Microsoft from having to implement their own rendering. There is also the added benefit of attracting people from the largest developer ecosystem - Web, who are not necessarily interested in .NET. That would also make it possible to add more platforms later, like Linux, at a minimal cost.

The only downside, the way I see it, is for people who absolutely refuse to learn or use HTML/CSS, but they are a minority these days.

[Xyncgas]

Yea web app already is good enough
You can use electron to do a bunch things
Now it's simply would be nicer if people can make web app using C# / F# / VB
MAUI.Blazor / MAUI hybrid's biggest contribution is making .NET codes running natively on the platform (to do anything webassembly can't do for us for now)
MAUI using native control as its approach to implement cross platform UI framework is a lot works with not enough people making things as buggy as Xamarin did

[Xyncgas]

The only downside, the way I see it, is for people who absolutely refuse to learn or use HTML/CSS, but they are a minority these days

We gotta convince people HTML is basically byte codes because browser is really fast, you can change these HTML and the 'virtual machine' the browser is can interpret these code to do things, that're difficult for people to do them from scratch (pixel by pixel):

1. Displaying different languages' scripts
2. right to left / left to right detection and support
3. Word wrapping

[janseris]

The only downside, the way I see it, is for people who absolutely refuse to learn or use HTML/CSS, but they are a minority these days

We gotta convince people HTML is basically byte codes because browser is really fast, you can change these HTML and the 'virtual machine' the browser is can interpret these code to do things, that're difficult for people to do them from scratch (pixel by pixel):

1. Displaying different languages' scripts

2. right to left / left to right detection and support

3. Word wrapping

Except it uses Javascript to manipulate the visual tree and that is hell slow. HTML is nothing like byte code. That would be WebAssembly.
MAUI is not only about UI but about device capabilities usage including low-level (more than browser API capabilities). E.g. background GPS service. But truth is MAUI cannot do background GPS service anyway so you have to do some heavy platform code.

[Xyncgas]

We can manipulate dom from Webassembly soon, but to the point of 'HTML is basically byte codes', in my opinion it's because browser use SIMD-Processing for parsing text so its performance is close to byte codes

I agree native capabilities attract people's attentions, because it's an important feature for people to use. Yet the native capabilities is separate from the way MAUI choose to be an UI framework by using native controls, for example people can have these capabilities in hybrid setup by using browser (webview) to present their content, while still having access to native capabilities in for example Blazor's 'Code Behind' because .NET is running natively with this option

[RobTF]

My problem with using HTML over native widgets is;

• HTML has no opinion on how anything should look. Native components adhere to the OS standards out of the box whereas HTML removes any standardization as the concept simply isn't there. As OS manufacturers don't release libraries which supply their standards in HTML developers have to cling onto whichever open source project of the month is doing the best job of replicating it.
• CSS is terrible. Everything ends up going through a pre-processor like SASS to try and make it somewhat usable. The number of hacks one must employ to get some basic layout designs put together isn't great.
• HTML in and of itself is actually pretty useless for applications. As @janseris points out, one must use backing scripts to create the illusion of an application front end by manipulating the DOM in realtime to give the impression of interactivity. This is very slow (hence the need for Reacts virtual DOM) and the whole thing is a hack on top of what is ultimately a document rendering engine.

There are massive advantages to XAML, which was designed for application front ends from the ground up. XAML however is just a markup language, its real power comes from the tools that support it. WPF is evidence of just how well this can work as WPF is absolutely fantastic - Microsoft did an amazing job on WPF and on the whole it was a huge improvement over WinForms and pretty much everything else at the time.

The problem with MAUI is they have not got the tooling into a place where developers can work as cleanly as they can with something like WPF, which causes the dev loop to be extremely long and the runtime is full of bugs partly because they've tried to overgeneralise things without taking the time to fully take into account each platforms idiosyncrasies. Adding yet more platforms as part of the Xamarin -> MAUI migration has just made this worse.

[Xyncgas]

I'd try to choose a point you made to discuss :

HTML has no opinion on how anything should look

XAML for building applications is putting certain benefits on the table when combine with the frameworks we have now that use it : Native controls, on the platforms it's running, out of the box

But I do not consider applications adhering to the platform's 'looks and feels' mandatory, and the frameworks offered that use XAML currently doesn't let me manipulate it as easily as it would manipulating HTML DOM in javascript, I doubt it would be helpful to the applications that wants to be as expressive as to the extend of freedom you have when using web application's approach

Overall the stance I have on XAML are :

1. Application can be beautiful in their own way
2. It's impossible to manipulate what's on screen
3. You can not build frameworks on top of it to let yourself be writing applications in another language (C#/F#/VB or other languages) without writing XAML at all when building a new application because how versatile HTML are and how restricted it is for using XAML

[RobTF]

But I do not consider applications adhering to the platform's 'looks and feels' mandatory

Perhaps not mandatory, but I'm sure Apple/Microsoft/Google have spent $$$ in R&D getting things right whereas the custom UI widgets in the latest novelty app for viewing cat photos probably hasn't.

[JoaoVictorVP]

There are massive advantages to XAML, which was designed for application front ends from the ground up. XAML however is just a markup language, its real power comes from the tools that support it. WPF is evidence of just how well this can work as WPF is absolutely fantastic - Microsoft did an amazing job on WPF and on the whole it was a huge improvement over WinForms and pretty much everything else at the time.

There are also massive disadvantages to XAML, like it being a whole new thing to work or the fact that it incentivizes enormous ammounts of data sharing and sticking with things like MVVM instead of allowing the construction of dynamic and interactive UI's. For anything but a corporate software it is a pain to work with.
An approach like Kotlin did with compose would be much more interesting. We had 'comet' which was promising, but it sounds it is stopped in time as well.

[KubaO]

XAML is a meta-language that lets you instantiate objects and set their properties. It has a 1:1 translation to C# code (or F# or VB.net, per your pleasure).

[axa88]

I'm feeling stupid, I am wrong, I should reconsider how I can write an application without writing XAML using it

Trouble is there is so little documentation on avoiding xml. I just use a lot of trial and error unfortunately.
Anyone have any resources on using strait c# for UI design?

[bondarenkod]

XAML is a meta-language that lets you instantiate objects and set their properties. It has a 1:1 translation to C# code (or F# or VB.net, per your pleasure).

You can basically convert XAML 1:1 to any other layout definition language, sometimes with a few adjustments. Structurally, it can be converted back and forth to JSX.

That said, XAML doesn't need to be as bulky or restrictive as it once was. It worked fine 15-16 years ago when WPF was released, but it no longer meets modern UI/UX development standards. Of course, it's still convenient for some older developers who want to rely on students' knowledge until their retirement. But just look at how much C# has evolved over the years. I've been writing in C# since 2009 and started developing mobile apps for Windows Phone (and other Windows platforms) in 2014-15.

I switched to React Native after seeing and experiencing the slow progress of MAUI last year, and I have no regrets. Of course, I now face different challenges, but none are as frustrating as those I encountered with Xamarin Forms. I would love to see the React Native UI paradigm integrated into Microsoft's project infrastructure and ecosystem—especially the ability to continue using C#/DLLs/NuGet packages, etc.

It's ironic that Microsoft has never managed to deliver commercial-grade (*) applications based on Xamarin Forms/MAUI. Most, if not all, of their products are built using native code or a mix of web technologies, including React (Native). It’s clear that management is out of sync with developers and other technical staff who could provide proper requirements before developing a new stack. The same misalignment happened with Windows Phone (Mobile) and is now happening with Boeing.

(*)—It's worth noting that when I refer to commercial-grade applications, I'm not talking about apps with simple layouts, a few pages, and a login screen with a menu. While those types of applications may work fine for certain use cases, they don't fully showcase the capabilities of a robust development stack. So, when someone says, "I have an app and it's working fine," I acknowledge that, but I’ve seen and worked on many similar apps myself, especially during my time developing for Windows Phone in 2015-2016.

[janseris]

@bondarenkod can you elaborate on "XAML no longer meets modern UI/UX development standards"?

[bondarenkod]

@bondarenkod can you elaborate on "XAML no longer meets modern UI/UX development standards"?

@janseris

Example 1: Conditional Rendering
In React Native, conditional rendering is straightforward and readable. You can easily define UI component in the same file or in a separate one and use them:

{isLoggedIn ? <HomeScreen /> : <LoginScreen />}

To achieve the same functionality in XAML, you would need to:

• or: Use Visibility with a Binding and a Converter
• or: DataTemplateSelector
• or: DataTrigger
• or: etc.

Example 2: Inline Conditions
React Native allows for inline conditions directly in the UI code, which is incredibly useful:

{ backgroundColor: isEnabled ? 'green' : 'gray' },
...
listViewProps={{
  ...(Platform.OS === 'android' && { inverted: messages.length !== 0 }),
}}
...
{loginStatus === LoginStatus.LoggedIn ? 'Welcome, User!' : 'Please log in.'}

In XAML, implementing such logic typically demands a lot of boilerplate code, converters, triggers, playing with visibility, moving text constants to the VMs, etc.

Example 3: Inline Functions
React Native enables inline functions like this:

onPress={() => {
  onPressMessage(item);
}}

In XAML, however, this would require defining at least one separate method in the .cs file. Yeah, it can be done automatically, but this method is defined in a different file. So, if you need to recall what's happening here, you need to navigate to the xaml.cs file to have a look.

Example 4: Hot Reload/Refresh
React Native's hot-reload/refresh works seamlessly in 80–95% of cases (personal experience), significantly speeding up development A LOT.
I don't know the status of HR\HR in the MAUI, because after trying the first "release" version I've started crying and told the company that we are going to try RN or Flutter.

That's just a few examples I were able to generate in 10-20min of time.

Based on my experience working on a project with ~70k ELOC (I've excluded a few droid projects, I believe that VS counted some generated R code as mine) and a few years (since 2014-2015, just XF, WPF, etc - 2011+) of hands-on XAML development, I often found myself spending 60–80% of my time dealing with framework limitations rather than writing code or implementing features. This inefficiency, coupled with the verbosity and complexity of XAML, makes it less suitable for modern UI/UX development compared to frameworks like React Native.

XAML\MAUI\XF - are the perfect products, I wish I could have the same joy using them instead of spending time learning a new framework (which was easy).

[mnxamdev]

Does Microsoft use MAUI in any of its products?

[hez2010]

The Azure mobile app is built using MAUI.

[janseris]

Can you post a link to sources

[dotnetian]

It doesn't matter

[RobTF]

We asked this a couple of times before and the conclusion is "yes they do" although not on anything you'd call mainstream. The biggest is probably the Azure app, but despite it's name making it sound important the app is pretty basic in terms of functionality. I can't see them porting something like Teams, for example, as they'd likely never get it stable enough for production.

I'd seriously love to be proven wrong on that last point!

[jfversluis]

The Azure mobile app is listed here: https://dotnet.microsoft.com/platform/customers/maui and we're actively working right now to get more stories on here, so stay tuned!

Additionally, during .NET Conf (and some other events since then), a couple more Microsoft products were pointed out.

[Seanxwy]

I just want to say that MAUI + Blazor is not bad.

[Xyncgas]

Yea you literally are writing an app that can be deployed to

1. the websites and be installed as webapp
2. running natively on windows & Mac getting all the 'real multi-threading' and make network requests without cors restrictions
3. You can alternatively stuff it inside ElectronNET or Photino, and instead of using MAUI, you are writing blazor that can be running on Linux too which MAUI doesn't support and you can in theory write application in F# instead of C# or html so you wouldn't even feel like you are coding for blazor / the web you would feel like you are writing a console app then because the browser renders whatever html you are displaying your app is going to be easily supporting rich dynamic content

[Xyncgas]

To get started using photino instead of MAUI for blazor so you can run your app on Linux / MacOS / Windows
Simply clone or download this repository https://github.com/tryphotino/photino.Blazor
Navigate to the hello world project in Samples folder and run dotnet run to see

[tjiakwokyung28]

maui is the best 👍

[bondarenkod]

It sounds like you have experience with a wide range of tech stacks. Aside from the one you’ve mentioned like MAUI (probably, Xamarin Forms), have you worked with other stacks or platforms and for how long?

[phillippschmedt]

@davidortinau Is it maybe time to close this discussion? It keeps getting pushed to the top without any real new insights.

[gautambjain]

Before this discussion gets closed, I would like to add that my experience with Maui has been pleasant and I really like it. I think with .Net 8, things have been lot better. Last week I launched my app "Notezilla" successfully on both Play Store and App Store. Thanks to the generous community.

I hope Microsoft keeps the same attitude and improves WinUI 3 too at much faster rate.

[davidortinau]

I'm pleased to see reports that our efforts and investments are recognized, and success is being achieved using .NET MAUI. I'm closing this thread as it seems to have run its course.

We welcome constructive criticism as it is often the best feedback for guiding our future investments. Please do continue to share both reports with us, and keep in mind the https://dotnetfoundation.org/about/policies/code-of-conduct.

[GerryOnGithub]

I tried Dotnet MAUI in version 6 for the first time, but back then I decided to go back and backport back the application in Xamarin.Forms. I've released the app in Xamarin, does the app suffer from the fact it was written using the Xamarin.Forms? No. Not at all. Sometimes it only required more typing, because I'm used to relying on the dependency injection and writing unit tests and Xamarin.Form is full of static calls, so I have to wrap it.

A little bit of background about myself, I'm a contractor, working with from small fintech startups to global tech companies and banks, but from time to time I'm helping non-profit organizations for pro-bono. I've worked on several such projects, usually for a couple of months, and then a little bit of maintenance. I've developed 2 apps in Xamarin.Forms and one React Native. The React Native base was the bigger so far. For the current project, I've decided to give a shot MAUI for the second time. I did a prototype, to verify that the required features are supported (Lottie animations, local notifications, database, ...). Sure, my prototypes worked, it wasn't perfect, but it somehow worked (the first warning sign, #14911), so I prepared CI/CD for the project, agreed with the client, and finally started working on implementation.

The application is very simple, with a very simple design. Regarding the custom navigation, I was a little bit worried, and after reading the documentation about Shell navigation I got the feeling like, it would be quite problematic to use it with my navigation, so I gave it a day and a half and create my own including the animation, it worked like a charm until I hit the wall for the first time. The data binding between View and ViewModel does work only for buttons, using gesture recognizers it just does not work, #15147. Along the way, I also found that the border control is broken on Android and it renders 1px space around, so the green background is visible on edges, but it was already reported and planned for a fix in version 8, a second warning sign.

I tried a different approach, using the Shell. It "worked", but the animation does not. I should describe the animation, once you tap on the icon, the active page (the one with the green color and title in the menu) becomes blackish and slowly hide the text (text width becomes 0) on changing the page and the icon for a new active page becomes green and shows the title. The animations were broken by changing the page. You can't put in the shell something other than page content, so every page has to have the same menu control. Bummer.

What other options do I have... After some research, I found, that some ppl are using Carousal View and I was like: "Oh, why I haven't occurred to me before." I was a little bit ashamed of myself. So, I created the DataTemplateSelector, and prepare views, the menu worked, and the animations worked, but the data binding in views are completely broken. Even the controls aren't bound to the view model properties, it is just completely broken. Kick into the face.

I'm losing hope, but let's it take from a different angle, let's create an observable collection with content views and render them in the content view in the carousal view, similarly for the very first attempt. IllegalStateException. Kict into the nuts.

Let's use the Content presented, exactly like the very first attempt. IllegalStateException. What the hell?!

I'm giving up.

💩

I agree, apparently for Maui I need to completely rewrite my apps from almost scratch. I am also very unhappy about this. Why can't Microsoft learn from Toyota: continuous improvement, not massive changes every couple years.

[haidar47x]

I'm very confused as to why Microsoft invests in cross-platform app development technologies. They can just focus on their own products and leave supporting other platforms to the community/responsible party. The only thing that makes sense to make cross-platform is .NET.

Why not focus on WinUI for Windows based devices and Blazor for browser-based dev? The time, cost, and energy invested in these technologies is too much. If someone wants to develop for macOS or iOS, they can simply use SwiftUI or something else. If someone wants to develop for Android, they can use the existing ecosystem that's battle-tested and already works. Why re-invent the wheel? Why must everything be cross-platform?

Apple won't do this because they know it's a lot of work to support these changing technologies. They merely focus on their own platforms, their own toolkits, and their own language. Consequentially, they have the most coherent development ecosystem that looks good, optimized, and very much stable. They only need to worry about their own technologies.

Microsoft does it all. Jack of all trades and master of none. Excess of everything is bad.

The worse thing is that Microsoft won't even use these technologies themselves, which leads to "LACK OF TRUST".

[haidar47x]

I agree that it's more convenient to use the things that we're already familiar with. However, there's no silver bullet. It doesn't hurt to broaden your knowledge. I'd rather learn Swift than use C# for a macOS application.

[vanka78bg]

I believe the reason why Microsoft does that is pretty obvious - to lure as much developers as possible to their ecosystem. We are no longer in the 90s, so not everything is just PCs with Windows pre-installed. In fact, Windows is no longer the most used operating system, and the PC is no longer the most widely used hardware. Simply put, to stay relevant, they have no other choice, but to make cross-platform solutions.

Currently, I am working on a software project that requires both Windows and Mac support as a bare minimum, plus Android and iOS for the lightweight mobile version. The users demand it, so we have no other choice, but to give them what they want. Having everything implemented in C# can be a huge time saver - we have about 90% code reuse. Had we chosen to go for the platform-specific route, we would have to use C# on Windows, Swift on Mac and iOS and Java on Android. That would mean almost zero code reuse. In practice, we would have to implement and maintain four different products with the same functionality, using four different technology stacks, at four times the cost.

Without going into much detail, web application is not suitable for this type of project. It has to be a native application, having access to all the features available on the target platform. That's why we keep .NET MAUI in our radar, but currently it is too unstable and lacks some essential features to be of any use to us.

[bondarenkod]

Because I want to do it in C# and not learn a whole new ecosystem, tooling, language specifics and stupid naming conventions

This year, I dove into Node.js and React Native (RN), and I’m genuinely happy with this decision. The shift allowed me to focus more on product quality rather than spending 30–70% of feature development time (compared to Xamarin.Forms) on performance tuning and other optimizations, trying to find workarounds, sitting at the github and waiting for issue-fixed-pr to be merged (which never happened in some cases, even for fixed issues (!!!)).

At the same time, I continue to leverage PowerShell and C# for backend tasks, ensuring a well-rounded skill set. Switching to RN has opened up a new world of possibilities, enabling me to create better products, reduce time spent on optimizations, and develop custom tooling for my project. It’s not just a simple application—it’s part of a flexible and robust solution (product).

On top of that, learning new technologies like RN and Node.js has been an excellent way to keep my "geeky" brain in good shape. Speaking truthfully, the architectural approach in Xamarin.Forms was a dead end. Not much improvement could be implemented in terms of performance; the only real option was to rely on the framework's performance (or it's updated version), which wasn’t great for large applications at all.

I’ve also leaned heavily on ChatGPT for developing features and tooling. While the results aren’t always perfect, it often provides 40–80% of ready-to-use code or sparks ideas for implementation. This has significantly accelerated my workflow.

My deep understanding of architecture and 6+ years of experience with Xamarin.Forms made the transition to RN surprisingly smooth. For me, adopting this new technology felt as seamless as starting a new project.

[Xyncgas]

but C# is faster than browser and javascript and native control is faster than browser controls so RN is always going to be inferior
For actual big application it has to be Xamarin / native
though I likely might be wrong

[bondarenkod]

but C# is faster than browser and javascript and native control is faster than browser controls so RN is always going to be inferior For actual big application it has to be Xamarin / native though I likely might be wrong

This project is built with Xamarin.Forms (XF), excluding some native projects and a few internal core NuGet libraries. The React Native (RN) version currently implements about 80–90% of the features from the XF project, which means the RN app’s codebase mostly mirrors the same functionality set.

From my experience, React Native is significantly faster compared to Xamarin.Forms. I stopped trying .NET MAUI once I discovered that the CollectionView component still wasn’t functioning properly even one year after 'release' and we decided not to invest into it.

(native projects are excluded as well as a few internal core nuget libraries).

[ChrisONZ]

I think probably want to check your OS stats Sent from Outlook for Android<https://aka.ms/AAb9ysg>

…

________________________________ From: Ivan Todorov ***@***.***> Sent: Tuesday, December 24, 2024 2:09:29 PM To: dotnet/maui ***@***.***> Cc: Chris Owens ***@***.***>; Comment ***@***.***> Subject: Re: [dotnet/maui] MAUI is just a SCAM (Discussion #15203) I believe the reason why Microsoft does that is pretty obvious - to lure as much developers as possible to their ecosystem. We are no longer in the 90s, so not everything is just PCs with Windows pre-installed. In fact, Windows is no longer the most used operating system, and the PC is no longer the most widely used hardware. Simply put, to stay relevant, they have no other choice, but to make cross-platform solutions. Currently, I am working on a software project that requires both Windows and Mac support as a bare minimum, plus Android and iOS for the lightweight mobile version. The users demand it, so we have no other choice, but to give them what they want. Having everything implemented in C# can be a huge time saver - we have about 90% code reuse. Had we chosen to go for the platform-specific route, we would have to use C# on Windows, Swift on Mac and iOS and Java on Android. That would mean almost zero code reuse. In practice, we would have to implement and maintain four different products with the same functionality, using four different technology stacks, at four times the cost. Without going into much detail, web application is not suitable for this type of project. It has to be a native application, having access to all the features available on the target platform. That's why we keep .NET MAUI in our radar, but currently it is too unstable and lacks some essential features to be of any use to us. — Reply to this email directly, view it on GitHub<#15203 (reply in thread)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AJTUAXWOHEIWKOMUURQP6UT2HFTJTAVCNFSM6AAAAAAYKAXLCSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTCNRVHA2DQMA>. You are receiving this because you commented.Message ID: ***@***.***>

[FM1973]

We have developed two Maui apps for customers (both in the app and play store). One has about 11k installations, the other almost 50k.

The first is using Maui "classic". It works fine although I have to say it´s sometimes hard to use Maui "classic" because of bugs and performance problems.

The other app is using Maui Hybrid with blazor. This is much easier and the app size is - in our case - a lot smaller. Blazor is very easy to use and we had a very smooth development experience. We did a web app as well and could resuse 90% of the code.

If I had to choose between "classic" and blazor for the next project, I would select Maui hybrid with blazor for sure.

So, in the end, a tool (framework) is as good as you are using it.