Suggestion - extend Xamarin EOL until MAUI is Production Ready #15222
Replies: 10 comments 20 replies
-
|
I agree with this, one more year of support could make a lot of difference. Because of the Xamarin EOL we've taken the plunge to MAUI but it's a painful process at the moment and rather frustrating when we have a perfectly functional Xamarin version already in production. We have testers asking why the new update has more jank/bugs than the old version - so a huge portion of the work is in ironing out or working around MAUI specific issues which will hopefully start to disappear in the coming months. |
Beta Was this translation helpful? Give feedback.
-
|
.NET 8 is literally their chance to prove MAUI works, if they fail to satisfy the developers people deserve one more year of Xamarin support at least, it is microsoft's product that binds mincrosoft to its developers and its eco system and it's more than just open source project |
Beta Was this translation helpful? Give feedback.
-
|
Yes, well this will eventually be the case - but right now, .NET 8 and MAUI for .NET 8 are in beta and that's certainly not a commercially acceptable way forward for those migrating their apps right now - in fact it just adds another big moving target and considerable cost to migration work. There's also a lot of confusion as to what bugs are even being fixed for .NET7 MAUI vs what is being done in .NET8 (bar looking through piles of commits and bug reports). |
Beta Was this translation helpful? Give feedback.
-
|
Microsoft please what is your decision on this request for EOL extension? The reviews I just read about Maui online are horrible!!!, but Microsoft keeps advertising the platform. |
Beta Was this translation helpful? Give feedback.
-
|
We‘re about to migrate from XF to MAUI .NET 7 and I came to the point that the product is in an unusable state for us to continue. We tried the latest preview 2 of .NET 8 too and it‘s not significantly better. It would take a lot of time to mention all problems, so I skip this here. Most of the issues were already reported by other users anyway. For us its pretty clear, we will keep Xamarin untill the very end of its lifetime. If MAUI is not stable enough on May 1, 2024, we have to say good bye to C# mobile development. |
Beta Was this translation helpful? Give feedback.
-
|
With Xamarin.Forms you can build and release apps with iOS 17 Android 14, if you don't need to use, new Android 14, iOS 17 API because if i understand correctly Microsoft not release binding for it. https://dotnet.microsoft.com/en-us/platform/support/policy/xamarin |
Beta Was this translation helpful? Give feedback.
-
|
It will be very obvious and natural that we will all rush to another non-microsoft mobile platform to save our apps, if Microsoft ends Xamarin.Forms pre-maturely. |
Beta Was this translation helpful? Give feedback.
-
|
I think it makes far more sense for Microsoft to just invest the resources to get MAUI up to par and make it happen. There is still 7 months to end of service on Xamarin. That is plenty of time to fix the major bugs if they are interested to do so. I think the high level bugs like in complex systems like CollectionView are less important as we can code our own management and virtualization solutions. However, we do need Label/Editor/Border/Layout/Shadow/Image at the bare minimum working. I don't see why 7 months shouldn't be enough to get those working. MAUI was released in May 2022. It has now been 1.5 years since it was released. It will be 2 years since MAUI was released by the time Xamarin is retired. If they can't get MAUI working by then, it is not a matter of time, it is a matter of mismanagement or underfunding by Microsoft which is an intentional choice they are then making. Dragging this out further will not solve those issues. A software product made by a multi-trillion dollar corporation (yes trillion - Microsoft is worth $2.439 TRILLION) should absolutely be expected to be functional by 2 years after it was officially released. There is no good excuse it should not be. Excuses solve nothing and there are no valid excuses when you are a company with $72 billion profit in 2023 alone. This is not some small Internet startup company. It is one of the richest and most successful companies on earth. We need MAUI working so we can move forward and make successful projects. |
Beta Was this translation helpful? Give feedback.
-
|
My words, 100%. It will not be a matter of time in May 2024. It will just be too late if things in MAUI don‘t work better by then. We‘re a multi-million CHF development project and our investors will not wait for .NET 9 to arrive. It‘s a bad situation. |
Beta Was this translation helpful? Give feedback.
-
|
'why can't you programmer figure it out things yourself but you had to wait for other people to do it for you' is what I am hearing from investors I say we can rely on .NET for basic things like memory safety and cool things like reflections and dynamic typing interoperability, but for application domain I guess besides ASP.NET we need to do everything ourselves instead of relying on projects like xamarin, or maybe even ASP.NET shouldn't be used and instead servers use custom solution like custom protocol over IP and custom UI library this way we can truly be blamed for not studied enough in school to make things happen for the money we took |
Beta Was this translation helpful? Give feedback.
-
|
It looks like (if I'm not mistaken) there is some sort of EOL extension here now(?) allowing compiling against iOS17/Android14 which should provide some more breathing room so I think that's good news (and sensible decision from Microsoft). After many delays, I'm a month and a bit into migration of a major client project from Xamarin to MAUI right now (one of the bigger ones that needed to be tackled) - and wanted to share this experience/thoughts if it helps anyone. Most important bit of advice : would highly recommend that 3rd party MAUI component suites (like Telerik) are used & are essential if you have a complex UX - much of the MAUI controls offering are simply not Production ready. Otherwise you'll just waste tons of budget trying to do workarounds - and you'll actually save the client money (overall) just biting the bullet on this. This means .NET7 MAUI is the only option right now (as these 3rd parties won't touch .NET8 until it's at GA. This is particularly the case for List/Collection Views which are a complete trainwreck if using the OOB ones, but similar for a lot of other components too. Also, finding Android .NET7 (in combination with these 3rd party controls) is starting to feel a lot more stable, the SR8 release last week 'automagically' fixed a bunch of issues (even ones with 3rd party controls), most likely due to further fixes to Grid sizing problems (particularly handling of * and Auto sizing) which these controls relied on too. It's by no means perfect/fixed yet though, but it is a big improvement on a couple of weeks ago. The iOS .NET7 is still pretty bad/messy (and don't set the bar too high there right now) - again a lot of it comes back to the Grid sizing issues (and margins/padding not being observed too) which don't seem to have improved with SR8. I'm really hoping when .NET8 appears then it will be a lot better a situation. Another key bit of advice is to not spend too much time chasing workarounds just yet, just flag broken UX stuff for later investigation and work on what you can so the entire dev effort doesn't come to a complete halt. Many of these would just be wasted effort if platform fixes sort them out anyhow. Hopefully things will improve a lot for .NET8 final release - although apparently the beta's of this have a lot of issues still. So in a nutshell though - don't expect/plan on releasing anything to PROD for .NET7 right now, and plan with your clients to (hopefully) around timeframes of 'early next year' instead (by which time you may or may not need to allow for some workarounds for outstanding things). On a good note, we managed to get some DevOps pipelines working for Android .NET7 builds (win-latest) which included using private Nuget repo (req by Telerik controls). Another colleague has a combined pipeline also working for Android & iOS (using single mac-latest vm) so it seems that bit is achievable too. Hope that helps others plan/proceed! Just don't set your expectations too high just yet - particularly for iOS releases. cheers |
Beta Was this translation helpful? Give feedback.
-
|
We will reply later with more insights but I'd like to add that we are now evaluating release 8.0.14 and pre release of version 9 of different devices. In the coming days we will be gathering more insights through testing on identical devices with different version of XF and MAUI. |
Beta Was this translation helpful? Give feedback.
-
|
If you have specific scenarios and examples that aren't covered in existing open issues related to lists (CollectionView primarily) and performance, please add them. Improving this is a top goal for .NET 8 servicing releases. For immediate needs where perf is most impactful to the app experience, we are seeing devs have good success swapping in VirtualListView. |
Beta Was this translation helpful? Give feedback.
-
|
@davidortinau |
Beta Was this translation helpful? Give feedback.
-
|
@mobilewares if you can file issues with a There are already some improvements, that are mostly focused on what we saw scrolling a
But some of these help all platforms. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the replies. It's quite a bit more involved/complicated - we specifically need functionality like grouping/load more, headers etc etc - so we've had to use 3rd party controls from Syncfusion & Telerik for the large lists throughout our App. The CollectionView has always been hugely problematic in past (as per the many bugs in past 12 months) so we stayed right away from that too, even for scenarios where it was a regular list. I see same issues on both 3rd party components (SfListView & RadListView) - and at the end of the day it really appears to be the rendering of the items - and I'm pretty sure if I used a collection view would see same performance issues. Our ItemTemplates are unfortunately quite complex layouts with a lot of elements including imagery - client business requirements for the App means we don't have any choice on that - and as mentioned we are exactly reproducing the same layouts as we had for their current XF product which ran very smoothly in same scenarios. The XF version of the App in fact had far less optimized layouts & not much compiled binding either - it wasn't ever needed. The rest of the App definitely seems more sluggish as well (compared to XF) - there's not any one thing I can directly put a finger on - just overall seems to be rendering at much lower frame rate, slower to initialize content on pages and glitchy/flickery etc - see this is on latest iPhone Pro Max too (main testing device) so it's not due to lack of powerful device. These other things aren't show-stoppers, but noticeable to anyone who will transition to the MAUI version after being a heavy previous user of the XF one. If I get a chance/budget from the client I will have a look at doing some profiling - but as above I really think it just comes down to slower UI rendering performance of MAUI vs XF which is compounded when there is a huge amount of complex content. |
Beta Was this translation helpful? Give feedback.
-
|
The only thing I'm aware of that is inherently slower in MAUI (at an architectural level) is: Overall though, I've seen MAUI generally outperform Xamarin.Forms such as: So as much as we can: file issues with |
Beta Was this translation helpful? Give feedback.
-
|
@AlleSchonWeg if you're using skia for lottie animations, check out: mono/SkiaSharp.Extended#250 ...which is one of dozens of known leaks fixable with: https://github.com/AdamEssenmacher/MemoryToolkit.Maui
Have you come across my writeup + repro app in my memory toolkit linked above, which showcases MAUI's systemic memory leak issues? It's definitely an architecture problem. The first noticeable effect of these leaks (especially on iOS) is often UI stutters as a direct result of thrashing, eventually followed by a crash when the OS inevitably kills it. It takes a lot before "hello world" or demo apps hit this threshold, but it's really easy for real-world apps to encounter this situation. And yes, it's worse on MAUI. |
Beta Was this translation helpful? Give feedback.
-
|
I just checked, and they both appear to be fixed in the nightly build. Awesome! I want to stress that my original comment was in response to your statement:
While it's great to see individual leaks getting fixed, what I'm trying to communicate is that developers are really struggling due to the cascading effect leaks have when they occur. Realistically, a few leaking borders should not be a big deal. The problem is when a single leaky control does make into a view, everything leaks. This is an architectural problem. It makes developing MAUI apps extremely unforgiving. Once encountered, apps are doomed to suffer responsiveness issues (due to thrashing) before inevitably crashing. This issue is exacerbated by a separate architectural problem, which concerns ...so there you go. Two architectural issues with real, demonstrable impact on performance making MAUI apps inherently slower than Xamarin. |
Beta Was this translation helpful? Give feedback.
-
|
Right, I don't think "inherently slower" is the same thing as the handler lifecycle. I was not involved in the design there, so I don't know why some of the decisions around handlers were made. I am generally not a fan of handlers; I listed some of my complains on this comment: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the insight! We can call it 'emergently slower' if it helps 😂 The bottom line is that MAUI's 'production-readiness' is still highly questionable. These memory issues are what completely derailed my own (still incomplete) migration from Xamarin, and I've heard the same from quite a few happy users of the memory toolkit (115+ stars in 3 months...) If you care to take a peek, I also include a really simple sample app in the toolkit that shows how, out of the box, the GC in iOS.NET is practically useless under really basic conditions. It's been a struggle. |
Beta Was this translation helpful? Give feedback.
-
To be fair, this is the same behavior as Xamarin.iOS and MonoTouch, see: |
Beta Was this translation helpful? Give feedback.
-
|
...and yet, the GC in a Xamarin.Forms port of the sample app has no problem reclaiming memory! MAUI version after several push/pop cycles: Xamarin port: I'm acutely aware of the ref counting concerns in both Xamarin.iOS and iOS.NET. This isn't that. |
Beta Was this translation helpful? Give feedback.
-
|
Honestly the AI generated boilerplate codes for each specific platform can be the true cross platform solution Imagine having a build process that turns natural language or domain specific language into IOS / Android / Windows / Linux application that looks the way you described and its functionalities are tested Instead for people writing MAUI program the AI model is run on a server to generate the app and test the app it generates while reducing cost for companies (paying robot to write code gotta be cheaper than paying human) |
Beta Was this translation helpful? Give feedback.
-
Hi All,
Like some of you I've been working on a mix of MAUI side projects over past 24 months (to gain experience) as well as ongoing/established commercial Xamarin projects for clients & am quite concerned by the current state of this new replacement platform.
Unfortunately the clock is ticking for Xamarin projects - the EOL for Xamarin iOS/Android OS (and no support for future OS updates) means existing Xamarin projects absolutely have to be migrated from Xamarin to MAUI by ~April/24 for iOS and ~August/24 for Android - otherwise updates will not be accepted by the respective App stores.
Not migrating the commercial Xamarin projects to MAUI (or something else) ahead of this deadline is not an option right now for clients - as it's commercially unacceptable to have a scenario where critical App updates and new features can't be deployed to their customers if needed.
I'm having the (difficult) conversation now with clients about the impending migration deadline & the need for them to invest in the migration soon, but extremely concerned about the current state of production readiness of MAUI. My clients have made significant financial investment in their existing Xamarin applications over past few years - so the suggestion to migrate to completely different platform (ie. Flutter, Blazor etc etc) instead of what should be a cheaper incremental migration to MAUI isn't a commercially agreeable option.
I totally appreciate the difficulties the MAUI team face right now (and am thankful for their hard work) - a very small/undersized team dealing with an increasingly huge backlog of bugs and a moving targets (.NET versions, rapidly updating OS versions/features) - plus the difficulty of rolling out updates without regressing existing working functionality. I'm hopeful this is going to get better - however 'better' vs actual 'Production ready' are two different worlds here. I'm not overly confident this will happen well in advance of the migration deadlines, which is the timeline we all need given migration work of complex Apps need to happen soon and be completed in time.
So I'm proposing a different approach/lifeline : add one more year to the Xamarin EOL date (currently May 1, 2024). That way iOS17 and Android 15 would get supported by Xamarin - giving the MAUI team an additional 12 months to get the new platform truly production ready & existing Xamarin Apps another year of life. Obviously this would need more investment by Microsoft in Xamarin (which may seem counter productive given the need for MAUI funding) - but I think this increasingly becoming a necessity given the huge amount of existing Xamarin applications out there.
Anyhow - that's my 2 cents worth. I'd really appreciate any feedback/response from the Microsoft folks on here who might have the ability to make this happen & appreciate the current state of play.
thanks
Niall
Beta Was this translation helpful? Give feedback.
All reactions