Quo Vadis:
Entwicklung von Desktop-Anwendungen mit .NET

Im ersten Teil ging es um die Frage, welche echten Anwendungen mit .NET gebaut sind. Eine Antwort darauf war Subtitle Edit, und die hat mich zum Nachdenken gebracht: Das Projekt hat sich für seine Neuentwicklung nicht für Microsofts Angebot entschieden, sondern für Avalonia. Genau wie JetBrains bei dotMemory und dotTrace.

Das ist kein Zufall, und es führt zur eigentlichen Frage: Wohin geht die Desktop-Entwicklung mit .NET? Die kurze Antwort lautet - nicht dorthin, wo Microsoft hinzeigt.

Die Anforderung dieses Beitrags ist bewusst gesetzt: Wir wollen für Windows, Linux und macOS entwickeln. Alles, was nur auf Windows läuft, kann in dieser Betrachtung nur als Negativbeispiel vorkommen. Das klingt streng, für viele Werkzeuge dürfte es aber heute die normale Erwartung sein.

Eine kurze Historie: WinForms, WPF und dann?

WinForms kam im Februar 2002 mit .NET Framework 1.0. WPF folgte im November 2006 mit .NET Framework 3.0. Beide sind bis heute im Einsatz, und beide laufen nur auf Windows. Abgekündigt ist keines davon: Laut Microsofts Entwickler-FAQ bekommen WPF und WinForms weiterhin neue Funktionen. Für neue Anwendungen, die nur auf Windows laufen sollen, empfiehlt Microsoft allerdings WinUI.

Was danach kam, ist eine lange Reihe von Anläufen:

• Silverlight sollte .NET in den Browser und damit auf jede Plattform bringen. Der Support endete am 12.10.2021.
• WinRT und die Store-Apps von Windows 8 waren an ein Betriebssystem und ein Vertriebsmodell gekettet.
• UWP kam am 29.07.2015 mit Windows 10 und war die “universelle” Plattform, die genau ein Betriebssystem kannte. Abgekündigt ist sie nicht, für neue Desktop-Anwendungen empfiehlt Microsoft aber WinUI.
• Xamarin wurde 2016 gekauft, und der Support endete am 01.05.2024.
• WinUI 3 wurde im November 2021 mit dem Windows App SDK 1.0 stabil und heißt inzwischen nur noch WinUI. Windows-only.
• .NET MAUI wurde am 23.05.2022 stabil. Der Nachfolger von Xamarin.Forms, gedacht als das eine plattformübergreifende Framework.

Dazwischen liegt ein Lichtblick: Am 04.12.2018 hat Microsoft WPF, WinForms und WinUI unter Open Source gestellt. Das war ein echter Schritt - er hat aber an der Plattformfrage nichts geändert.

Vernachlässigt hat Microsoft dabei nicht die Windows-Desktop-Entwicklung, dafür gab es eher zu viele Anläufe. Silverlight und Xamarin sind eingestellt, der Rest läuft bis auf MAUI nur unter Windows.

Vernachlässigt wurde die Frage, wie eine .NET-Desktop-Anwendung auf einem Rechner läuft, der nicht Windows ist. Und genau diese Frage steht hier im Mittelpunkt.

Die entscheidende Spalte heißt Linux

Das ist der Kern der Sache.

MAUI kann kein Linux, jedenfalls nicht von Microsoft. Linux steht nicht auf der Liste der Zielplattformen. Damit ist MAUI unter unserer Anforderung kein Kandidat, sondern ein Mobile-Framework mit Windows-Beilage. Und WinForms, WPF und WinUI 3 sind Negativbeispiele.

Aber Achtung: Seit März 2026 gibt es eine erste Vorschau von MAUI Avalonia, einem Backend, das MAUI-Anwendungen über Avalonia auf Linux und in den Browser bringen soll. Es baut auf .NET 11 auf und ist noch nicht für den produktiven Einsatz gedacht. Bemerkenswert ist, von wem es kommt: Die Linux-Unterstützung für Microsofts plattformübergreifendes Framework liefert nicht Microsoft, sondern das Avalonia-Team.

Bleiben zwei: Avalonia und Uno Platform. Avalonia rendert mit Skia auf allen Plattformen selbst. Uno Platform bildet die WinUI-API nach und rendert auf Linux über Skia in einer X11-Umgebung oder direkt in den Framebuffer, letzteres für Geräte ohne Fenstermanager.

Der Unterschied im Ansatz ist wichtig für die Entscheidung: Uno lässt Dich WinUI-Code schreiben und trägt ihn auf andere Plattformen. Avalonia ist ein eigenes Framework mit einem XAML-Dialekt, der WPF verwandt, aber nicht gleich ist. Wer WinUI-Code hat oder Microsofts API-Oberfläche behalten will, sieht sich Uno an. Wer von WPF kommt oder neu anfängt, landet bei Avalonia.

Was die Entwickler tatsächlich benutzen

Diese Zahlen brauchen einen Vorbehalt, sonst führen sie in die Irre:

MAUIs Downloads dürften überwiegend auf Mobile entfallen.

