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.

[Xyncgas]

🤡

[pikausp]

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? :)

[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

[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

[hunsra]

The promised benefits of MAUI are very attractive to me, especially being an independent .NET developer hoping to build an app for multiple platforms with the same codebase. The idea of MAUI is fantastic, and is why I decided to use it (as well as why I decided to use Xamarin.Forms in the past). I realize the framework is open source and that I haven't paid for it, so that tempers my attitude a bit. However, I do pay monthly for Visual Studio and Microsoft does claim MAUI is production ready.

For a large portion of my efforts so far, MAUI has worked well. However, there are a number of things that don't work as expected and even though the majority of the functionality I've used does work, the things that don't cause frustration, and in some cases, prevent progress towards completion until a workaround can be discovered or the problem is fixed.

In my opinion, Microsoft has let their developer community down a bit by promoting MAUI as "ready" when in really isn't. I think their ability to test, add/fix features, and produce meaningful documentation is too limited. Whether it's an issue with too few resources or lack of focus, I can't say. There seem to be at least 10 engineers who make significant commits, and I see recurring activity on YouTube and social media related to MAUI, so there seems to be more that just a few people working on the product. Maybe there's just too much to do.

I'm still hopeful that the state of MAUI will improve, but I don't know how long I can wait before I decide to move in a different direction.

[arunkumarpediredla]

are you using .Net 7 or .Net 8?
Please look into the recent fixes
[https://github.com/dotnet/maui/releases/tag/8.0.6]

[Alt-WN]

.Net 8 with all latest updates. It is a new, fresh project, so I have a luxury to choose whatever is the newest and the best. I realized that MAUI is not the best. The earlier I migrate to Flutter the easier and cheaper the migration process is.

[mikeboth]

Ballmer? I think you need to step forward from 2014, I am pretty sure the only 'Maui' he knows these days is the Hawaiian one! Also - if it's a 'new fresh' project, that's not a migration.

We're heading towards releasing our .NET MAUI Android app in the very new future (internal company application); it's a company-critical system that will really help employees in my client's company with their work. .NET MAUI quality has noticably improved in recent months.

Regarding the 3.1k github issues - when I've had a look at the queue there are, yes, real issues, but a lot of issues that are very poorly described by the submitters or problems with their configuration or lack of understanding of basic development concepts. So IMO the 3.1k issues does not accurately reflect the state of .NET MAUI.

[Alt-WN]

Yes. Ballmer or other current of former member of board. I want somebody with established reputation and relationship with Microsoft take responsibility of their words. Junior developer, who was hired by MS a month ago showing training video does not convince me that MAUI will be continued for years. I was misdirected by Microsoft too many times (ADO, RDO, DAO, ActiveX, JScript, Fox Pro, Windows Phone, Silverlight). And, I see on many forums, that MS is taking developers from all areas and putting them all into Azure, which is the priority. I agree that you may receive stable UI on Android, what we did in last 2 months (with additional effort to bypass layout bugs). But it appears the complete crap on iPhone, unless you start again to tune your UI. This is not how multiplatform framework should work, if I need to create separate UI for each platform. Our project is still fresh project, that we started in December 2023. Of course there is not too much to migration, yet, but the later we switch to Flutter, the more have to rewrite from C# to Dart. Backend and services will survive and I see they are easily callable from Flutter. We don't know yet how about authentication/authorization, which we already stabilized on .NET MAUI using this helpful video by Carl Franklin: https://www.youtube.com/watch?v=erP42WqOi0Q. Anyway, we have already decided to quit .NET MAUI/C# in favor of Flutter/Dart. Azure services, and Azure SQL still remain our backend.

[azrinsani]

Collectionviews are still broken as of dotnet 8!

[Xyncgas]

Microsoft can develop the AI required for fixing all the issues making sure they are working

[mjsb212]

It's interesting to read all the other devs experiences on this thread. For me MAUI has worked out better than Xamarin & is faster to develop with than Xamarin - HOWEVER - CollectionView does not work well yet in .net MAUI for large Data sets. There are too many issues with memory leaks and layouts in CollView -- that has been my only issue with MAUI & Unfortunately for large enterprise apps its a major problem and development had to be stopped on certain projects until the performance is better & the bugs are worked out. MSFT is aware of the bugs and has acknowledged them; but they get worked on too slowly because there are not enough devs working on MAUI; so we are all hoping in ver 9.0 we will see many things fixed -- but we are also very unsure of the future because MSFT seems to ignore how import MAUI is to their main biz model. They need to hire more devs to look over all the backlogged MAUI bugs instead of ignoring them, and I think if they address more of the backlogged issues and just acknowledge they exist -- then the Devs will have more confidence in the project going forward.

[williambuchanan2]

@mohachouch Main issue at the moment is a severe scroll jitter in iOS. It is so severe that users can't actually scroll, making the app unusable. Also lots of layout issues if you try to use images in iOS. In fact there are a lot of layout issues in general in iOS. CollectionView still glitchy and the alternatives also have problems. Also the iOS keyboard still has a lot of problems - the main one being you can't access anything on the bottom half of the screen when it is showing.

When we upgraded to .NET 8 I tried undoing all the workarounds I have in place, but none of the bugs have been fixed so I had to leave them in place. I still have 11 open bugs logged which haven't been looked at, other than the usual backlogging of them. On top of that, I had some new issues in .NET 8 which I spent weeks working around.

My main gripe is the same as everyone else - that MS aren't fixing anything. It seems like they are away in fairy land adding new features while ignoring all the problems that everyone who is actually using Maui is reporting to them.

[Xyncgas]

maybe there is problem in management, people can not fix bugs
Big company really likes having these overheads

[Alt-WN]

Not "maybe", but for sure this is a management issue. Management, not employee is responsible for driving company.

[ajay-mundi]

Memory issues, keyboard issues, can't screenshot a map, layout problems. A bunch of other patch fixes/workarounds to somehow get something out to the users. Fundamental things that should just work, don't. Been following this issue for almost a year now.

[bondarenkod]

Some of the newly added features are far from the "completed" state. At least it was true during the Xamarin.Forms time.
I always wonder why they are trying to add so many new features when the existing ones aren't working properly or not working properly at all.
Just a small example:
xamarin/Xamarin.Forms#4848
xamarin/Xamarin.Forms#15680

But in some other cases, like embedding fonts, they did an excellent job, this small, but powerful feature worked like a charm without any issues. I wish they put more effort into polishing and covering more real-world use cases when deciding to release some features to the public.

[nbaulesglobalsolutions]

It's not a scam.Just under-valued. Pay the Man! Get Outlook for iOS<https://aka.ms/o0ukef>

…

________________________________ From: Steve Brody ***@***.***> Sent: Wednesday, January 31, 2024 1:53:52 PM To: dotnet/maui ***@***.***> Cc: Ngirngerikl Baules ***@***.***>; Comment ***@***.***> Subject: Re: [dotnet/maui] MAUI is just a SCAM (Discussion #15203) It's interesting to read all the other devs experiences on this thread. For me MAUI has worked out better than Xamarin & is faster to develop with than Xamarin - HOWEVER - CollectionView does not work well yet in .net MAUI for large Data sets. There are too many issues with memory leaks and layouts in CollView -- that has been my only issue with MAUI & Unfortunately for large enterprise apps its a major problem and development had to be stopped on certain projects until the performance is better & the bugs are worked out. MSFT is aware of the bugs and has acknowledged them; but they get worked on too slowly because there are not enough devs working on MAUI; so we are all hoping in ver 9.0 we will see many things fixed -- but we are also very unsure of the future because MSFT seems to ignore how import MAUI is to their main biz model. They need to hire more devs to look over all the backlogged MAUI bugs instead of ignoring them, and I think if they address more of the backlogged issues and just acknowledge they exist -- then the Devs will have more confidence in the project going forward. — Reply to this email directly, view it on GitHub<#15203 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AECNY5VYRE5ZXDUR3IXHFKTYRG55BAVCNFSM6AAAAAAYKAXLCSVHI2DSMVQWIX3LMV43SRDJONRXK43TNFXW4Q3PNVWWK3TUHM4DGMJUGYYDC>. You are receiving this because you commented.Message ID: ***@***.***>

[williambuchanan2]

Unrelated, but kind of related... we also started work on a Blazor Web project, using MudBlazor. It is amazing. Everything just works, and everything is easy to do.

I just wonder how they got it so right with Blazor, while at the same time got it so wrong with Maui.

[FM1973]

Currently doing a blazor web app too. It´s great but when you dig deeper, there are some problems as well. But blazor is definitely more mature.

[FreakyAli]

I feel like this page is full of "skill issue" and not acting high and mighty, I have faced issues with .NET MAUI and a lot of them, But not gonna lie Flutter is no different, You should be happy you were not a Flutter dev back in 2020-21 otherwise you would be writing about Flutter somewhere, it had bugs like adding images automatically rotated it randomly, image pickers did nothing and a lot more.

All developers work with products that have issues in them, it's our job.

[MAUIoxo]

I am not entirely with you. Most of the things I faced as issues were problems that turned out to be a bug. I just remember when I turned the orientation of the Phone and layouts got damaged and even colors turned. Or let's take just .NET MAUI 8 were still the Switch is not handling On/Off-Colors correctly. We can't argue and say its just us and we are not mature enough to handle issues. There are certain expectations on basic things that have to work. Issues just in special cases. I also remember basic things like in a Flyout when the first Item could not be clicked anymore when you had a Flyout-Header. This for instance worked in .NET 7 without any problems. I could go on and on with things. The biggest problem right now is really not that there are more things supported for Windows or MacCatalyst, but that the basic things work reluctantly without problems all around. And the next problem is that when one issue is fixed you get the impression two new issues were introduced. In my opinion this is what get's this negative impression. Once the bug level decreases and it gets stable with all the things, I would imagine there are no more complaints. And just think of a company that has to pay their developers and they should try do their development around issues and find ways to solve an issue that is not their own one, that's a pretty damn thing to so and expect.

[FreakyAli]

I agree that MAUI has a lot more issues than you would expect but saying that it is unusable or just a SCAM is perhaps not the way to go, because if that's the case you should call out each and every framework similar to MAUI a scam for having the same issues.

[RobTF]

I feel like this page is full of "skill issue" ...

All developers work with products that have issues in them, it's our job.

Unfortunately this isn't the case. Our team is well seasoned in MAUI and Xamarin before it. It is down to the skill of my team that we are able to use MAUI at all as they constantly need to understand the intricacies of how MAUI works well enough to work around the various problems, such as the following off the top of my head;

• Keyboard covering UI and not allowing the user to scroll to lower content. - Broken since Xamarin
• Flyout header now no longer respecting the "Use outside safe bounds flag") - Broken since .NET 8
• Tapping android notifications in app where the process is already running due to a foreground service crashes the app. - Broken since .NET 6
• Image rendering on Android not working if loaded from an asynchronous source. - Broken since a later .NET 7 version (maybe fixed in .NET 8 but reports are mixed).
• Top flyout item not being tappable without hacks. - Broken since .NET 8.
• The absolutely atrocious carousel control which;
  • Crashes if the ItemsSource is an ObservableCollection and an item is removed.
  • Does not respect setting the CurrentItem property without shim timings and very specific binding setup.
  • UI lags and often stops mid-movement between pages. - Broken since .NET 6
  • Turning "Loop" off causes the control to render completely the wrong height in iOS. - Broken since .NET 8
  • Android simply not running reliably on 8.0.101

My team have had to put in multiple hacks/shims in both our application code as well as the build tools to keep things running. We have had to completely re-implement the carousel control on iOS but due to the gesture recognizers not working on Android with ScrollView we've had to work around the Android specific CarouselView bugs there. This is only possible becasue of the skill of the team and their understanding of the issues of the platform, not lack of skill. It's at the point where delays due to these issues are raised at board level and senior management meeting notes have occasionally contained Github links to issues so the wider business is aware of why the issues exist.

We think MAUI is a valuable tool for the .NET ecosystem, but we do feel somewhat lied to that it is as production ready as stated, I think this is where the concept of "it's a scam" comes from - it's the vast difference between the Microsoft PR and the reality that people (developers) have a hard time reconciling. It feels as though Microsoft needs to send out representatives into the businesses using MAUI to understand the day-to-day issues as they seem somewhat ignorant or naïve about it.

[Xyncgas]

Crashes if the ItemsSource is an ObservableCollection and an item is removed

Yea, I thought it's 'Observable', we all thought that's what Microsoft thought : We can all agree, that it's Microsoft who decided to use that name to imply an ability for them to observe it that's why you are required to bind an observable collection in the first place, so is it our fault when they seem incompetent to observe a collection with this interface which 99% times were using Microsoft's own implementation of collection under the hood, of course not, they would like you to think it's your fault, so you can put up with their tardiness in fixing their system, and who doesn't like the sound they make when they say it's open source and you are using it for free, which seems reasonable for the statement that usually comes next : Because you are using a free product you should expect no warranty of it and fix it yourself if anything goes wrong because you can, there was the question however which is was it truly free, as many people already answered it no it's not something Microsoft offered to people in the spirit of charity, it was advertised for development of an ecosystem for people to commit in, it painted a good future but it wasted many people's hours, false advertisement at the very least, some might even say a scam, and it was a scam due to the incompetence of the people managing this project, we can do their jobs better than them building a multi-platform UI framework, and we can refer to all the amazing frameworks we had already built, flutter for example allows a developer to present UI as pixels on a canvas therefore by supporting interaction of the canvas, various devices can interact with your applications. It's unsurprising to see Microsoft losing its creativity and soon the top dog of S&P 500 might belong to another company if this continues.

[Overdrive77]

I feel like this page is full of "skill issue" and not acting high and mighty, I have faced issues with .NET MAUI and a lot of them, But not gonna lie Flutter is no different, You should be happy you were not a Flutter dev back in 2020-21 otherwise you would be writing about Flutter somewhere, it had bugs like adding images automatically rotated it randomly, image pickers did nothing and a lot more.

All developers work with products that have issues in them, it's our job.

Here's my take on .Net MAUI

As a professional developer of 20 years and having over 36 years programming experience, it's obvious our job is to implement, fix, improve and document our work… OUR WORK!

However, I disagree with your statement of “skill issue.” (I'm assuming you're referring to general developers) when in fact it’s .Net MAUI not being fit for purpose. If you’ve ever developed in Xamarin Forms you would see instantly how bad MAUI really is as a product.

To give you a comparison, it’s like being a web developer and having your website display perfectly in FireFox, Safari, Google Chrome, Opera etc… and having to do workarounds and even more workarounds for that website to display properly in Internet Explorer... to the point that developers placed an 'unsupported alert' to any users using IE.

Yes, as a developer, it’s my job to find solutions to problems and to fix them. My job is not to fix the tool which is supposed to help me to do my job.

[unamed000]

The biggest problem is really not MAUI is having a lot of bugs and do not compatible very well with Xamarin.

The biggest issue is the date Microsoft mark the EOL for Xamarin, while they introduce new framework that do not even work as good as the old tool!

MAUI teams should try their new tool with a really complex application, combining with MAUI + a lot of iOS Extensions for example. At this state, they don't even have an official guideline on how to implement iOS Extensions on MAUI, so how comes MAUI will be able to replace Xamarin.Forms with lack of support / tools and having a tons of bugs leftover?

And the biggest issue with my "port" is the CollectionView, which is a very important control for most of the app, and it won't work well at all with complex layouts inside.

What will we suppose to do when Xamarin EOL date is coming close and we don't have an alternative? If we choose to rewrite everything, we will just simply choose another framework like RN or Flutter, definitely we don't want to spend time with a framework that we no longer trust.

Upgrading to a new version of the same framework (well maybe that's why they changed the name) shouldn't take a lot of effort like rebuilding an entire application again.

Telling about myself, I used to work with various mobile frameworks such as Native iOS + Android / Flutter / RN, and i never face so many difficulties for custom controls / debugging comparing with while working with Xamarin (although i spend most of time working with Xamarin because of most of remote jobs). And i have to say that MAUI is now at even worse state than Xamarin.

I appreciate the team that they are working on improving the architecture like introducing Handler / Declarative UI / Blazor, etc ....
BUT the biggest issue from Xamarin is not really how the project is "architecture", it's about the how easy to implement such a feature comparing with other framework. I don't mind adding some extra lines of code for a renderer comparing with a Handler. I don't mind to use a "complicated" XAML syntax comparing with Flutter declarative UI. BUT I just want the fundamental control like CollectionView should work as expected. If we have a complicated layout that the height is changed dynamically with user interaction, boom, it should work, not by adding a tons of workarounds / cheats to make a simple thing like that work. Or when i have to write a Calendar control and having 365 labels that is having a Text binding on each page of a CollectionView, I'm expecting my iPhone 14 at least work smoothly when user is scrolling

[ziomek64]

well what is more interesting is the reply when someone asked in this thread what happens to xamarin then? the reply was "not sure.... " and the thread was closed!!

xamarin/xamarin-macios#19966

I think that's because they're moving to new packages, and namings. As it was answered

[developer9969]

@ziomek64 in the case of Xamarin it looks like nothing will happen as it stands today!!.
If ever we need to make an update to the XF app we are stuffed as iOS is concerned because we will not be compliant due to lack of privacy manifest, and as Maui is concerned who knows when that will be available.

[huyvuskedulo]

@developer9969 they just released support for to build Xamarin on Android SDK 34 and Xcode 15, so i think we have at least 1 year now.

Bad news is on azure devops, the macOS-13 doesn't support xcode 15, which sucks. So in this time, we either have to use our own agent or building it manually locally

[developer9969]

@huyvuskedulo is there an official link we can look at thanks

[huyvuskedulo]

@developer9969 https://devblogs.microsoft.com/dotnet/announcing-dotnet-maui-in-dotnet-8-rc-2/#bonus-2-xcode-15-and-android-api-34

They released it couple months ago. And I'm still able to build Xamarin apps in Xcode 15, so can confirm it.

[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.

[jonmdev]

Nice thing about Maui is you are not forced to use XAML. I don't use it. Zero use for it. Just work in C# and you can build anything you can imagine and have enough time to try to make the logic for it work.

[Xyncgas]

You can not build a MAUI app without xaml right
for example can you add a red box on screen every 5 sec, in theory and using MAUI and without XAML

[jonmdev]

Absolutely you can do MAUI with no XAML. I do it all the time. That's all I do. Look at my bug reports. I usually just take the default Maui program and modify App.xaml.cs (default file) but I don't use any XAML. Everything can be done with C#.

[Xyncgas]

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

[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!

[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