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.

你的里程可能会有所不同。不过，如果你有WPF或UWP的经验，我会强烈推荐Uno。如果你两者都没有经验，那么我会推荐Uno，因为Android的上级性能。

另一个不同的观点是，此时此刻，您只能将UNO与Xamarin.Forms所做的进行比较。如果您是MAUI团队的一员，那么您应该照亮这条路，但我不是。您真的不知道正在进行哪些结构性更改以提高性能，而最近Microsoft非常重视性能-所以我猜他们肯定会在Java/C#划分上下功夫。
另一件要考虑的事情是，MAUI是一个微软的API，UNO是不是（现在）我们知道在未来，微软倾向于买断技术，他们喜欢和适合的愿景。
如果你现在需要跨平台开发，你正在比较现在可用的UNO和Xamarin. Forms。如果MAUI没有被推迟，它将于2021年发布。
现在来回答你真实的的问题：你现在可以使用.NET核心在linux上运行WPF，你不需要等待MAUI或者退出微软的API。

Uno团队也在文档中讨论了此问题-https://platform.uno/docs/articles/intro.html#how-is-uno-platform-different-from-net-maui
Uno平台应用程序是跨平台的，运行在web以及移动的和桌面上，同样，从一个单一的代码库。Blazor是ASP.NET的一个功能，主要用于构建web应用程序。
Uno平台应用程序是用C#和XAML标记编写的，而Blazor应用程序是用“Razor”语法编写的，这是HTML/CSS和C#的混合。
Uno Platform和Blazor都利用.NET的WebAssembly支持在浏览器中本地运行。

WinUI不支持在浏览器后面执行XAML+代码;微软的WASM集成意味着一个WebView WinUI可以在其中执行blazor组件。因此，如果你想让图形组件可以在浏览器中使用（作为一个真正的Web应用程序，使用wasm），并在任何平台（windows/mac/Android/IOS）中作为一个经典的桌面应用程序，你必须将其定义为HTML，而不是XAML。