How are things in 2026?

[Mimisss]

Inspired by the How are things in 2025? discussion.

So, how is MAUI doing in 2026?

Is it growing strong or not? Any cool packages worth mentioning?

And are we going to see any major improvements? For example, the process of publishing for iOS could be heavily improved, IMHO.

[AlleSchonWeg]

Performance improvements. But i'm still on .Net 9.
.Net 10 in 2026 introduced new "features" which created new trouble:

• EdgeToEdge in Android (Statusbar color, ModalPages, TabbedPage)
• iOS 26 liquid glass (LargeTitels, TitleView)
• iOS CV2

Issues and PR's created for almost every issue, but merging is still very slow. Focus is more on ai, automatic pr review and repository statistic.
As a result, more open issues and a lot of open pull requests.

[jfversluis]

@AlleSchonWeg We have been able to merge these:

• NavigationPage TitleView iOS 26 (NavigationPage TitleView iOS 26 #32200)
• iOS Large Title display disappears (iOS Large Title display disappears #33037)
• [iOS 26] ToolbarItem color with custom BarTextColor not working ([iOS 26] ToolbarItem color with custom BarTextColor not working #33970)
• [Android] TabbedPage BottomNavigation BarBackgroundColor not extending to system navigation bar in edge-to-edge ([Android] TabbedPage BottomNavigation BarBackgroundColor does not extend to system navigation bar area in Edge-to-Edge mode #33344 / [Android] Fix for TabbedPage BottomNavigation BarBackgroundColor not extending to system navigation bar #33428)
• iOS CollectionView ItemsLayout change not respected with CollectionViewHandler2 (iOS CollectionView doesn't respect a change to ItemsLayout when using Items2.CollectionViewHandler2 #31259)

I think they should all land in SR5, might be SR6.

We're still working on:

• StatusBar and FlyoutBackground wrong color on Android (StatusBar and FlyoutBackground wrong color on Android #32987)
• [NET 9 regression] Changing StatusBar and NavigationBar background color doesn't work with Modal pages ([NET 9 regression] Changing StatusBar and NavigationBar background color doesn't work with Modal pages #28552)

The latter likely isn’t a .NET MAUI regression but a platform change in Android 15+ (API 35).
Android now enforces edge-to-edge rendering, and APIs like Window.setStatusBarColor() and Window.setNavigationBarColor() are deprecated and may be ignored. The system bars are transparent by default, and apps are expected to draw their background behind them.

Because of this, setting system bar colors directly (via MAUI, toolkit, or native code) may have no effect on newer Android versions.
The recommended approach is to render edge-to-edge and control the visible color through the page/layout background combined with safe areas: https://learn.microsoft.com/dotnet/maui/user-interface/safe-area?view=net-maui-10.0.

Using MAUI safe areas allows the layout background to determine the visible color behind the status/navigation bars, which aligns with the new Android model.

Let us know your findings and what else we can do for you

[AlleSchonWeg]

@jfversluis
Thank you very much for your work on these issues. The merging pace is very good and i hope with the next sr releases a lot of issues will be fixed. I think a lot of users will be happy!

I'm aware that EdgeToEdge is no MAUI regression. Also liquid glass is from Apple and not from Maui.
I think the statusbar color problem occurs when you use a NavigationPage.TitleView. The titleview is a MaterialToolbar in Android and perhaps the insets are not set correctly on the native MaterialToolbar. As you wrote the Statusbar is now transparent and as a result the primaryColor in the androidmanifest.xml becomes visible.

[AlleSchonWeg]

Hi @jfversluis,
any news about progress on the StatusBar/SafeArea issues? I tried some workaround (setting colorPrimary in manifest for example) but without success. Sometimes it works with normal pages but breaks with modal pages or it doesn't work with older android api (API < 34).

[jfversluis]

Looking into #28552 specifically, thats the one you mean, right?

[AlleSchonWeg]

@jfversluis It is this issue: #32987

[Xyncgas]

#15203 (reply in thread)
Antigravity + redot is the butter
AI can be knife to butter but instead of address MAUI's failure people are pointing to artificial intelligence to fix everything which looks bad because then why not use AI writing an app in natural language and have agent verify the result by giving them emulators of android and ios and comparing screenshot / pdf

[Xynratron]

Review / Retest on every platform consumes most of my time. A Real-Time Click on every platform-emulator would be very nice, but currently we have to wait many seconde between every click / touch to see the next screen (Emulator / Simulator are realy slow). All at the same time with hot reload to review the changes?

An easy to use and implement frontent test framework may be the first step: Testers can define a step-through and AI-Agents can verify. Maybe 2029? (or proof me wrong! Is there someting around!?)

[Xyncgas]

[jfversluis]

Not sure what those badges say about how well things are going. MAUI is a complex codebase running tens of thousands of UI/unit/device/integration tests. Some of these are flaky by nature. We can run them in such a way that it looks green there, but that would not help anyone I think. In fact, I don't think this is any useful indication of anything, so I just removed them. Thanks for the nudge!

[holecekp]

MAUI is great and I would definitely recommend it. About a year ago (I'm not sure when exactly), I noticed a significant improvement in the speed of releasing bug fixes. However, the year 2026 didn't started well. MAUI needed to tackle the edge-to-edge mode, which is required for targetting Android 16. This introduced a great amount of bugs in the .NET 10 version. The following service releases in 2026 fixed some of them but often introducing regressions. If you use Android, it's safer to stay with .NET 9 for a while. However, I'm optimistic because the current pace of bug fixing is quite good.

Version 10.0.41 is the first .NET 10 version that could be usable for me in the production on Android with a few workarounds. I released a new version that is based on it to the beta testers today.

Here are the main difficulties I've experienced for different platforms as of 2026:

• Android (.NET 10) - Incorrect background and icons colors for the status bar - to make things even worse, they differ depending on your Android version and if a modal page is opened. Shell doesn't fully support edge-to-edge mode, there are visual bugs especially in the landscape mode, even though the serious ones were fixed in the latest MAUI version. Rendering speed for a grouped CollectionView is not ideal (both .NET 9 and 10).
• Windows - Publishing is not fully supported in VS and I need to use the command line (VS can create only MSIX, which is refused by Micorsoft Store because I used MSIXBUNDLE for Xamarin.Forms version in the past).
• iOS - there are much more issues compared to Android. Many of them are visual and layout bugs when a visibility of a control is changed at run time or when the screen is rotated. The most serious ones have been fixed at the end of 2025 and beginning of 2026. Some still remain. For example, if I rotate the device to the landscape mode and then back to the portrait mode, the safe-area stops working and moreover one of the tabs disappears. Turning the display off with the power button and turning it on again returns everything to the correct state. Also requiring a certain XCode version is not comfortable. When VS or something else is updated, running on iOS stops working unless I download and install a newer XCode version (which can be an hour or even more depending on the Internet connection speed). The setup for Pair-to-Mac is also very difficult in general.

UPDATE:
Unfortunately, MAUI's bad luck in 2026 hasn't been broken and is getting even worse. Version 10.0.50 introduced another serious regression. This has been fixed a week ago, but the fixed version (10.0.51) isn't publicly available and there is no information when it will be released. So to answer the question about the current state in 2026 - thinks got much worse compared to 2025 and the Q1 of 2026 was a time of constant regressions and other bugs that makes it difficult to use in the production. I wish it will improve in the rest of 2026.

[Xynratron]

For Windows: I have a .targets File to build bundles (had the same problem last year, I think this one: #22445 (comment)) - but for .net10 my sideloading packets for testers are broken.
Windows-Store itself has no prio at microsoft since years.

[Xynratron]

MAUI is a great Idea, but not a solution for an Enterprise.

We had a Xamarin-App for many years. Needed to port it to MAUI. Now needed to port to .net10.

In an Enterprise driven environment the Idea of changing the Framework every 12 months is terrible. That is a Microsoft decision, but .net10 is only till 2028. The Problem: the changes are very fast and you cannot establish stability. From .net 8-9-10 the Bindings changed, you have to correct everything and let it go to the complete Enterprise Review Process. There are no 2-Weeks Reviews. We do our sprints in that time, but a product review?

Current State: .net9.0 worked fine, Update to .net10 broke too much. We are not finished with the migration now and .net9 Support ends in Nov2026. We are not allowed to ship after Support. Nice.. one Year for everything. (to be clear: .net10: release Nov2025, .net9 Support End: Nov2026)

Suggestion: New / Breaking Changes not for the "cool new .net Release" - .net 10 broke too much to be feature complete till Nov this year.

You are not stable on .net10 till now! How can we update?

[kubaflo]

Hi! Thank you for the feedback - it’s really appreciated!
The key question is: what is preventing you from shipping on .NET 10 today?
If you can share the specific issues or breaking changes you're hitting, we can take a closer look. Maybe we can address them or fix them in an upcoming release.

Cheers!

[Xynratron]

Problems with iOS. Things work on Windows / Android but break at iOS. And may not be our c# code in the ViewModels?

Example: We have an Issue with "IsVisible" set to false leads iOs to not display a Page. I filed a bug for the Syncfusion-Team, but that does not seem the whole story.
Maybe if you see something similar, it looks more to be an issue with "View.IsVisible" on iOS. (because, If I set it on a sourounding ContentView, it also breaks rendering without any Exception)

Next Example: I have an Layout Control to do a Wrapping & Sizeing of Child Controls (very close to the Microsoft Example Documentation) -> perfect at .net9, works at Windows & Android at .net10; breaks on iOS -> Loop for Measure() whithout a LayoutCycleEcxeption

I dislike the Idea of filing Bugs without proper investigation. I will provide it, if I have a reduced the example for the team to investigate it ( and I can be sure it's not my fault ;-) )

To reduce the Syncfuison-Problem to a small project I needed ~8h. (Extract from main project, copy everything to have it compiling, remove, remove, revert, remove etc.)

So: I expect stability.

[Xynratron]

@kubaflo I have to correct myself - both problems seem to have the root cause at the Syncfusion - work in progress, workaround available. So yes: i dislike to say "there is a problem" without a full proof ;-) and apologize - I think my wording was too rude yesterday.

But my main concern remains: don't run too fast to new features, maintain stability.

[petthreer]

Exactly! I've described my issues in: #34568 (comment)

[DarthDeville]

Hi, Can we now reliably use Edge-to-Edge (true fullscreen) on Android — at minimum translucent system and navigation bars? On .NET 9, I’m currently using a small plugin that works well across both normal pages and modal pages (including Mopups and MPowerKit). Edge-to-edge works consistently for me up to Android 15 without issues. When I initially tested .NET 10 (around Nov 2025), this was the first blocker I encountered — edge-to-edge behaviour was inconsistent, which ultimately forced me to revert back to .NET 9. I appreciate that everyone has different use cases and it’s difficult to track every scenario, but a definitive answer regarding this specific Android edge-to-edge scenario would really help determine whether I can safely ship on .NET 10. Thanks in advance for any clarification!

…

On 3 Mar 2026, at 00:24, Jakub Florkowski ***@***.***> wrote: Hi! Thank you for the feedback - it’s really appreciated! The key question is: what is preventing you from shipping on .NET 10 today? If you can share the specific issues or breaking changes you're hitting, we can take a closer look. Maybe we can address them or fix them in an upcoming release. Cheers! — Reply to this email directly, view it on GitHub <#34171 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BOKZA7QSATJIQ3AM7SUSSCL4OYQ3XAVCNFSM6AAAAACV3JERMGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOJXHA2TENA>. You are receiving this because you commented.

[kubaflo]

HI! You can try this: https://learn.microsoft.com/en-us/dotnet/maui/user-interface/safe-area?view=net-maui-10.0

[Mimisss]

Am I the only one who thinks that Edge-to-edge is a terrible idea as far as UI and HCI (Human Computer Interaction) is concerned?

[DarthDeville]

Thank you so much for getting back to me so soon and appreciate the link which I have had a look at and at first glance if this works I will be over to .net 10 quicker than I thought! Much appreciated and now I have to burn the midnight oil and try to get this to work. Regards

…

On 3 Mar 2026, at 14:47, Jakub Florkowski ***@***.***> wrote: HI! You can try this: https://learn.microsoft.com/en-us/dotnet/maui/user-interface/safe-area?view=net-maui-10.0 — Reply to this email directly, view it on GitHub <#34171 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BOKZA7QGXJAC62KZU7RIYVT4O3V63AVCNFSM6AAAAACV3JERMGVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKOJYGYYDAMA>. You are receiving this because you commented.

[skha83]

I really hope #32878 gets merged and a fix for #32125 gets implemented for SR6. With the type of app I'm developing, we might only release one or two updates per year to app stores. So everything needs to work 100% when we release, we can't just make a new release 3 days or a month later with a fix to some UI elements appearance, as this process is very costly and time consuming. So waiting more than 4-6 months to get basic UI elements to a working state, like the issues I linked, is not ideal.

The next release will be our first using .NET 10. It has required a decent amount of refactoring. Especially in the dialog/popup logic, because the refactoring of Popups in MAUI.CommunityToolkit, required us to find another popup solution, which were compatible with our current navigation framework. Together with the long running compatibility issues with UI components in iOS 26, it has been a lot of both work and waiting time for fixes, without adding any new value to the app, other than to keep it compliant with different App Store SDK requirements.

I agree that the pace and momentum in the repository seems to be picking up, so I hope it will continue to improve 👍

[jfversluis]

Absolutely agree, we're actively working on the issue you mention and the bigger picture here. So keep bringing us the things you need and we'll have a look!

[petthreer]

I also ran into issues with popups, so I ended up creating a separate page and navigating between pages instead of using popups.
I was using a popup together with a dropdown selection component from Telerik (the paid version), but that combination didn’t work at all—and with each update, it seemed to get worse.
I’ve experienced the same “workflow” you described since the Xamarin.Forms days. Every update meant spending weeks fixing the entire app’s UI.
There was even a period before/after .NET MAUI was released when basic components like CollectionView didn’t work properly in most use cases.

[holecekp]

I've released a new version of the app based on .NET 10 but it didn't go well. I had to halt the rollout because the new version crashes in TypedBinding with InvalidOperation_HandleIsNotInitialized. This worked well in .NET 9.

[holecekp]

For anyone having the same problem - it seems to be caused by AsyncRelayCommand together with changes in MAUI in .NET 10 version. AsyncRelayCommand calls CanExecuteChanged internally after the command execution finishes. If it's used for a Button and it becomes unavailable, the command execution crashes the app with InvalidOperation_HandleIsNotInitialized.

According to ChatGPT (I didn't verify), .NET 9 failed silently in these cases while .NET 10 can crash. This is a really awkward issue becuase it's almost impossible to guard against all cases when the original Button is not available after a long-running task finishes.

I fixed this by adding AsyncRelayCommandOptions.AllowConcurrentExecutions to all AsyncRelayCommands. This prevents CanExecuteChanged to be called. Instead, I'm guarding agains the concurrent command evaluation myself manually. This however added a lot of boiler plate code. I've released a new version with this fix and I'm testing if it works. I didn't report this issue anywhere becuase this is one of the bugs that appears randomly and is very difficult to reproduce.

[holecekp]

I've released the new version with the workaround for AsyncRelayCommand occasionally randomly crashing. Unfortunatelly, it didn't fix the problem. There are fewer crashes but calling CanExecuteChanged in general can crash .NET 10 MAUI with InvalidOperation_HandleIsNotInitialized. Reported for both Android and Windows. It worked well in .NET 9. I recommend caution when upgrading MAUI to .NET 10, if you use CommunityToolkit.Mvvm.