How was your most recent experience with MAUI XAML for Mobile Apps as of January 2024?

[azrinsani]

I'd like to do a Poll to see the sentiments around MAUI Xaml for Mobile Apps

Your sentiments should be based on your MOST RECENT experience with MAUI XAML for Mobile App and not > 6 months ago where we can agree it was not perfect at launch.

I would like to limit this Poll specific to MAUI Xaml Mobile Apps only. It seems like the sentiments around MAUI Blazor are positive.

I have purposely made it into 4 options to reduce subjectivity.

From Microsoft's official documentation, Xamarin support will end in May this year. Many including myself are still undecided whether we should spend hours battling MAUI bugs or port our existing Apps to Flutter.

Hope this poll will help many of the undecided. Cheers!

Also, I would highly appreciate it if you help spread this poll to your groups or forums!

[azrinsani]

The results so far are rather appalling. With almost 50% of responders having negative "intolerable" experiences, your project stands a 50/50 chance to potentially fail...

[ziomek64]

Over 60 now

[azrinsani]

I was only referring to the 'Negative' rating which was ~50% 5 days ago.
I would take 'Slightly Negative' as something still acceptable. Any framework would have small hiccups.

[yyliveyy]

Setting aside the issue of bugs:

1. Linux is not supported

2. Desktop platforms have lower support than mobile platforms (which is puzzling) and cannot support large-scale desktop level development. For example, the most commonly used DATAGRID on desktop platforms actually does not support it.

   It is very disappointing that those who work on desktop systems can make the desktop platform look like this.

3. Declarative programming is not supported.

[Xyncgas]

XAML was declarative
Procedural and functional programming is not supported There should be a state like browser's DOM

[Overdrive77]

As a hobbyist, .Net MAUI is pretty good and has some neat little features, I’m playing with some WinUI and Android projects. At the same time… MAUI .Net 8 still contains some annoying bugs, but nowhere near as bad as .Net 6 and 7. It's stable enough for small projects.

Now, from a business perspective.
I have several large Xamarin Forms projects which has many users. Since Microsoft pushed in favour for .Net MAUI, Xamarin Forms to me has become neglected, kicked to the curb. I’m now unable to upgrade Xamarin Forms as it breaks our existing projects beyond repair (thankfully have source backups!)

The other real annoyance with Xamarin is I’m stuck on VS 2019 which I cannot upgrade and haven’t upgraded for quite some time, as again it’s breaks Xamarin Forms! And when I’m dealing with customer integrations and fixes etc, I don’t expect to have to battle VS too!

So, now I’m pressured to migrate to MAUI .Net 8 (seeing as Xamarin will be discontinued May this year. For the love of... No, just no!)

I’ve tried using the migration tool to little success.
Through frustration, I’m rewriting each project in .Net MAUI line-by-line, class-by-class. I’m also having to waste hours overcoming existing MAUI bugs. In addition there’s features that should be ‘out of the box’ but instead you have to install 3rd party packages just to do one task. In addition, there’s some things in Xamarin that could be done in Android native but is no longer accessible in MAUI.

My stress and frustration is through the roof! I still believe Microsoft was premature marking MAUI production ready. I think that move should've been done at .Net 9.

This whole experience has been a total sh?t show. I've used VS since pre .Net, and never have I been so disappointed.

[robertmaxted]

I just want to know why on earth they are killing Xamarin may 2024 When .NET MAUI is not nearly ready for all of us with existing Xamarin.forms applications. Not to mention that VS code is absolute trash (for us devs that have used visual studio for so long) and we now have no choice but to use that (On Mac) - or Rider, which is not great. I would quite literally pay $500 per year to keep Xamarin forms and visual studio for Mac "alive". The thing is, I would happily use .NET MAUI for a new application. But, for all of us that require working packages for things like firebase (of which the only viable plugin is messy to say the least) have no choice but to move to MAUI, when it is almost impossible for complex applications!! What are Microsoft thinking!? Start charging for visual studio Mac and watch how many of us (devs) subscribe to it, obviously keeping Xamarin.forms alive.. @davidortinau @jamesmontemagno @jfversluis @maddymontaquila @jsuarezruiz

