I'm a little confused. Can anyone explain exactly what the difference is between the two? When should we use MAUI and when UNO?
As I realized, both can run on different platforms, so what is the reason for introducing two different technologies at the same time? Can they run on Windows 7? Or are they just limited to Windows 10? Can my WPF program run on Linux with these two technologies?
UPDATE: Dec 1, 2023
For those who want a more up-to-date perspective, check out this GitHub issue thread about the developer dissatisfaction with MAUI. Also note that there are a couple of comments about Avalonia on mobile as well. In the last three years, UNO has continued to mature and get more stable with each minor release.
UPDATE: Aug 9, 2020
I've worked with the production release of Maui long enough that I thought I might share an update to my original post. Below are some criteria that I have used to compare the two platforms:
- Migration from Xamarin.Forms: MAUI wins - unless your project needs access to the native layer. Accessing the native layer on UNO is significantly more straight forward. If you have more than one or two native interfaces, UNO might be less painful in the long run.
- Devices / Platforms supported: UNO wins here:
- UNO: iOS, Android, Windows UWP, MacOS, MacOS-Catalyst, Windows WPF, Window WinUI, WebAssembly, Linux GtK.
- MAUI: iOS, Android, Windows UWP (MacOS and Blazor support is still pending)
- WinUI and Windows Community Toolkit (WCT): The SDK surface (number of widgets) of WinUI is much greater than what MAUI offers. Adding WCT makes this a slam dunk.
- Maturity: In most cases, this is why I choose UNO (I have chosen MAUI when porting very simple Xamarin.Forms apps, with mixed results). UNO has the benefit of 5+ years of development while the paint is still drying on MAUI. For me, this has meant my MAUI projects have had the kind of bugs and build problems that I used to see with Xamarin.Forms 3+ years ago.
And there's one more thing I might add - a bit of analysis. One thing I didn't consider when I originally wrote this post is why the development experience with UNO seemed less fraught with issues. Now that I've learned more, it's quite simple: DOG FOODING. Microsoft doesn't use Xamarin.Forms for any of its products and, to date, that's also true for MAUI. However, nVentive (UNO's parent), created UNO specifically to solve a problem for their business. It appears that they use it a lot. And, I'm starting to see it out in the wild in places I would have never expected, like the Nuget Package Explorer built into NuGet.org. Here's a link for those of you that can appreciate a little irony.
ORIGINAL POST:
I've been developing with Xamarin.Forms (to be renamed MAUI) for 5+ years and Uno Platform for soon to be four months. There are a number of differences that, to me, made it worth my time to move from Xamarin.Forms to Uno. First, the similarities:
- Both are C# Cross Platform Frameworks
- Both have XAML support
- Both Support iOS, Android, Universal Windows Platform, and (to a lessor extent) Mac OS via the non-.Forms Xamarin platform frameworks.
- Xamarin.Essentials works with both Xamarin and Uno on the above platforms
- Neither have built-in support for Printing, PDF generation, or PNG generation.
Now the differences:
- Architecturally, Xamarin.Forms is its own abstraction layer above the native APIs where as Uno builds UWP interfaces upon the native APIs. This is, in my mind the most important difference for three reasons:
- In Android, Xamarin.Forms abstraction includes the measurement and layout management. This is VERY EXPENSIVE and, for all but the most simple of list views, results in very poor performance. Uno, by contrast, performs this in the native layer - thus avoiding a magnitude of passing back and forth between Java and C#.
- In WASM, Xamarin renders via Blazor - which enables hybrid server / client applications. Unfortunately, this adds complexity when compared to the approach Uno has taken. It is yet to be seen if the Xamarin approach has a performance penalty.
- Because Uno builds UWP upon the native UI frameworks, it's pretty straight forward to open up the covers and make deep changes in function. It's much more difficult (if not impossible in some cases) to do that in Xamarin.Forms.
- Uno has strong support for WPF (so yes, it can run in Windows 7), Tizen, and and Linux (GTK).
- Uno supports the complexity of UWP XAML - which, if you're experienced with WPF or UWP, has some major advantages. Otherwise, it will be lost on you, as it has been on me. I'm hoping to change that.
- Uno supports WinUI and Windows Community Toolkit libraries.
- Although I cannot be sure of this, I believe Xamarin.Forms has been around for about 2-3 years longer than Uno Platform. That being said, Uno has quickly caught up to Xamarin in function and code quality. I believe this is, in part because of having UWP as very mature operating spec.
- In my experience of migrating a project of ~132k lines of Xamarin.Forms code to Uno, Uno was significantly less verbose, at ~65k lines. Almost all of that reduction was in lines of UI code (the models, view models, and business logic was almost untouched). This was largely due to the how much more feature rich UWP (Uno) controls can be.
Lastly, you asked if you your WPF program can run on Linux with these two technologies. The answer is
- Xamarin.Forms: No. Linux is not supported;
- Uno Platform: No, but it is possible to migrate your code. The effort would be about the same as porting your program from WPF to UWP.
Your mileage may vary. However, if you have experience with WPF or UWP, I would highly recommend Uno. If you have experience with neither, then I would recommend Uno because of the superior performance with Android.