Why its like that? (MAUI product development progress)

[Laftek]

Hey everyone.

Firstly I just want to say that I respect how much effort is MAUI and ASP team putting to make MAUI a great product. Thanks for that!

On the other hand I am wondering why we see such a lack of bug fixing in commits history (comparing to pace of issues being reported every day)? Is the team shifting their focus somewhere else or there are no enough man power? What's the strategy?

I really mean no offense because I know what team did is such a great milestone but why the progress slowed down that much? Just trying to understand for the future consideration.

I really hope it will get more stable in .NET 7 because there is a great great potential!

@Redth @davidortinau

[manishbisen]

Yes even I notice this looking to commits time in .Net Maui repo.

[DoubleDBE]

I'm wondering this as well.

[GeraudFabien]

I'll try an answer. I'm not from MS or even a contributor but i read a lot of issues. And this is my understanding of what i read.
All the problem of maui is bound around native UI. Xamarin has the same problem than MAUI. Native UI are a hell to develop for a lot of reason:

• Limit customization : A lot of person wonder why Maui XAML is not has powerful than WPF, WinUI, UNO, ... . When you bound a control to the native control you have the agility to customize has much has the native control support. You can't add the feature you want. And some feature may behave differently or became very hard to support.
• Performances : A lot of people when they ear native ear performences. If for drawing one simple button it may be true. If you draw a page (A lot of control) it became the total opposite. And Maui has a lot of work to do to ensure this doesn't result in an unusable framework.
• Behavior differences for any OS version : Any update of any supported version may add breaking change. And Maui must adapt. Even some minor Android version has breaking UI change. The worst is maui customize the control for you. In exchange it tend to make you depend more on the native behavior. So the probability a minor bug impact you a lot is greater than with just using the drawing control
• Predefined style and different unit : Each OS has it's predefined choice. Unit or default style. Maui has to convert all the Unit and default to get somethinks uniform. But it cant be complex. For instance even if the Unit seems the same it may depend from where the calcul start and end (eg. Assume you want to fix a size of a control. But in os foo the size take count of the border and in foo2 no. Even with the same unit it became really complex)
• New version each year: Every year a new version for each OS came out to complexify all that. And to maintain they title of best native framework they must integrate all the new feature day one and so priories feature over bug fix.

The result event draw a simple picture was a challenge for the team. And has far i follow they can't display a simple grid without bug. And they have a lot of performance problem. In the same time the community start looking at UNO and Avalonia who grow. Or to quit .Net with Flutter or Angular. All this solution support Linux and web that maui has an hard time supporting (Linux hasn't really a native look and Web is really totally different with HTML than other framework and supporting natively web would mean convert to HTML and it's nearly impossible)

They is also a second problem. A lot of feature are done only to lock the community inside of MS Stack. No vscode support but work has been spend on it and the support was drop in the way.
They start to make https://github.com/dotnet/Microsoft.Maui.Graphics.Controls but doesn't support it. Even through the community was interested (I'm not I would prefer MS help UNO integrate inside of MAUI so that UNO control can be used in MAUI)

[Laftek]

I agree native path is not the easy one. Having said that if someone does not care about having native UI then I guess Blazor (and Graphics.Control once is mature) is a solid choice. I wish they use Blazor as entry point to Linux support with MAUI.

[Xyncgas]

Maui supports blazor? Also native performance is true relative to blazor wasm, because instead of using blazor wasm you are using MAUI, which gives you threads and System.Security.Cryptography and SIMD when you are running MAUI.Blazor

[manishbisen]

@jfversluis @jamesmontemagno can answer this.

[GeraudFabien]

Please don't @ the PM uselessly. If they want to answer they answer. Spamming they cause more harm than good.

[davidortinau]

We always want a quicker pace, so I'm with you on that!

Improving quality is our top priority during this initial release phase, and that includes bug fixes plus release infrastructure, automated testing, process and product coordination, and more. Not all of that shows up as a commit in the log, but is just as important if not more.

Also, I want to make sure you are tracking the right commit activity. There is a lot of activity spread across branches. main branch is now the .NET 7 release upcoming, and net6.0 is the ongoing servicing of .NET 6 releases.

[Laftek]

Thank you David for your answer, I appreciate it.

I didn't realize there is different branch for servicing so now it makes sense, thanks for clearing this out.

Keep up the good work!

[manishbisen]

Thanks @davidortinau for taking time to update us on this.Really appreciate.

[Xyncgas]

MAUI is amazing, it would be more awesome if we can use it on Windows Phone