Please keep Xamarin.forms alive. start a poll, see how many of us will pay to keep it, just for another year or two! Maui (plus packages) is not ready for existing migration of MANY of our apps. Please consider this folks.

Failing that, please just at least extend the deadline by one year. This will give most of us (the community) enough time to get packages etc all sorted.

[raselldev]

with the same language (C#), re-writing xamarin form to net maui is painfull

[Overdrive77]

I stated above that MAUI .Net 8 is stable enough for small projects. I wish to apologies as this is no longer the case as I've just discovered it's not stable enough!

After writing a simple class library containing commonly used components and custom Xaml views, the inner bindings of those views breaks when referenced in the main application.

In addition Shell Navigation displays blank white pages when navigating (I had a tab with 4 simple content pages with content!!!)...

x:Name="XYZ" XYZ throws object reference as its null when accessed from code behind.

Cross compatibility is a headache as it runs ok on Android and breaks on Windows, and fixing Windows breaks Android. Yeah write once, deploy on multiple platforms sounds very inaccurate now.

I am now seriously reconsidering whether to continue using MAUI or just drop it altogether for something that actually does what it says on the tin.

[codeaphex]

@davidortinau this is the same experience I have, using a custom control library breaks the whole app, some controls render on the first page, but if I use them on another page the whole screen is white. If I replace them with default control the page will be rendered. It's there some magic thing missing in our libraries? I saw members of the Maui team writing control libraries and guess actually using them, but I don't know how much this is tested.
I'm not using shell navigation btw, since it was also broken multiple times in the past.

[AndrewMaisey]

In the end we almost lost a customer due to the appalling mess that is .NET MAUI. It failed to render CollectionViews correctly, code was slow and unresponsive to run, the promise of cross-platform compatibility ('one code base for all') did not materialise and we had to go back to platform specific sections.

I also wasted a huge amount of time simply getting Visual Studio to connect to my Mac build host. Problems which I reflected to the relevant teams but went almost completely ignored - many of these bugs are still present as of writing this. It takes 80% of the time to work through the tooling, bugs and end-platform differences, 20% actually to work on the app itself.

As a product I could use reliably in a commercial setting, MAUI is not fit for purpose.

[Kalyxt]

Its too soon to cut off support for Xamarin Forms but I found that MAUI hybrid is the way to go when you have problem with certain controls. Also there is new Skia rendering library for MAUI with few controls which I had to try, demo was great.

[MatthewKapteyn]

Looked at porting a 'mid-sized' Android/iOS Xamarin Forms project over to Maui last year and it was clear things weren't ready so we waited. Completed the migration a few weeks ago for Android. 20+ hours to get this far and we haven't touched an iOS build yet.

The good:
Skiasharp and FFImageLoading are very useful projects and good to see working with Maui today. Most of the old XAML outside of some namespace tweaks works fairly well oob.

The bad:
Annoying issues that required workarounds with Xamarin were unfortunate to see again in Maui. e.g. backbutton behaviors, a nullable datetime picker, a native image control that doesn't tank performance to name a few.

If you had extensive custom renderers - too bad. The upgrade assistant support that had been promised early during Maui development - didn't do much and hasn't been updated in 2 years. Instead replaced with a DIY checklist.

In short, seeing Xamarin support being dropped so quickly is alarming and should be reconsidered.

[davidortinau]

The .NET Upgrade Assistant is updated regularly. Latest release was 2 weeks ago. https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.upgradeassistant

Yes, the assistant will not do anything with custom renderers, and will not result in a working application. There are manual steps everyone will need to complete that require decisions only you can make.

Congrats on completing your Android upgrade.

[MatthewKapteyn]

Thanks for the reply, I hadn't realized the upgrade-assistant repo had been deprecated and moved to an extension. I'll be sure to try that on the next migration that's coming up in a few months.

[unamed000]

Here is my experience from spending about 60 hours to port a big-sized project from Xamarin.Forms to MAUI (and we failed). The project was mainly using Xamarin.Forms and the old Navigation Page system.

• The most impression thing is when building for iOS, the project took more than 1 minute to deploy on my M1 Pro laptop for every single changes! Which is significant slower than Xamarin.Forms old project.
• First we need to deal with MAUI Handlers, we have around 15 custom renderers in the old projects that we have to port into Handlers .... well it does costs time, but not big deal!
• TouchEffect in Xamarin community does not get supported, so we have to workaround the entire project with the new gesture recognizer and our "handmade" long click gesture recognizers then re-implement the whole 200 XAML files (or more). Well .... that's still acceptable!
• With FFImageLoading, there are some libraries which has been ported, but the port is not 100% aligned with the old ones, there are still some APIs that missing, like the ability to embed Authorization token in the HTTP Client or the Invalidate the caching. Oops ... we will skip that for now. Let's wait for MAUI team to add official FFImageLoading.
• Then the biggest issue, which we decide to DROP the migration and choosing another platform. Which is the collection view:
  -- Our app depends heavily on the CollectionView with the very complex layout inside
  -- The header of the collectionView on MAUI does not get re-caculated when the height is changed, which make it's overlapping with the content.
  -- The size of each item view size differently and not correctly comparing with Xamarin.Forms, for example: If Item 1 should be allocated 100pt for it's layout and Item 10 should only be: 50pt. When user scroll to Item 10, it will somehow allocate 100pt instead of 50pt and vice versa. And there is no workaround for that.
• Another very big issue is unlike Xamarin.Forms, which support to do the UI on iOS Share extension. MAUI has no official way to embed an iOS extension inside the project. And for iOS Extension, there is no way to embed a MAUI application in there! Which force us to develop EVERYTHING for that extension again by using Xamarin.iOS (by native APIs)

So, that's why I decided to give up the migration part at this state. We're observing the state of MAUI and the EOL of Xamarin. If they force the EOL of Xamarin as they stated. We will might just pick another framework

[AlleSchonWeg]

We also decided to pause the migration. The main problem for us are animations. If an animation is running over a longer time the android app crashes. As a CV we used the DevExpress component. But many more problems with fonts, shadows, toolbaritems, switches ...
I hope MS extend the XF EOL. At the moment we can't release an app with maui.

[AlphaNERD-]

Well… between the lack of a XAML designer, issues working with binding libraries suddenly not working anymore, getting used to a new software that is NOT an IDE replacement… How is this supposed to replace Xamarin?

I work on an app which communicates with mobile thermal printers and they come with their own native SDKs. All of these are wrapped in their own platform specific binding project. The binding libraries for Android didn‘t exactly work until i started building them separately. 2 of my binding libraries for iOS still refuse to work. According to a support agent from Microsoft the static libraries were only built for simulator even though they worked fine on physical iOS devices within Xamarin.iOS.

.NET Meteor has proven itself to be more reliable than Microsoft‘s own MAUI debugger in VS Code. And it doesn‘t cut off variable contents after about 100 characters. Too bad it doesn‘t bring back the missing NuGet Package Manager, the SDK Manager or even just some proper project management. I had to install multiple plugins to get some features back that i had in VS for Mac.

And then i still won‘t be able to easily modify UIs for Xamarin iOS, Android or even just XAML. Hot Reload doesn‘t replace a WYSIWYG editor. I want to merge my Xamarin projects into one single .NET 8 project once the migration is done to really use .NET 8‘s full potential. Without a WYSIWYG editor this will take probably weeks longer than it already will with an editor.

And don‘t get me started on Azure DevOps and Microsoft App Center.