Blog
Quo Vadis:
Building Desktop Applications with .NET
Part one asked which real applications are built with .NET. One of the answers was Subtitle Edit, and it made me think: for its rewrite, the project did not pick Microsoft’s offering. It picked Avalonia. Exactly like JetBrains did for dotMemory and dotTrace.
That is no coincidence, and it leads to the real question: where is desktop development with .NET going? The short answer is - not where Microsoft is pointing.
This post sets its requirement deliberately: we want to build for Windows, Linux and macOS. Anything that only runs on Windows can appear here only as a negative example. That sounds strict, but for many tools it is probably the ordinary expectation today.
A short history: WinForms, WPF, and then?
WinForms arrived in February 2002 with .NET Framework 1.0. WPF followed in November 2006 with .NET Framework 3.0. Both are still in use, and both run only on Windows. Neither is deprecated: according to Microsoft’s developer FAQ, WPF and WinForms continue to receive feature updates. For new applications that only need to run on Windows, however, Microsoft recommends WinUI.
What came after is a long series of attempts:
- Silverlight was meant to bring .NET into the browser and thereby onto every platform. Support ended on 12 October 2021.
- WinRT and the Windows 8 Store apps were chained to one operating system and one distribution model.
- UWP arrived on 29 July 2015 with Windows 10 - the “universal” platform that knew exactly one operating system. It is not deprecated, but for new desktop applications Microsoft recommends WinUI.
- Xamarin was acquired in 2016, and support ended on 1 May 2024.
- WinUI 3 became stable in November 2021 with Windows App SDK 1.0 and is now simply called WinUI. Windows-only.
- .NET MAUI became stable on 23 May 2022. The successor to Xamarin.Forms, intended as the one cross-platform framework.
There is one bright spot in between: on 4 December 2018 Microsoft open-sourced WPF, WinForms and WinUI. That was a genuine step - but it changed nothing about the platform question.
What Microsoft neglected along the way was not Windows desktop development - if anything, there were too many attempts. Silverlight and Xamarin are discontinued, and apart from MAUI the rest runs only on Windows.
What was neglected was the question of how a .NET desktop application runs on a machine that is not Windows. And that question is the focus here.
The decisive column is Linux
That is the heart of the matter.
MAUI cannot do Linux, at least not from Microsoft. Linux is not on the list of target platforms. Under our requirement that makes MAUI not a candidate but a mobile framework with a Windows side dish. And WinForms, WPF and WinUI 3 are the negative examples.
But watch out: since March 2026 there has been a first preview of MAUI Avalonia, a backend meant to bring MAUI applications to Linux and the browser via Avalonia. It builds on .NET 11 and is not yet intended for production use. What stands out is who makes it: Linux support for Microsoft’s cross-platform framework comes not from Microsoft, but from the Avalonia team.
Two remain: Avalonia and Uno Platform. Avalonia renders everything itself with Skia on every platform. Uno Platform reimplements the WinUI API and renders on Linux via Skia inside an X11 shell or straight into the framebuffer, the latter for devices without a window manager.
The difference in approach matters for the decision: Uno lets you write WinUI code and carries it to other platforms. Avalonia is its own framework with a XAML dialect related to WPF but not identical to it. If you have WinUI code, or want to keep Microsoft’s API surface, look at Uno. If you come from WPF or start fresh, you end up at Avalonia.
What developers actually use
These numbers need a caveat or they mislead:
MAUI’s downloads are likely to be predominantly mobile.
A MAUI project pulls Microsoft.Maui.Controls whether it becomes an Android app or a Windows application, and MAUI’s successes are in phone apps. Avalonia’s number, by contrast, is predominantly desktop. For desktop alone Avalonia is therefore probably ahead - that is an inference, not a measurement, because downloads are not broken down by target platform.
What the numbers do show for certain: Avalonia at 22.9 million is not a hobby project. It sits in the same order of magnitude as Microsoft’s own offerings, without a corporation behind it.
At the lower end sit the alternatives. Eto.Forms (1.4 million) uses each platform’s native widgets. Photino.NET (373,377) and ElectronNET.API (649,803) put a web front end in a window with .NET behind it. GirCore (283,776) provides modern GTK 4 bindings for .NET. All three approaches work, but the numbers say it plainly: whoever builds cross-platform today reaches for Avalonia or Uno.
Who migrates says more than who downloads
Numbers show reach. Projects that made a choice under pressure are more convincing.
JetBrains ported dotMemory and dotTrace from WPF to Avalonia to reach macOS and Linux. The team’s own words:
“As our tools use WPF, Avalonia was an easy choice for us. It is an impressive technology which has seen tremendous growth in recent years, and it feels mature enough to be used for production code.”
Subtitle Edit builds its version 5 on .NET 10 with Avalonia 12, cross-platform down to Linux. Version 5.2.0 was released on 10 September 2026.
And in the opposite direction: Bitwarden did not migrate its Xamarin apps to MAUI. In January 2025 it moved to native Swift and Kotlin.
The examples show a pattern:
Whoever comes from WPF and has to get out lands on Avalonia. Whoever wants to leave MAUI lands on native code.
A project that went the other way, from Avalonia to MAUI, did not turn up in the research. That is not proof none exists - but it is conspicuous.
For existing applications there is also a paid route: Avalonia XPF is a commercial WPF fork that reimplements the WPF API on Windows, macOS and Linux, and in the most expensive tier also on iOS, Android and WebAssembly. According to the vendor, existing WPF code keeps running after a change to the csproj, including controls from Telerik, DevExpress, Syncfusion and Infragistics. Licensing is per application. That is a vendor claim, not my own measurement - but it is exactly the path a twenty-year-old WPF codebase needs, and Microsoft does not offer it.
What this means in practice
If you start a .NET desktop application for Windows, Linux and macOS today:
- New and cross-platform: Avalonia. Its own rendering, real Linux support, proven in production by JetBrains and Subtitle Edit. The XAML dialect is related to WPF, so the knowledge transfers.
- Existing WinUI or UWP code: Uno Platform. It reimplements the WinUI API rather than offering its own.
- A large existing WPF codebase that has to move: look at Avalonia XPF. It costs money and saves the rewrite.
- Mobile only, with a Windows side dish: MAUI. That is where its real successes are, see part one.
- Windows only, and Windows forever: WinUI. Microsoft recommends it for new applications that only need to run on Windows. Under our requirement it is still the negative example.
And for completeness, because it is a hobby of mine: not every application needs a window. Terminal.Gui has 2,068,322 downloads and builds interfaces in the terminal - cross-platform, with no rendering question at all. For tools that run on a server anyway, that is often the better answer than a window nobody there will see.
Conclusion
The timeline answers the question better than any argument: of Microsoft’s desktop frameworks since 2002, every one still maintained runs only on Windows, except MAUI. And MAUI, the one designed to be cross-platform, cannot do Linux.
And the community? The Avalonia repository was created on 5 December 2013, the MAUI repository on 8 May 2020. Six years and five months of head start. By the time Microsoft started caring about cross-platform .NET user interfaces, the solution had been around for years. And Linux support for MAUI is now coming from Avalonia, of all places.
That is the answer to quo vadis. The road does not run through Redmond. It runs through a community project that finished the job.
If you start a desktop application with .NET today, answer one question first: which machines should it run on five years from now?