Ein MAUI-Projekt zieht Microsoft.Maui.Controls, egal ob es eine Android-App oder eine Windows-Anwendung wird, und MAUIs Erfolge liegen bei Handy-Apps. Avalonias Zahl ist dagegen überwiegend Desktop. Für Desktop allein liegt Avalonia damit vermutlich vorn - das ist eine Ableitung, keine Messung, weil die Downloads nicht nach Zielplattform aufgeschlüsselt werden.

Was die Zahlen aber sicher zeigen: Avalonia mit 22,9 Millionen ist keine Bastelbude. Es liegt in derselben Größenordnung wie Microsofts eigene Angebote, und das ohne Konzern im Rücken.

Am unteren Ende stehen die Alternativen. Eto.Forms (1,4 Millionen) setzt auf die native Oberfläche der jeweiligen Plattform. Photino.NET (373.377) und ElectronNET.API (649.803) stellen eine Web-Oberfläche in ein Fenster, mit .NET dahinter. GirCore (283.776) sind moderne GTK-4-Bindings für .NET. Alle drei Wege funktionieren, aber die Zahlen sagen deutlich: Wer heute plattformübergreifend baut, nimmt Avalonia oder Uno.

Wer umzieht, sagt mehr als wer herunterlädt

Zahlen zeigen Verbreitung. Überzeugender sind Projekte, die eine Wahl unter Druck getroffen haben.

JetBrains hat dotMemory und dotTrace von WPF nach Avalonia portiert, um auf macOS und Linux zu kommen. Das Team dazu wörtlich:

“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 baut seine Version 5 auf .NET 10 mit Avalonia 12, plattformübergreifend bis Linux. Version 5.2.0 ist am 10.09.2026 erschienen.

Und in der Gegenrichtung: Bitwarden hat seine Xamarin-Apps nicht auf MAUI migriert, sondern im Januar 2025 auf natives Swift und Kotlin umgestellt.

Die Beispiele zeigen ein Muster:

Wer von WPF kommt und raus muss, landet bei Avalonia. Wer MAUI verlassen will, landet bei nativem Code.

Ein Projekt, das umgekehrt von Avalonia nach MAUI gewechselt ist, ist bei der Recherche nicht aufgetaucht. Das beweist nicht, dass es keines gibt - auffällig ist es trotzdem.

Für Bestandsanwendungen gibt es zusätzlich einen bezahlten Weg: Avalonia XPF ist ein kommerzieller WPF-Fork, der die WPF-API auf Windows, macOS und Linux nachbaut, im teuersten Tarif auch auf iOS, Android und WebAssembly. Bestehender WPF-Code läuft laut Hersteller nach einer Änderung an der csproj weiter, inklusive der Steuerelemente von Telerik, DevExpress, Syncfusion und Infragistics. Lizenziert wird pro Anwendung. Das ist eine Herstellerangabe, keine eigene Messung - aber es ist genau der Weg, den ein zwanzig Jahre alter WPF-Bestand braucht, und Microsoft bietet ihn nicht an.

Was das praktisch bedeutet

Wenn Du heute eine .NET-Desktop-Anwendung für Windows, Linux und macOS beginnst:

• Neu und plattformübergreifend: Avalonia. Eigenes Rendering, echte Linux-Unterstützung, produktiv erprobt von JetBrains und Subtitle Edit. Der XAML-Dialekt ist WPF verwandt, das Wissen überträgt sich.
• Bestehender WinUI- oder UWP-Code: Uno Platform. Es bildet die WinUI-API nach, statt eine eigene anzubieten.
• Bestehender großer WPF-Bestand, der raus muss: Avalonia XPF ansehen. Kostet Geld, spart die Neuentwicklung.
• Nur Mobile mit einer Windows-Beilage: MAUI. Da hat es seine echten Erfolge, siehe Teil 1.
• Nur Windows und für immer nur Windows: WinUI. Microsoft empfiehlt es für neue Anwendungen, die nur auf Windows laufen sollen. Unter unserer Anforderung ist das trotzdem das Negativbeispiel.

Und für die Vollständigkeit, weil es mein eigenes Steckenpferd ist: Nicht jede Anwendung braucht ein Fenster. Terminal.Gui kommt auf 2.068.322 Downloads und baut Oberflächen im Terminal - plattformübergreifend, ohne jede Rendering-Frage. Für Werkzeuge, die ohnehin auf einem Server laufen, ist das oft die passendere Antwort als ein Fenster, das dort niemand sieht.

Fazit

Die Zeitleiste beantwortet die Frage besser als jedes Argument: Von Microsofts Desktop-Frameworks seit 2002 laufen alle noch gepflegten nur unter Windows, bis auf MAUI. Und das plattformübergreifend gedachte MAUI kann kein Linux.

Und die Community? Das Avalonia-Repository wurde am 05.12.2013 angelegt, das MAUI-Repository am 08.05.2020. Sechs Jahre und fünf Monate Vorsprung. Als Microsoft anfing, sich um plattformübergreifende .NET-Oberflächen zu kümmern, gab es die Lösung längst. Und die Linux-Unterstützung für MAUI kommt jetzt ausgerechnet von Avalonia.

Das ist die Antwort auf Quo Vadis. Der Weg führt nicht über Redmond, er führt über ein Community-Projekt, das die Aufgabe erledigt hat.

Wer heute eine Desktop-Anwendung mit .NET beginnt, sollte deshalb zuerst eine Frage beantworten: Auf welchen Rechnern soll sie in fünf Jahren laufen?