Is NET MAUI the future of cross platform development? We recently caught up with Ryan Gant from Bottle Rocket to find out. Developers can now use a unified framework supporting Android, iOS, Windows, Web, and Mac. It promises improved performance and seamless cross-platform development.
Well, it depends how you want to look at it. The TL;DR is the number of outstanding bugs has grown.
I remember in the early MAUI days when people were commenting about there being 2000 open issues - there’s now nearly 3,500 open issues. A lot of issues have been closed - there was a period where several I was waiting for got fixed - but even more new ones are getting reported as people transition from Xamarin. A lot of them aren’t “reliability bugs” in the sense that it makes the app crash, but there’s a whole bunch more missing functionality.
Quite frankly I’m surprised they sunsetted Xamarin as planned. All along I was thinking “there’s no way that’s gonna happen on that date with this amount of bugs still open”, but yep, they went ahead and did it anyway. If it were up to me I’d still be using Xamarin, but I don’t have that choice (hence starting up this community to try and reassemble everyone from the Xamarin forum days, and let’s get to helping each other out with our bugs and workarounds - I already got 1 solution to a problem from someone here).
To give an idea of the missing functionality (which was working in Xamarin) you still can’t bind to properties in your ToolbarItems, cause there’s no properties there to bind to! The issue for that is now 2 years old. We were told that we can use handlers for that, but there’s no documentation on how to do that (I raised an issue for that too a few weeks ago). As I said, that’s not one that causes your app to crash, but you still can’t do what you could do in Xamarin yet, so the ToolbarItems look out of place with the rest of your app. FlyoutMenu still has issues too.
And a bunch of those bugs are for shell, which nobody wants anyway, but for some unknown reason they want people to use it. And newbies don’t know the difference and will raise an issue for “shell” when in actual fact it’s not an issue with shell but with the root MAUI control. The bug I mentioned before about ToolbarItems was initially raised as being a bug in shell, but the bug is actually in ToolbarItems. They should just kill off shell and focus on fixing the actual MAUI bugs.
Thanks for the explanation! I recall something sort of similar happening years ago with Microsoft recommending WPF over WebForms even when it didn’t have all the same functionality or data controls yet. But at least they had different design considerations, separation of concerns and stuff. Still not quite sure what the different design ideas behind Xamarin and Maui is, but I probably have to actually try Maui to figure it out. Going purely by reading, it just seemed like the same purpose as Xamarin, so it didn’t seem like big enough impetus to learn something new yet and I haven’t been pushed to yet from an outside source, like my work. But I’m sure I’ll have to eventually if I keep working in industry places that like Microsoft enterprise software frameworks.
Still not quite sure what the different design ideas behind Xamarin and Maui is
Xamarin had separate projects for each platform, whereas they’re all together in MAUI. Also Xamarin was tied to .NET Standard 2.1, whereas MAUI uses the latest .NET releases (starting with 5 or 6 - I’m now on 8). MAUI major releases now come out at the same time as Visual Studio updates. Also, as mentioned, MAUI uses handlers, but I’m still trying to work out how you actually use one to create a property (sigh). There was a few, annoying, breaking changes too. e.g. in Xamarin I could define the span and height of an element in a Grid with a single command, but now I have to use two (for some bizarre reason setting the column span is now entirely separate. I ended up writing my own function so I could do it all in 1 line again).
“The improvements they’ve incorporated into .NET MAUI indicate that it’s more reliable than Xamarin”
BWAHAHAHA! 🤣🤣🤣 😡😡😡 I don’t know who this guy is, but he doesn’t seem to know much about MAUI/Xamarin other than a blurb someone has given him.
I haven’t looked into Maui yet, but is not more reliable than Xamarin yet?
Well, it depends how you want to look at it. The TL;DR is the number of outstanding bugs has grown.
I remember in the early MAUI days when people were commenting about there being 2000 open issues - there’s now nearly 3,500 open issues. A lot of issues have been closed - there was a period where several I was waiting for got fixed - but even more new ones are getting reported as people transition from Xamarin. A lot of them aren’t “reliability bugs” in the sense that it makes the app crash, but there’s a whole bunch more missing functionality.
Quite frankly I’m surprised they sunsetted Xamarin as planned. All along I was thinking “there’s no way that’s gonna happen on that date with this amount of bugs still open”, but yep, they went ahead and did it anyway. If it were up to me I’d still be using Xamarin, but I don’t have that choice (hence starting up this community to try and reassemble everyone from the Xamarin forum days, and let’s get to helping each other out with our bugs and workarounds - I already got 1 solution to a problem from someone here).
To give an idea of the missing functionality (which was working in Xamarin) you still can’t bind to properties in your ToolbarItems, cause there’s no properties there to bind to! The issue for that is now 2 years old. We were told that we can use handlers for that, but there’s no documentation on how to do that (I raised an issue for that too a few weeks ago). As I said, that’s not one that causes your app to crash, but you still can’t do what you could do in Xamarin yet, so the ToolbarItems look out of place with the rest of your app. FlyoutMenu still has issues too.
And a bunch of those bugs are for shell, which nobody wants anyway, but for some unknown reason they want people to use it. And newbies don’t know the difference and will raise an issue for “shell” when in actual fact it’s not an issue with shell but with the root MAUI control. The bug I mentioned before about ToolbarItems was initially raised as being a bug in shell, but the bug is actually in ToolbarItems. They should just kill off shell and focus on fixing the actual MAUI bugs.
Thanks for the explanation! I recall something sort of similar happening years ago with Microsoft recommending WPF over WebForms even when it didn’t have all the same functionality or data controls yet. But at least they had different design considerations, separation of concerns and stuff. Still not quite sure what the different design ideas behind Xamarin and Maui is, but I probably have to actually try Maui to figure it out. Going purely by reading, it just seemed like the same purpose as Xamarin, so it didn’t seem like big enough impetus to learn something new yet and I haven’t been pushed to yet from an outside source, like my work. But I’m sure I’ll have to eventually if I keep working in industry places that like Microsoft enterprise software frameworks.
Xamarin had separate projects for each platform, whereas they’re all together in MAUI. Also Xamarin was tied to .NET Standard 2.1, whereas MAUI uses the latest .NET releases (starting with 5 or 6 - I’m now on 8). MAUI major releases now come out at the same time as Visual Studio updates. Also, as mentioned, MAUI uses handlers, but I’m still trying to work out how you actually use one to create a property (sigh). There was a few, annoying, breaking changes too. e.g. in Xamarin I could define the span and height of an element in a Grid with a single command, but now I have to use two (for some bizarre reason setting the column span is now entirely separate. I ended up writing my own function so I could do it all in 1 line again).