The MAUI team does not respond to issues with any urgency... THIS IS **THE** ISSUE!!!

[mobycorp]

Description

DO NOT CLOSE THIS ISSUE BECAUSE YOU THINK IT DOEN'T MEET THE CRITERIA OF A VALID ISSUE! THERE ARE SOME VERY SALIENT ISSUES BEING RAISED IN THIS ISSUE.....

I have reported issues as far back as Feb, 2022, and of as now, many of these reported issues remain unfixed. This is really a poor situation where I have to open an issue to complain about issues not being fixed. The lack of response to issues IS the issue.

I reported an issue (#4672) and here we are at .NET 8 and this VERY BASIC thing remains unfixed. @davidortinau I know I have been critical of the lack of desktop support and I do applaud your efforts in shoring up this deficiency in the latest releases, but how long do we have to wait for the most basic MAUI stuff to work properly?

When I open a window that has frames, it almost NEVER draws correctly. You have to resize the window to force a layout recalculation for things to correct themselves. Here is a picture of an app that has a flyout strip and it never draws correctly until a window resizes:

You can see that the button row is not centered. Here is the same screen after a window resize.

I reported this almost 2 years ago and you (David) even added comments to the original issue: Controls/Layout does not draw controls correctly in first-time view. #4672

It has been in the backlog ever since and I would think that something that makes a MAUI app look like total s&#t would be a concern of the MAUI team.

Also, I reported the fact that easy controls like Switch cannot have its basic colors changed (at least at the time I reported the issue: There is no way to set the text color of a Switch control #8965). Gerold V just took it upon himself to close my issue by telling me, in essence, we are not going to do stuff like this. I should go write platform-specific code. That's ridiculous because what is platform-specific about the Switch control??? In WPF EVERYTHING was stylable... Why is it the responsibility of the development community to do your work by writing handlers and such to get something simple to work?

Also, take a look at the screenshots above. Notice the minimize, maximize, and close buttons are double-drawn. How does this stuff pass QA??????

I am getting ready to roll this out to 2000 perspective users and I will not be proud of 99.99999% of the app because of the visual aspects of MAUI. I looked at UNO and Avalon back when I was deciding to go cross-platform and I decided to stick with Microsoft all the way for everything: .NET, MAUI, gRPC, ASPNETCORE, etc... I wanted the whole stack to be Microsoft, but I am ruing my decision... MAUI is great in concept, but not in implementation. Simply upgrading Xamarin to MAUI did not buy the community much in the whole product delivery. You guys have focused far too much effort on sapping milliseconds out of performance while glaring visual bugs persist. I think 90% of the attention should be placed on fixing bugs and performing better QA. I know stuff breaks from release to release and I would think that decent regression testing would catch stuff like this. I also think you guys need to look at WPF and figure out how to achieve the functionality that existed there before developing new stuff. I would love a WYSIWIG XAML editor so we can see what we are designing without having to run the app. This brings me to Hot Reload which RARELY works! It does work on straight XAML, but not XAML in templates. I see it work there, but as I said, rarely.

I have been a developer since 1984 and have focused much of my career on UI design. WinForms was great and WPF was even greater. MAUI isn't even making the charts... I sometimes spend hours trying to get something that was easy in WPF to work in MAUI and that is time I don't have...

Yes, this rant is probably misplaced here in the issues log, but how else can somebody truly vent their frustrations about developing with MAUI? I spoke via a TEAMS meeting early last year with both David and Maddy and I let my opinions be known then. Here it is almost two years later, and nothing is even slightly easier to develop in MAUI... I would love for David to be made aware of this "issue" and have him contact me directly. This doesn't even scratch the surface of my frustrations...

I really want to talk to @davidortinau directly. Please pass this on to him.

Regards,
Steve Miller

Steps to Reproduce

No response

Link to public reproduction project repository

No response

Version with bug

8.0.3

Is this a regression from previous behavior?

No, this is something new

Last version that worked well

Unknown/Other

Affected platforms

Windows

Affected platform versions

No response

Did you find any workaround?

No response

Relevant log output

No response

[Alex-Dobrynin]

It seems to me that this is the end for Microsoft's mobile team. They do not fix own bugs, they do not respond to the tickets, they even do not review PRs made a year ago to fix BASIC feature of MVVM - Bindings. All they do is blah blah blah to the camera. Poor, very poor management.
When i firstly heard about maui, it was said that it will be revolution in .net mobile development. I thought it will be some kind of XPF (x-platform WPF), the render engine will be based on skia and we will be able to style everything and everywhere, like it is in WPF and we will never do ui based platform-specific things, like it is in Flutter. But what do we have? Very laggy buggy 'XF', and if you need some not standard implementation of controls maui provides you, you need go and implement platfrom-specific things. Even XF has better performance and less bugs. They could go and look how avalonia managed to implement this, but no, they trying wrap shit into a candy wrapper. IMHO

[charlesroddie]

It seems to me that this is the end for Microsoft's mobile team.

This is not accurate. It only applies to MAUI. Microsoft's mobile team includes dotnet android and xamarin.ios. These are not only stable but rapidly improving. The macios team even gave us NativeAOT support with dotnet8 which is fantastic progress. The mobile-focused team also includes skiasharp which is also great.

they even do not review PRs made a year ago to fix BASIC feature of MVVM - Bindings

This may be true but developer assumptions that things like bindings and navigation should be part of a UI framework are partly responsible for the buggy nature of the platform, by increasing maintenance workload for no reason. It's overreach, since the dotnet generic type system can handle reactive code in any UI framework without the framework needing to know anything about it.

They could go and look how avalonia managed to implement this

It would be a good idea for either 1. avalonia to find a way to port xamarin.forms to avalonia, like they did with wpf, or 2. for maui to copy avalonia and abandon its native-control approach as unmaintainable and replace it with a drawn control approach.

[nor0x]

It seems to me that this is the end for Microsoft's mobile team.

This is not accurate. It only applies to MAUI. Microsoft's mobile team includes dotnet android and xamarin.ios. These are not only stable but rapidly improving. The macios team even gave us NativeAOT support with dotnet8 which is fantastic progress. The mobile-focused team also includes skiasharp which is also great.

they even do not review PRs made a year ago to fix BASIC feature of MVVM - Bindings

This may be true but developer assumptions that things like bindings and navigation should be part of a UI framework are partly responsible for the buggy nature of the platform, by increasing maintenance workload for no reason. It's overreach, since the dotnet generic type system can handle reactive code in any UI framework without the framework needing to know anything about it.

They could go and look how avalonia managed to implement this

It would be a good idea for either 1. avalonia to find a way to port xamarin.forms to avalonia, like they did with wpf, or 2. for maui to copy avalonia and abandon its native-control approach as unmaintainable and replace it with a drawn control approach.

rapidly improving 🤔 the iOS binding are not only incomplete but there is no binding story for Swift based frameworks/libraries which are definitely the future on the Apple side.

I agree, SkiaSharp is a great product. I use it daily in a big production app - but similar to MAUI it's understaffed. The idea of Maui.Graphics is awesome but the half baked execution is bad

[charlesroddie]

Some very big upgrades over the years: PCL profiles -> netstandard, mono -> monovm inside dotnet6 -> nativeaot inside dotnet8. I am glad they focused attention there. I did a search and there is a chance your swift bindings will come in dotnet9.

[robloo]

@Alex-Dobrynin

All they do is blah blah blah to the camera. Poor, very poor management.

Adding, if you've ever worked in a large company you unfortunately realize that this isn't "poor management" how you think. It's politics. Management may very well be struggling to keep Maui alive internally -- or to get the funding it needs -- and putting on a good show is important to avoid further cuts. It's not ideal by any means but that's what happens when you are driven by revenue streams for Azure. Microsoft has no vision in this space for where they can take things and spur future growth and future revenue so its just driven by the numbers today -- which are not in our favor.

I hope everyone keeps that in mind in these discussions. We need to keep Maui and the underlying tooling alive for .NET itself and all the UI frameworks built on top of it. Maui as a container for even Blazor web views is good tech. Maui is still a pretty important piece and if we loose it now because the team stops fighting internally we do everyone a disservice.

[Quaybe]

This, 110%. I worked at Microsoft for 5 years in a non-Azure role while all resources were (probably still are) being dumped into Azure, and our on-prem focused team barely got any leftover scraps. Your statement is completely accurate, and it's painful to know that's exactly what is happening here, because I want MAUI to succeed.

[foximoxi]

I appreciate the huge contribution that has been made over the last few years to rebuild Xamarin Forms into something faster, more flexible and bug-free. Unfortunately MAUI already has more bugs reported than Xamarin Forms, although its support is currently only formal. Hire a few more people to start fixing bugs systemically. The number is only increasing - 2122 reported bugs as of today. How many will there be next year?

[robloo]

This is important to highlight. .NET MAUI and it's underlying tooling is very important to the .NET ecosystem regardless of UI framework. Hope they get more resources and direction to correct course.

[bigpilot]

I believe all these Microsoft GUI frameworks (WPF, Xamarin, UWP, WinUI, MAUI) are merely meant to dissuade developers from using Multi-platform frameworks like wxWidgets and Qt.

I believe wxWidgets is the best UI framework out there. It's just unfortunate that there's no C# support. You need to be able to program in C++ to use it. It's a joy to use, especially in combination with wxFormBuilder.

[bbqchickenrobot]

Why would they make flawed UI's to "dissuade" using other UX frameworks? I think that logic is backwards, if MS devs hated MS UX tools they would leave and go to other frameworks ...

[Alex-Dobrynin]

@bbqchickenrobot money doesn't smell

[Xyncgas]

but they are still calling it 'forms'
UI should be a canvas where contents are painted efficiently with hardware acceleration
You can Qt a webview for me I will let the webkit browser do the rendering for anything I wanted

[nor0x]

this made it to hacker news
Developers are not happy with .NET MAUI, but nobody in the team cares about it

@mobycorp good luck with getting an answer, critical comments or discussions are usually not addressed at all

[doublecount]

Avalonia is the best c# xaml cross-platform by far !

[Alex-Dobrynin]

what is avalonia.bionic? something without .net android but native code instead?

[robloo]

Yes, it's native code I think. Possible with .net native and https://developer.android.com/ndk.

[Alex-Dobrynin]

So as I see, after Amazon became a big sponsor of Avalonia, it has big future as Flutter. In near future we can use avalonia android with better performance, sounds great

[AlizerUncaged]

2024 and we already have android, ios, wasm and many other platforms, avalonia is the defacto standard for dotnet ui!

[Xyncgas]

MAUI still unavailable for linux (officially)

avalonia use something similar to XAML too, you can not render dynamic content like you can using html + javascript (I'm wrong), browser is better for providing UI

Electron.NET should be the future imo

[Alex-Dobrynin]

For the "casual developer" maybe... It's primarily a Xaml to SKIA interpretation engine. It will never be as fast or scalable as MAUI with its native mapping.

@Stedy59 Oh yeah? Have you heard smth about Flutter and how does it work?

[robloo]

It does matter to understand Flutter's architecture. Doing so would discredit your above claims. It's not wise to disregard a technology entirely -- It exists for a reason and it's good to understand why.

[Alex-Dobrynin]

Doesn't matter... Not a Dart fan.

It has nothing to dart, it about architecture of framework

[Strypper]

[Stedy59]

Please elaborate...

[robloo]

Let's not get personal. I have concerns about the leadership in MAUI but the dev team seems well qualified from what I've seen. They are just understaffed and doing the best as possible.

[Strypper]

A good manager doesn't put all the troubles and problems on to themselves
They will hire more and transparent with the users for the roadmap
It's clear that they only make this for Blazor folks not giving a damn about users that use this for a serious native application.

[qrzychu]

For me it's even worse - a third party managed to do what MS said was impossible. They made WPF multiplatform.

Yes, guys at avalonia made XPF - all you have to do is to change the SDK in your csproj and bam, your wpf works on MacOS and Linux.

Why MS didn't go this route? Just expand WPF to other platform, do some improvements? Give us Razor syntax (simpler change notification for simple views), proper Blazor interop (both ways embedding), some easier to use styling, maybe an app builder.

Instead somebody made a decision to create a new platform from scratch, which took resources out of the dotnet team. So far only achieved goal is some nice dotnet conf presentations. Oh, and another achieved goal was the death of Xamarin

[robloo]

For me it's even worse - a third party managed to do what MS said was impossible. They made WPF multiplatform.

This was always interesting to read. Whenever Microsoft stated something to that effect it wasn't coming from a technical source that's for sure. Microsoft is steered by underqualified PM's most of the time in the UI framework space.

[bigpilot]

There are obvious business reasons why Microsoft doesn't want multi-platform desktop frameworks to succeed.

[Stedy59]

Please enlighten us...

[giuseppenovielli]

.NET MAUI, from what I can see, is the ONLY framework that has created a cross-platform architecture design (handler).

Thanks to this design it is the ONLY framework that allows developers to DECIDE AND IMPLEMENT which component to use (native, skia or another graphics engine) to render, for example a Label.

The other frameworks (Flutter, Avalonia, React native) have their OWN rendering and STOP.

.NET MAUI allows you to CHOOSE, IMPLEMENT AND CUSTOMIZE THE ABSTRACT COMPONENT.

In your opinion, would .NET MAUI have any problems implementing everything in Skia, as Flutter or Avalonia does?

I think the most difficult part was Microsoft's choice to implement everything using NATIVE COMPONENTS, because each OS has its own logic, compared to implementing everything via the graphics engine.

In your opinion, does React Native, which has the same implementation as .NET MAUI, UI OS, have fewer problems or bugs?

[robloo]

Note that the Uno Platform also allows using native controls side-by-side and interchangeably with C# WinUI controls. It's architecture is somewhere in between Maui and Avalonia.

Avalonia can embed native controls with some airspace considerations.

So the other frameworks still allow native control usage as required.

[ivanjx]

thanks for the info @robloo
btw have you tried uno yourself? do you face any noticable performance drop especially on low-mid end android devices? i tried their control catalog app but the performance on my device is just so terrible.

[Atulin]

IMHO the technicalities don't matter, the result does. Sure, it's cool that MAUI uses native components over drawing everything from grounds-up, but if the results are worse than a framework that just draws everything with Skia, I'll pick the latter any day.

[robloo]

@ivanjx Yes, Uno was trialed in the past on my end and ran into the same performance concerns on Android and macOS.

[stevefan1999-personal]

State of React Native: fix 1 bug, got 2 bugs in return...

[Atulin]

Just a reminder that Microsoft is moving pretty much all of their native UI apps to webviews. Teams, Outlook, soon enough Windows itself will just be a borderless Edge window.

I think the fact they don't even want to eat their own dog food speaks volumes.

[ivanjx]

honestly if they would just let us create blazor hybrid for linux, like photino, it would be perfect. i dont care about native controls anymore since they just bring headaches.

[Xyncgas]

Linux + MAUI.Blazor

[charlesroddie]

MAUI is great in concept, but not in implementation.

No it was clear from from the beginning that the concept was a bug factory.

• Sticking with the native control approach of xamarin, which immediately 4xes the work and 4xes the potential for bugs and makes it almost impossible to achieve consistent UI.
• Saying yes to everything (navigation, bindings, multiple ways to do stylings including css, adding blazor).
• Exaggerating the technical advantages of the xamarin to maui move. There is a string dictionary at the heart of maui which does lookups based on type and property strings.

I looked at UNO and Avalon back when I was deciding to go cross-platform and I decided to stick with Microsoft all the way for everything: .NET, MAUI, gRPC, ASPNETCORE, etc... I wanted the whole stack to be Microsoft, but I am ruing my decision...

"I want to the whole stack to be Microsoft" is an appalling way to make a decision.
And while you do recognize it as a poor decision, you maintained it for 2 years despite the pain it caused you.
And you seem to maintain it still and your strategy is still to keep going and try to get them to change.
Forget about brand names, work out the cost of porting to uno or avalonia, work out the cost to you (in dev time and product quality) of dealing with maui bugs, and see which is larger.

[mobynet1]

@charlesroddie, if time and money were not an issue, I could take a look at changing, but being a single developer company with a funding deadline, I don't have the luxury of switching. When I worked at DEC (Digital Equipment Corporation) we found that third-party 'anything' cost more in the long run in terms of support. I was also amazed at the number of people who would spend days if not weeks getting Eclipse set up bitch about Visual Studio because Eclipse was "free." It was not free when you factor in the labor it takes to make a "free" thangy work - it cost more. Plus, if the development teams at DEC, Microsoft, et. al. talk together and share talent, it should make the product better in the long run. The MS internal teams may not be discussing issues to find common ground, but the only way to get that to happen is to shake a few trees and rattle a few cages. I have a meeting planned with David Ortinau and I am hoping that something can be done to alter the current direction. Anything decided now will still take months to make it out to main street, but if you don't push the boat in some direction, you will always be stuck at the dock.

[davidortinau]

Reminder of the code of conduct we expect everyone to observe.

https://github.com/dotnet/maui/blob/main/.github/CODE_OF_CONDUCT.md
https://dotnetfoundation.org/about/policies/code-of-conduct

[durandt]

Sad that it should be that hard to create discussions to convey legitimate critics without it becoming a townsquare lynching.

[mobynet1]

Some people... geeze...

@Strypper and @durandt and all of the other people who have contributed positively to this thread - thanks for your positive feedback. Yes, I don't know where some people get off on being jerks in forums such as this. They must have thought they were on Twitter or X or whatever it's called nowadays. There's consensus building, problem-solving, and positive contributions. Then there are others who simply can't play in the sandbox with all of the other people who are just trying to make things better for the community as a whole.

[Vroomer]

Yeah, indeed, thanks for all the great positive contribution @Strypper brought here. Now that you got attention from @davidortinau I really hope they won't treat your issues with priority just because you are so vocal about them. That just shouldn't be a factor for prioritizing bug fixing. It would be very unfair to thousands of other developers who vote for their issues as is customary.

[terrajobst]

@Vroomer @mobynet1 @mobycorp @Strypper

We don't mind critical posts about our project. But we do mind when people personally attack each other. Your response to each other are inappropriate. Future comments like these won't be accepted. Please adhere to the Code of Conduct or we'll be forced to block your accounts.

[xamiell]

Same from my experience, all members of my team opted for Xamarin.Forms/MAUI not to be part of the tool stack and opted for other more stable frameworks. Xamarin/MAUI seems to have no clear focus of priorities.

[davidortinau]

I really want to talk to @davidortinau directly. Please pass this on to him.

@mobycorp let's have a call and discuss. Please email me david.ortinau@microsoft.com if you haven't already (I've been out on holiday).

[DDHSchmidt]

☝️
This is what I consider an anti-pattern, given the circumstances and the history that has led us here.

Sure, there are specific uses cases that are better discussed in a 1-on-1 but in my opinion the biggest elephant in the room is that I never know which problem the next (service) release will even contain?
Several, minor 7.0.X releases changed the behaviour of Layout controls. One release, your content was aligned perfectly on iOS, next minor release and everything's all over the place again!
Fix that and the next minor release suddenly breaks the layout on Windows!

I had minor hopes for .Net 8.
David was really pushing hard the "We don't do all fixes in .Net 7 anymore so we can fully concentrate on .Net 8".
I encountered only minor setbacks with the .Net 8 previews and no major screw-ups (Several minor ones, but oh well) ... come around RC2 and our build pipeline breaks for Windows, because suddenly UseRid is absolutely necessary since WindowsAppSDK is not ready for .Net 8 yet?
Yeah, I know, different team. But come on... iOS-/Android-integration with .Net 8 is on time, but with a library produced in-house at Microsoft we can't do?
That just adds insult to injury and really undermines how .Net MAUI seemingly always gets the short end of the stick at Microsoft...

Anyway, that's just one of the many regressions that have been haunting every release so far and I don't see how any 1-on-1 will improve on non existing QA?

This offer feels like a "back room tactic" to direct everything into private channels so that the discussions, comments, etc. look "cleaner" again marketing-wise...
I for one think public shaming (without the personal insults) is more than justified, even if it's just for dissuading unsuspecting developers to sink time into this framework.

[davidortinau]

but in my opinion the biggest elephant in the room is that I never know which problem the next (service) release will even contain?

I agree, and I want to get better visibility for everyone on this. As for what is a known candidate for a service release, we use this project board: https://github.com/orgs/dotnet/projects/194/views/20.

Several, minor 7.0.X releases changed the behaviour of Layout controls.

For this reason and others we redirected effort from back porting fixes to service releases to improving our testing, validation, and overall QA processes so that in future servicing we can have more confidence that we aren't regressing. I detailed some of that effort in the .NET 8 release blog, and expect we now starting to see the first fruits of that labor. More work to do, no doubt. It sounds like you noticed the impact, aside from the RC2 issue you noted.

This offer feels like a "back room tactic" to direct everything into private channels so that the discussions, comments, etc. look "cleaner" again marketing-wise.

I do understand that. I'll keep that in mind going forward.

[durandt]

Although I agree with the general feeling of frustration in this thread regarding the quality and stability of MAUI I would like to bring it some nuance.

For background, I released my first MAUI app (iOS/Android) to 20'000 students in august this year and it is working well enough (rewrite from a previous Xamarin.Forms app). I have even received some positive feedback. The biggest issue is the app crashing quite often on resume on iOS and it is not a MAUI issue but a dotnet runtime issue: dotnet/runtime#81211
But I agree that to do so I had to spend much more time fixing small things that I would probably not have had to spend using other frameworks.

MAUI is pretty instable
But so was Xamarin.Forms for quite some time in the beginning and developers and community had to work together to make it work properly. Before it was acquired by Microsoft were nor code nor issues public and community had to work quite hard to find and share work-arounds on the Xamarin forums. Bringing it open-source helped finding work-arounds and quicken the pace of fixing things.
I am not happy with the current state of MAUI but with the experience of Xamarin.Forms I am still hopeful that it can be improved.

Given the scope of the problem (the number of issues and the too-few hands to fix them) we (the community) need to work hand with the developers and make their work easier by contributing positively to the issues we create or upvote. Getting agressive toward the developer-Team won't help us (see "a management issue" below).

MAUI does not listen or fix bugs
This is simply not true. I understand folks saying "I paid for this product please fix this" but the code and issues being open-source it is up to us the community to try and help the developers by providing repros and trying to find and share work-arounds to quicken the fixes, as mentioned by @Vroomer. Yes I would like things being fixed with less work from my part, but the number of issues makes it unrealistic to expect things to be fixed without some engagement from our part.

I have documented around 10 bugs/issues that affect my app in various ways and around half has been fixed and/or are actively worked on.
Although not fast and we could also talk about the slow pace of backporting fixes to the current version. The team seems to be focused on the next release, which is understandable from a product management point of view but always frustrating from the user's point of view.
I also agree with the point being made that I see no great triaging/prio of the issues at hand. At least not a clear doctrine about what should be fixed when.

The MAUI team has fixed a great number of issues with the .NET 8 release and I have some hope it will be more stable (I will in the coming weeks upgrade and test my app and will come back here to share the feedback)

A management issue
Too few folks, too big scope, I agree with @charlesroddie
I think a lot of the issues may be related to management issues.
The scope of MAUI is too big for such small a team to tackle. Whether these requirements came from the Team itself of from upper management it is still a management failure to have allowed it.
And another management issue to have not dedicated enough resources to make it possible.
There should have been teams using the product, either within Microsoft or within the MAUI team, to help improve the quality of the product.

TL:DR;
Yes I am not really happy with MAUI today but will work together with the MAUI Team to make the product better. Being harsh to the developers won't help us, we need to work together. And I am hopeful that a good and stable MAUI can be achieved in the future.

[mobynet1]

@durandt I certainly did not expect the response that happened on this post and it did get pretty squirrely, but I did get David's attention! I have already responded to him and hopefully will be able to meet with him in the next several days to discuss my, and it appears, a great deal of other's issues! Yes, my only intention was really to make things better for everyone even though I took a "bull in the china shop" approach!

[NonameMissingNo]

Any MS products using maui?

There are 3 apps that use Maui from MS, namely Azure, Microsoft 365 Admin, and Store Commerce

[bigpilot]

I have decided not to use cross-platform Xamarin/MAUI anymore but to use the native Xamarin.Android and Xamarin.iOS as targets.

I had all sorts of problems when I ported one of my apps from Xamarin.Android to Xamarin.Forms/MAUI and I simply couldn't get the same level of quality with Xamarin.Forms as with the native implementation. And trying to solve the issues took me too long and I often ended up with a sub-optimal result.

[davidortinau]

@bigpilot why not use .NET for Android and .NET for iOS with .NET 8? Xamarin end of support is in May 2024.

If you have a specific case for shared UI you can blend in .NET MAUI and Blazor hybrid even though your apps are that way by default.

[bigpilot]

Yes, those are the successors to Xamarin.Android and Xamarin.iOS. I'll use .NET Android and .NET iOS on my next attempt.

[winstonpang]

To be fair. Xamarin Forms was plagued with issues early on, and took sometime to iron out.

Now having said that, I think one of the biggest issues is that, they decide to drop Xamarin Forms completely and lead you to think you'll get a like for like experience, if not better when you move over. Which obviously is far from the truth.

It shouldn't require this much frustration for anyone to new up a MAUI project, and be able to develop a straight forward application without encountering basic issues like so.

One thing I would point out is, Microsoft, ever since WPF, has really disappointed loyal developers to their eco system and platform.

I personally think the issue that they face is largely because they are authoring frameworks that solve generic problems. Let me expand on that. Other companies like Facebook, Google, etc, all have now produced popular frameworks (React UI, Angular (in the past), Flutter, etc).

They were all born by a necessity, they needed something that they themselves could use, because they didn't feel what was on the market was good enough to meet their needs. As such, they heavily dog food their own products. Microsoft on the other hand, we have probably yet to see a serious MAUI application (I could be wrong, maybe there's one being developed still). You look at WPF same deal, really the only serious app they did with it was Visual Studio, and even then they probably customized, tweaked it a lot in order to achieve what they wanted, further to that I have no doubt they would have submitted a lot of suggestions onto the WPF team. This is really what Microsoft needs to do, more dog fooding.

Granted I am certain each team probably has their own liberty to choose the language, tools and frameworks they want to do, but without them mandating the use of MAUI and any of their other platforms, then the general dev community are left to be the guinea pigs and the only group of people that can drive change, and as you can see, the change is mega slow...

[phillip-haydon]

With Xamarin, after setting up VS, you can create a Xamarin project, and F5 it, and it runs. That's not the experience with MAUI. It complains about needing workloads, you install the workload, then it complains about another workflow, you install that, and it complains, eventually you install all required workloads, and it runs, and then you close the project, come back a week later, open it up, and it doesn't build...

Xamarin Forms at the time of acquisition worked better than MAUI does today. Period. MAUI has potential, but right now it just looks like another failed attempt from MS. Especially when AvaloniaUI and Uno Platform are far better. But unfortunately they aren't MS so stuck fighting with MAUI.

[Vroomer]

As for XF, something so basic as Margins or CarouselView was only introduced after acquisition. So much about XF back then being better than MAUI now. Period.

As for your workload issues, you should probably try to reinstall VS and .NET, if your workloads disappear without reasons. You can also consider raising an issue. I didn't hear anyone complaining about such problems and I've never encountered it myself.

[durandt]

I agree with @Vroomer that the acquisition of Xamarin and its subsequent release of source code improved quality a lot. I am not sure exactly in what shape Xamarin was at the acquisition but it wasn't great and I don't remember well enough to compare to todays MAUI.

What I can compare though is that, at the time, you had a handful of community devs (and a few Xamarin ones like James) that would answer on the forums and find some workaround for your issue. With the code being open source today and the size of the community, their are many more people able to find and share work-arounds and it's much easier to find them.

I agree a little with @phillip-haydon about the workload-stuff, the way the workloads work (at least on Mac) IS confusing. The installed workloads would look different on mac whether you installed them from VS or command-line, and VS would often prompt me to install workloads again although there were there just a few moments ago (on Mac, once again).
There is a discussion about understanding workloads here #6528 that David answered. I asked a few follow-up questions that were not answered though (but maybe I should have started a new thread).

Also, when you mention the Xamarin->MAUI transition, I think communication has been an issue. Many people who were committed to Xamarin understood it as "Soon decommissioning Xamarin, will be replaced by something better, MAUI" which: 1. Raised the expectations 2. Did not really explain why all this was necessary". The things you wrote @Vroomer about the need to leave Xamarin behind make sense and my guess was something around that. But I don't remember reading in from any official communication. Maybe it's a US-cultural thing that you don't talk bad about your own work, past present and future. But that creates some misunderstanding. Here in Europe where I am based I think we are used to more cynism and sincerity about our own work.

My point being: We would have needed a bit more communication, both about workloads and about the need for transition from Xamarin to MAUI.
I wished we had had a little longer support for Xamarin as well, so that the folks needing stability could have waited there for a bit longer until MAUI had matured enough for their needs. I perfectly understand that the team wants to focus all their effort on the main product rather sooner than later though.

[beglaryan-alen]

I mean there is MS products

[Vroomer]

@durandt I see how Workloads can be confusing, as there have been significant changes to them. Also, I can't say whether they work as intended on VS for Mac as I'm only using regular VS. Initially the idea was to have Workload tied to VS version and update Workload and project automatically together with VS. That obviously made it difficult to try preview versions or pin your project to an old version. For example to try preview versions you had to have installed VS Preview, update .NET preview and update VS Preview version or manually update Workload via CLI. In .NET 8 there was also a bug that caused .csproj <MauiVersion> not being respected for .NET 7 targets - I don't know if it's still present. Midway to .NET 8 they decided to make MAUI largely based on Nugets together with some bits in Workload, which is the current state. Now you can choose the version of MAUI (inc. nightly builds) by simply choosing Maui.Controls Nuget. You can either change $(MauiVersion) to a specific version in .csproj, choose it within Nuget Package Manager or keep $(MauiVersion) and set it via .csproj <MauiVersion>.

<PackageReference Include="Microsoft.Maui.Controls" Version="$(MauiVersion)" />
<PackageReference Include="Microsoft.Maui.Controls.Compatibility" Version="$(MauiVersion)" />

You don't need to update Workloads for new versions anymore, as long as you are on .NET 8 GA workload. There might occasionally be new MAUI versions requiring bump to workload in the future besides the yearly cycle, but that shouldn't be common as the Nugets carry almost all the stuff that is a subject to change.

As for the lack of information, I would recommend you to follow monthly MAUI Community StandUps on Youtube. I think the decision to move to MAUI was well explained in first episodes. You can also find some interesting more technical information on MAUI Discord.

I don't think the end of life date for Xamarin was set too early. The timeframe looked very reasonable on paper. It's just that nobody expected MAUI to be in its current state by now. When MAUI arrived in GA, it was only half baked, but the progress in those few months until .NET 7 GA seemed very rapid. I think most people had hopes that it will quickly turn around. However during .NET 8 they started hitting serious regressions. The breaking changes essentially resulted in abandoning .NET 7 servicing and focusing on .NET 8 previews. That left developers without any meaningful updates for about half a year apart from unstable .NET 8 previews or experimental main branch pipeline.

I think it's fair to say that the team made two major mistakes:

1. The idea of basing MAUI purely on Workloads was clearly wrong.
2. MAUI seriously lacked test coverage. A lot of Xamarin UI tests were not even ported to MAUI.

Thankfully both of those mistakes are now remedied. I think that Android and iOS will still be in good enough shape for Xamarin end of life. However developers in many cases have to start migrating in advance and in that case they are still likely to encounter some frustrating issues.

[robheffo79]

As THE mobile app developer at my company, the current state of MAUI scares me.

I develop apps for our clients, budgets are fixed and small.. I often encounter things in Xamarin Forms that in all reality should be a small thing to do but ends up in a hell of bug hunting and hacky work around that blows all profit in the job out of the water and we end up losing money.

Take one app for a good client of ours, an app they use to do inspections of infrastructure, taking photos of issues, adding findings and recommendations, sending back to the server where reports are generated and provided to the customer. I inherited it from an absolute abysmal developer in a poor state and have fought to bring it up to par.

My efforts turning the mess around have paid off in the client wants us to fork the app and modify it for a new branch of their business, great news, more billable hours for us! The problem is, with Forms being discontinued I need to port to MAUI. We have made the choice to port the existing app before we fork it, that way the app framework is still supported.

What scares me is how much time will I burn just getting the app ported, and back to parity with all the MAUI issues?

[activa]

This should give you a clue about what Microsoft thinks of MAUI. It's a job opening for a Principal Software Engineer (Mobile) at Microsoft.
Not a single mention of MAUI or Xamarin. Zero.

https://jobs.careers.microsoft.com/global/en/job/1661019/Principal-Software-Engineer-%E2%80%93-Mobile

[maonaoda]

If not, then MS should invent a new technology again and perhaps MS will then manage to keep step with other large companies.

not impossible, that is MS. We just some thing like test subject who using xamarin,maui...
What was the reason for choosing MS`s technology at the first time?

[true-perfect-code]

@jtorjo
You don't think that the money-hungry Microsoft managers develop the products, do you?
No, they are developers like you and me and most of them (if I understand correctly) do the work in Opensource for free.

If someone is frustrated about MAUI, then that is not fair to many developers who work hard day and night. Especially when some of the work is unpaid!

@maonaoda
I've been programming since 1985. Microsoft once hit the operating system. Unfortunately, everything else went wrong without exception, from IE browsers, to many .NET languages, mobile, various development technologies, etc.

I didn't even ask myself why that was, but I'm sure the answer is simple. You shouldn't think that you can invent a second wheel and then sell it well.

If microsoft had thought about it that way, the story would have been very different. let's assume NET. With NET, Microsoft wanted to create a platform that could compete with Java. If I were MS, I would have fully integrated Java into Microsoft and not invented NET! All the problems that have arisen over the last 20 years would not be there now and microsoft would probably be in a much better position than it is now.

But it is the way it is. If you can't live with it, you should choose something else. I am a fighter and have Microsoft to thank for my entire income. So I'm staying on board even though my retirement is still a long way off!

[jtorjo]

@true-perfect-code The devs that work for Microsoft on .Net MAUI do get paid, but they are too few. That's what this thread is all about.

[true-perfect-code]

@jtorjo
I now ask myself why it is so, after we all (including me) whined to Microsoft that NET had to be made public.

It's actually lucky that Microsoft hired (and paid) someone to do it!

[bigpilot]

I think both MAUI and Blazor need a rethink. Xamarin and MAUI have been in an unstable state for over a decade now and that's simply not acceptable for developers who need to make a living with these frameworks.

My suggestion would be to focus on .NET Android and .NET iOS and facilitating code re-use between the two and to abandon multi-platform MAUI.

Blazor needs to be a replacement for Javascript and not a UI framework.

[Xyncgas]

#https://github.com/dotnet/maui/discussions/17015

[tbprince]

Microsoft knows very well what to do to ship a development framework. If it doesn't do that, that's because it doesn't want to. It's not that they don't know.

MAUI could have been successful. Xamarin could have been (more) successful. WinUI, UWP... you name it. Microsoft did that for Windows Forms and WPF (and MFC before that). They know what to do.

A development framework should ship as stable and 99% complete since day ZERO. This game of shipping half-baked, uncommitted, lets-try-what-happens frameworks are completely unuseful and even dangerous. Incremental updates works for small features, not for core features. The very same day Microsoft announced MAUI, Xamarin became obsolete and other development frameworks aimed at building Windows applications became obsolete by design. Yet, two years later, MAUI is not feature complete nor stable, as messages in this thread prove.

Once you announce MAUI, no-one will invest in obsolete technologies and most developers will delay new projects to build upon MAUI. So Microsoft sank Xamarin and also other frameworks aimed at Windows apps. They knew that yet they announced something they perfectly knew it wouldn't be shipping feature complete so developers couldn't immediately replace Xamarin (or WPF or Windows Forms etc.) with this new framework so their choice was creating a new app with an already-obsolete technology (and accept the burden or having to port again at a later time) or skip MAUI stay put with the above-mentioned obsolete technology. None were good choices.

Since we have a couple of Xamarin-based apps we're on that boat too and we were just left asking what to do. Now that MAUI is out, Xamarin is not a sane choice for newer apps. If they don't invest in MAUI, how can we imagine that they will invest in "old" Xamarin?

At this moment, the only sane choice to build a Windows app is Windows Forms or WPF. And that's just crazy. Mobile? Xamarin, maybe, but going native seems the only good choice if we really need to write an important app.

The way you gain trust from developers for development framework is simple:

• announce the new framework
• release the new framework at the promised date. It must be 99% feature complete and include everything a sane Windows/Android/iOS developer would need to build a real application. No limitations, no "unsupported features", no "will-fix-it-later", no "workarounds", no "bugs";
• stop considering "incremental" features those that must be the core features of a development framework. That won't work. Developers don't want "workarounds" nor collection of hacks (at some time I think I heard you could use Blazor on the mobile to work around the limitations of MAUI. That's just crazy...);
• put enough resources to maintain the damn thing without free/underpaid work by the "community". If you gain adoption, someone might participate. Yet you won't gain adoption if you won't put enough resource to go on alone;
• announce that such new framework will be the supported way to build Windows/Android/iOS applications for the time being. Announce that you will support this new framework for 10 years, not a year less than that.

Everyone will simply start adopting the new framework and the supported way to build Windows / Android / iOS apps. End of the story.

Microsoft keeps "trying" by releasing uncommitted, unsupported, half-baked, unstable, bugged things in order to gain adoption without committing resources, people and time. Their goal is clear: they need to push people developing Android/iOS apps to build Windows apps as well.

That solution won't work unless you provide commitment to the bits you're launching everywhere in the room.

Every single attempt like the previous ones will simply build more skepticism into your platform. DO NOT try. Just do it. At this time, I know very few Windows developers that will think about building a new Windows applications using something other than Windows Forms or WPF. If you need a REAL, really important application it makes no sense to take this gamble using something else.

I recently spoke to a customer willing to port its long-time ago developed application to something more modern for Windows AND mobile. He simply said he won't take a gamble to do such a huge effort using any "late" Windows technologies or mobile technologies that Microsoft ships because they cannot risk that Microsoft will phase them out after one year or two and they don't trust such technologies anymore.

"If I ever decide to port this application to anything, I will only consider a Web port". BUT, his users won't like a Web-based application, they (rightfully) want something native. So they're struck but they prefer to evolve those old bits rather than entering into a madness of converting, porting, workarounds etc.

Look at this pearl:

The Desktop Guide documentation for .NET 7 and .NET 6 is under construction.

Yep, it's just been 2 years since .NET 6. No hurry. Let's just wait.

[stevefan1999-personal]

tl;dr: don't rush things out, perfect it first

[rsgilbert]

Keep up the great work folks!

[Strypper]

The new toolkit required net8 app? This is straight up comedy

[Mistofs]

I got a feeling they can and would internally work hard to make this toy better for themselves, crawled under the bedsheet because their product confidence is hurt, it needs to recover back before they can start addressing people's issues.

In other words MAUI is now in preview again.

[true-perfect-code]

@tbprince
I'm not defending Microsoft, I'm defending developers who put a lot of effort into delivering different tools (whether they are all employed by microsoft or not).

That's why it's really ugly to take all the frustration out on the developers, who can't help it that someone from the management floor of Microsoft wants to make a few percent more profit!

[phillip-haydon]

@true-perfect-code

Even if Apple or Google took over Microsoft, they probably wouldn't be able to do any better, because on the one hand you have to keep up with the technology and on the other hand it all has to be backwards compatible. The others don't have these problems for hystorical reasons.

This makes no sense.

Avalonia-UI is already better than MAUI
Xamarin is already better than MAUI
UNO is already better than MAUI

It's 100% possible Apple/Google could do better than MAUI.

[Atulin]

It's 100% possible Apple/Google could do better than MAUI.

You can cross Google out from this sentence, because Flutter exists and is quite pleasant to use. I'd even argue that Dart did some things C# could really learn from.

[true-perfect-code]

@phillip-haydon
If Avalonia and UNO are already better than MAUI, why don't you use Avalonia or UNO instead of constantly being angry about the development of MAUI?

[true-perfect-code]

@Atulin
Unfortunately, I can't say the same for Flutter. When there was the problem with the WebView component last year, I also wanted to get away from MAUI (Blazor inputs didn't work) and implemented a small project in Flutter. Personally, I didn't like the widget-based UI at all. No one can convince me that this Flutter widget should look more understandable to a developer than the same code in Razor/HTML.

Flutter

import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  @override
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Scaffold(
        appBar: AppBar(
          title: Text('My Flutter-App'),
        ),
        body: Center(
          child: Text(
            'Hi, Flutter!',
            style: TextStyle(fontSize: 24),
          ),
        ),
      ),
    );
  }
}

MAUI Blazor

@page "/"

<h3>My Blazor-App</h3>

<p>Hi, Blazor!</p>

[rsgilbert]

I think what we need to consider is the weight on Microsoft's shoulders.
They are working on so many projects. MAUI maybe important to you but it is just one of thousands of big projects maintained at Microsoft. Heck, its not even among the most profitable ones.
Microsoft, like all big companies is driven by data. Which product is selling the most? Which product has highest demand among the users? Which technology complements our already existing offerings?
Microsoft is not managed by software developers. Its not the coders who call the big shots. No, it is business men with MBAs. These business men comprise the middle management who report to their managers who report to their managers.
One thing I have come to learn about the cut-throat world of middle management is that they like to please their bosses. Products like MAUI that non-technical people do not understand do not look well on their reporting dashboards.

[true-perfect-code]

All the more reason for us to show respect to our Microsoft colleagues who put so much energy into development (MAUI, Blazor, ASP.NET, NET 8...).

[plettb]

Whereas this thread went in a number of different directions, the original message is one I strongly agree with.

I would think that creating an app in MAUI and getting the app into the Microsoft Store would be one of the most obvious use cases. However, I've been trying for months to get my MAUI app into the store and have had no success. I've posted messages on a variety of forums (including this one), as well as opened tickets with MS, all to no avail.

The thing that concerns me most is that I'm really starting to wonder, at this point, whether it can even be done! This could be solved with a simple, working tutorial of taking a simple "Hello world!" app through the entire process.

I'm at my wit's end and contemplating changing platforms despite my investment in first Xamarin and now MAUI.

[rsgilbert]

I am with you on the 'all to no avail' part.
I locked myself out of my Office 365 developer subscription a month ago. Something about deleting Terms of Conditions in Microsoft Entra Id. I opened tickets, support requests etc. I've never been helped.
The software looks promisingly good but what good is it to me if I cant be supported on a small problem like that?

[durandt]

I looks to me like all that could be said regarding this topic has been said and discussions are diverging farther and further from the issue at hand.

I therefore vote to close this issue from further comments.

[true-perfect-code]

That's exactly how I think!

MS developers may have made more mistakes than would be expected, but they (like us) are only human. Attacking the developers, most of which contribute to development free of charge, is not enough, you can only make the situation worse if you treat them without respect.

Instead, we should all make an effort to help make MAUI (or whatever) better and not constantly moan about how bad it is and how nothing can be done!

[Xyncgas]

You can express different views, assuming you are saying that you can already do.
You should not try to silent people, because you are having a different opinion than others, for example if I don't agree with what you said that's fine and if you are accusing me attacking you should take care to provide evidence for such claim

[Xyncgas]

In my opinion, going on to talk about silencing people by closing the conversation, continued to participate the narrative that's brought here, would be contradictory to the narrative itself, the fact one is allowed to suggest such a thing as to closing the conversation, silencing people's voices, demonstrates the counter opposite to the values I interpreted as 'keeping conversation healthy for this community'. The conversation one is trying to silence is also the space one is voicing their own opinions, it seems fair if one go ahead say whatever they want do whatever vote they want, meanwhile imo silencing people actually just sounds really absurd

[durandt]

Then do you care to share with us what you meant with the clown-emoji and how it participates in this discussion? (about closing the thread)

I'am OK with people disagreeing with me about closing this discussion and having a discussion about closing the thread in a grown-up manner.

[true-perfect-code]

@Xyncgas
My statement about reproach and respect was not directly addressed at you, but at all those who insult Microsoft developers.

Once again, I am in favor of everyone having the freedom to have their opinion. But I am not in favor of hunting people down under the premise of freedom of opinion, because that is a paradox in terms, which such people are not aware of and then "contaminate" this thread.

[Xyncgas]

Arc is on windows, written in swift
https://arc.net/

[Xyncgas]

This browser is a mothership set to make a return for all the web app

[ziomek64]

You're sometimes making some dumb responses dude, are you on drugs all the time? What does this have to do with the thread

[NCLnclNCL]

Use avalonia

[Strypper]

Look at these

Here are the responses from the Community Toolkit. It's important to recognize that MAUI is dependent on the toolkit, and it raises concerns that these contributors aren't compensated for their efforts. Where is the financial support from Microsoft for better maintenance?

[true-perfect-code]

@Vroomer
As far as I can figure here, there are few people who write a lot of negative posts about MAUI developers. Apart from the fact that it's not nice, the consequence is that such posts make the situation look much worse than it actually is. This can make new Maui developers feel very uncertain and that's a shame.

I'm not always happy with Microsoft products and frameworks either, but as has already been said here, either you change technology and look for something appropriate, or you bring patience or work with oder MAUI developers together.

[Vroomer]

@true-perfect-code To be honest the situation with MAUI is definitely bad and many developers including me are frustrated and rightfuly disappointed. Microsoft didn't commit enough resources and some poor decisions were made during MAUI's development, that further compromised the progress. The resuslt is that .NET 8 is how .NET 7 should look like and there are still many major issues left.

However it's fair to say that it does the job and thanks to the handler architecture, you can fix almost anything that doesn't work for you. If you have simple app, you will not encounter that many problems and if you have complex app, the handler architecture is massive advantage as it essentially lets you take full control of whatever native platform you are targeting. This means that you can do things you wouldn't be able to do with other cross platform frameworks.

As you said, there is just a few people who take any opportunity to bash MAUI, which creates eco chambers for others. A lot of the hate comes from the fact that many developers are not skilled in using MAUI and issues they encounter are their own mistakes or have very easy solutions. When they see posts like this (which has probably easy workaround as well), they immediately assume that MAUI is broken. You can also notice that many people berating MAUI are fans of competing technologies like Avalonia, who wants to stick it to us. :) At the end people think that MAUI is complete failure and start to invent all kinds of doom scenarios and absurd conspiracy theories about how Microsoft intentionally makes their product fail. MAUI's future is still very bright, the community is strong and the fixes are coming.

[true-perfect-code]

@Vroomer
from your lips to God's ears :)

[ivanjx]

a lot of people still don't understand what xamarin or maui is. they are just abstraction of native gui. if they just make it easier to integrate native controls from swift or java to c# then it will be good.

[Xyncgas]

Xamarin related technology try to find common grounds in different platform, the abstraction narrows the options of UI development the more platform it supports

if we instead target a single abstraction and implement it on different platform we eliminating the problems, creating a unified experience for us to write our UI on, Xamarin if try the route it has to implement a lot more features because the way it is now is far from being able to do procedure programming to get to the state of the interface you are trying to present to the people therefore your hands are tied when trying to implement visual studio's context menu using Xamarin

Browser is already cross platform, after webassembly can manipulate document object model efficiently we can use it instead, although it would seems a browser might be running more efficient if it's not using plain-text html but a new standard byte code format for UI that's trans-compilable to html + css + js then we are looking at making our own browser at Microsoft

[Alt-WN]

The section "Steps to reproduce" of THIS issue is empty. But it is easy to fill it out:

1. Raise any bug in MAUI.
2. See if Microsoft fixes it in a reasonable time.
3. If not, then it means this issue IS reproducible.

In my company we have: experience, code and libraries written in Microsoft/.net/C#. Now, I have got a task to develop a new application for video/voice recording and taking pictures with GPS tracking. The application needs to run primarily on Android and iOS (iPhone). As a second priority it would be nice if it can run on Windows, too. What framework/technology/language to use for it? I have chosen MAUI and just started to develop prototype and several screens. First I developed on Windows. Then I decided to test on Android: UI out of tune, list boxes with unvisible or unrefreshed items. After spending days to workaround issues, I received pretty acceptable (but not perfect) UI on Android. Then last week I started to test on iOS. And what? App icon covers 1/3 of bottom screen and impossible to press anything. Top panel narrowed to 2 pixels with impossibility to click it. Expanded list box items do not respond to events, but scroll list box down. Should I spend next weeks trying to workaround UI on iOS? And if I find acceptable solution on iOS will Android and Windows still work? I guess I need to escape from this blind corner. The earlier, the better. Helpful resources to make decision:
https://forums.theregister.com/forum/all/2023/11/29/microsoft_net_maui_devs_unhappy/

Any suggestions?

[Kalyxt]

Blazor hybrid app

[Xyncgas]

Blazor hybrid is really good because the UI is web but the program you are running is native
You can use blazor hybrid on Linux / Windows / Mac / IOS / Android
Basically you get the unified experience but you do not have to deal with any browser restrictions, you are liberated, the machine's hardware would be accessible