Replies: 15 comments 51 replies
|
Performance improvements. But i'm still on .Net 9.
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. |
|
Hi @jfversluis, |
|
Looking into #28552 specifically, thats the one you mean, right? |
|
@jfversluis It is this issue: #32987 |
|
@jfversluis Next issue is ready for you : #33037 :-) |
|
@AlleSchonWeg can you provide a bit more context? A fix looks to have been merged when using Shell in .NET 10 SR6. Are you not on that version yet or not using Shell? |
|
#15203 (reply in thread) |
|
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!?) |
|
|
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! |
|
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:
UPDATE: |
|
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. |
|
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? |
|
Hi! Thank you for the feedback - it’s really appreciated! Cheers! |
|
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. 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. |
|
@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. |
|
Exactly! I've described my issues in: #34568 (comment) |
|
I agree with the enterprise criticism. Enterprises move pretty slowly, to the point where even the overlap of dotnet LTS supported versions themselves is arguably insufficient - especially with directives like the EU CRA coming into force. Perhaps MAUI is still a bit too bleeding edge for LTS yet, but it would be great if at some point we could get the MAUI major version support timeline to match up with the dotnet SDK and runtime. |
|
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.
|
|
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? |
|
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.
|
|
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 👍 |
|
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! |
|
I also ran into issues with popups, so I ended up creating a separate page and navigating between pages instead of using popups. |
|
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. |
|
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. |
|
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. |
|
By the way, publishg a MAUI app as an APK file for Android is broken in the recent version of Visual Studio (https://developercommunity.visualstudio.com/t/Android-APK-install-fails-with--124-reso/11092830). It suddenly stopped working and VS creates a corrupted APK file. Publishg as an AAB bundle, which is much more important, fortunately works. But this shows that there are quite a lot of regression errors in 2026. |
|
Things are getting better and better with MAUI I think. Carrying on from my 2025 comment, a lot of the things I mentioned there still apply. However, there has been some great progress in a whole bunch of areas... DeviceRunners has apparently reached the point where it can be used in conjunction with XAML source generation has since landed and is, IMHO, a much saner approach on how compiling XAML should work. Community Toolkit improvements have significantly simplified custom controls. e.g. bindable property source generators allowed me to drop thousands of lines of boilerplate. There's some exciting stuff in the pipelines too... I've found that build-run-test cycle times are dramatically improved on non-Windows platforms with dotnet 11 preview and the switch to CoreCLR by default However, the very most exciting thing for me is the potential for a proper macOS backend! My biggest gripe is that Catalyst is riddled with issues that Apple refuse to fix (or even acknowledge). This could be the thing that elevates MAUI to be properly usable on Apple desktop without all the performance/reliability/accessibility baggage of Catalyst. I've given it a whirl from https://www.nuget.org/packages/Platform.Maui.MacOS and it's looking sooo good already. Thanks for your awesome work there @Redth! I can't wait for some official MS preview NuGets to drop, I really really hope this one makes it out of labs to first class support. As a fallback there's an Avalonia MAUI backend which is in active development, so there's another potential option there. But official MAUI macOS support would be wildly preferable to me at least. |
|
Regression in .NET MAUI 10.0.80 list looks smaller (better) too or mobile devs are on vacation 🔢 |
|
(Android) SR9 TOTALLY broke everything... I have never experienced a service release such as SR9 in my Xamarin/Maui life! It seems to be related to the Shadow changes... As anything that has a ripple drawable in the background emits debug errors and doesn't produce that effect if you add a shadow... Even the standard Maui button!!! Also, have they changed the underlying "wrapper" control, say if you create a control derived from ContentViewHandler? As it complains about duplicate Shadow objects and fails to draw properly. Stuck on SR8... I suspect that any bug report(s) created will be "back-logged" as the sprint for Maui 11 is near. |
|
The team should change their regression release management. The problem is, if a regression is reported it takes to long to create a release with a fix. Normally the fix comes with the nest SR. But in the next SR there are a lot of other fixes which creates other regressions. |
Perhaps it would be a good idea to have a period (a week?) before an upcoming new MAUI release when people would test for regressions and report them. Perhaps that's less costly than creating a new patch release. |
|
That would be great. But also the previous approach worked well - when the release has regressions (which was quite often in 2026), a hotfix version has been released soon, fixing only the reported regressions without any other significant changes that could break something else. This is how it used to be done and I think it worked well. However it seems that this tradition ends with 10.0.90 because it has been released 3 weeks ago. I guess we need to wait for SR10, hope it fixes the regressions and doesn't introduce new ones. |
|
Thanks for all the suggestions. There are many things to consider here which I won't bore you with. I assure you that we do whatever we can to minimize regressions wherever we can, including the period before a MAUI release where we test it. Is it perfect? As we all have seen, it's not, but not because we're not trying. And because of all that testing and the periods etc. it's not always as simple as putting together a hotfix for the next day, release it without any testing and hoping for the best. It's hard to get this right, on the one hand you're asking for better testing (which will take longer) and on the other hand we need to release faster (which most likely means less testing). We're continuously monitoring how things are going and where we can improve both quality and the processes around it. The other thing I'm sure you're aware of is the complexity of a product like MAUI. What could really help on your side is that if you are waiting on that long awaited fix and you see movement is to not wait for the release, but try it out on a nightly, or the artifacts of the PR and let us know right away when something doesn't look right. That way you can be ensured that the thing you're waiting for actually works when the release comes.
There is no tradition, nor do I think this should be a tradition. It's an emergency solution for some scenarios that we have seen where we want to help you ASAP. Of course; we do always want to help you ASAP, but it's just not always possible. And in this case it might just have been as simple as: it's summer for most of the people on the team and that means people have some time off. It's not like we're planning to have a regular release and then plan for a hotfix, they typically should not be necessary, but they have been for a couple of releases, but it's not a given. Don't get me wrong: I don't want to dismiss your frustrations, quite the opposite in fact, I hear you and we're working on it, just a bit of background information. We're just people too that are working on this :) Having all that said, SR10 is here for you now: https://github.com/dotnet/maui/releases/tag/10.0.100 let us know! |
|
Are we getting SR10 this week? The releases have been dragging their feet for months now. |
|
Through the use of AI we have a MUCH higher throughput, look at https://agentic-engineers.net/dashboard/. So fixes (and new things) come much faster than before. From the top of my head "before AI" our time to merge a PR was 6 weeks on average and now it's 6 days or less. We even have cases where it was less than 24 hours. Just to give you an idea: if you report something, hopefully with a reproduction, just seeing that the reproduction is not a security risk, pull it down, make sure we have the right SDKs, build it, deploy it, etc. is 30 minutes, easy and that is a low estimate. And then we just have it running on 1 platform. Then we need to figure out what it is that we're looking at. Is it indeed an issue, is the user maybe doing something they shouldn't is this specific to one platform, to all platforms? Was this a regression, so was this code touched recently? Maybe an iOS/Android update broke this, etc. etc. You are in the cross-platform/mobile development game, you know how it is :) that took a long time and that's even before thinking about a fix. That all became much easier with Copilot. That also means we can go much faster as I already said. Going much faster also means more regressions if we just look at volume. However, when you look at the regression percentage-wise, it's the same as it was before. So at least we didn't make that worse. Copilot is now doing the same level of development as us, but much faster. Of course the next obvious improvement we want to make is: less regressions so that it does a better job than us and faster. Having that said: if you finally get that new release and there is (YET ANOTHER GRMBL GRBML MAUI TEAM) regression and you still can't upgrade I understand how frustrating that is. As for: why not smaller releases and test better. This might come out a little more harsh than I actually mean it: but I don't think you understand the things we have to deal with at a big corporation like Microsoft. The overhead of making smaller releases and just testing better makes this pretty much impossible, or well, nothing is impossible, but it's just not worth it. Multiple teams are involved, and sign-offs and pipelines (which run hours for a build by the way), and the actual testing which is the same for each release whether it's big or small just to make sure nothing unintentionally broke, make it not worth it to go through all of that for just a small thing. One thing you could do of course is hop on our nightly feed and as fixes go in that you might be waiting for try them out and let us know before it's released so that it never ends up in a release and you know it won't cause any trouble for your production versions. That would be very valuable to us. And I probably don't have to tell you that .NET MAUI is an incredible complex product with a large codebase and so many moving parts. As mentioned: it might not even be something we did, sometimes it's an iOS update that will mess things up. We already have tens of thousands of tests varying from unit tests to UI tests to device tests, people manually going through things but it's just impossible to test every single scenario out there. And then I didn't even touch on the scenario where you might have built a workaround because a bug has been around forever (which I'm not very proud of) and then we finally fix it and now you think we did a regression simple because we fixed the actual thing and now your workaround is causing a bug 😄 All of this is in no way an excuse that you should stop asking these questions and challenge us, I just want to explain a little bit from behind the scenes. If it was as easy as just test better and just go faster and do better quality, we would have done that years ago. I'm very proud of our team and I love everyone of them and I have never worked with people that are so passionate about a product as these folks. They are putting in many more hours than required to constantly make the experience better one bug at a time.
Sorry that slipped through, responded on that PR to not mix things up here. We will look at those regressions and others that might come in and fix those asap! While these thread and comments are not always the easiest to read they are super important, and in this case for you @rokmeglicbit specifically you have been super helpful with indeed actually testing things out, providing feedback that also greatly speed things up. This is basically better than any testing we can do. So that's the only thing I ask: please keep doing that to you and everyone and let's move forward. I think that we're already in a so much better place than week, months and certainly years ago and we're in a better position than ever before. Let's improve even further and I'm sure we can get to a place where this won't be an issue anymore. 🙏 |
Thank you, but nugets are still missing as far as I can see. |
|
@jarlem There are right there...? https://www.nuget.org/packages/Microsoft.Maui.Controls/10.0.100 |
|
Nuget package is available. I was able to update MAUI yesterday in VS without any problems. |
Sorry, I had the nightly's installed and they did not show up. My bad :-) All good now. |
|
Interesting question. It would be good to see simpler iOS publishing and smoother tooling overall. Also, for students looking for updates, 11th Result BISE Multan is another useful topic to keep an eye on. |
|
Interesting question. It would be good to see simpler iOS publishing and smoother tooling overall. Also, for students looking for updates, 11th Result BISE Multan is another useful topic to keep an eye on. |
Uh oh!
There was an error while loading. Please reload this page.
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.
All reactions