DDC hakt nach: Steiniger Weg von WPF zu Avalonia?
Migration klingt harmlos. Als würde man Code in einen anderen Blumentopf pflanzen - hier und da ein paar Anpassungen machen – fertig ist die plattformübergreifende Zukunft. Doch wer von WPF zu Avalonia UI wechseln will, merkt schnell: Hier geht es nicht um Blümchen auf neuem Mutterboden, hier muss der XAML-Baum eine neue Heimat finden, ein technisch anspruchsvolles Unternehmen mit vielen Fragezeichen.
In diesem Interview erklärt Roland König genau dieses Projekt: Was lässt sich übernehmen, was muss neu gedacht werden – und wo hilft Avalonia XPF, wenn man nicht alles auf einen Schlag umkrempeln will? Dazu sprechen wir auch mit ihm über Performance-Versprechen, Plattformgrenzen und darüber, wann Avalonia eigentlich wirklich die bessere Wahl ist – im Vergleich zu MAUI oder Blazor.
Denn eins ist klar: Wer ernsthaft eine Cross-Plattform-Strategie plant, muss mehr entscheiden als nur Windows oder nicht, sondern auch nativ oder einheitlich, Look & Feel oder Corporate Design und ganz ehrlich: Wollen wir uns das wirklich antun?
Ist der Übergang von WPF zu Avalonia UI wirklich eine Migration oder eher ein "Neuschreiben mit XAML-Kenntnissen"?
Roland: Die Antwort darauf ist wie so oft ein Jein. Von der Applikationslogik bis hinauf zum ViewModel kann der Bestandscode übernommen werden. Beim XAML-Code gibt es zwar viele Übereinstimmungen zwischen Avalonia und WPF, allerdings auch einige Unterschiede. Das geht bei zusätzlichen Controls los und hört beim gänzlich anderen Styling-System auf. Daher muss man sich an dieser Stelle auf eine Migration des XAML-Codes einstellen. Bei einer Migration einer größeren WPF-Applikation auf Avalonia kann das kostenpflichtige Produkt Avalonia XPF helfen – hier ersetzt Avalonia den Unterbau von WPF und erlaubt es, WPF-XAML und Avalonia-XAML zu mischen. Avalonia XPF ermöglicht dadurch eine schrittweise Migration von WPF zu Avalonia.
Avalonia UI läuft auf Windows, macOS, Linux, Android, iOS, Browser UND Embedded Linux. Das klingt fantastisch, aber wie sieht's mit der Performance aus?
Roland: Da wir bei der Frage über viele verschiedene Plattformen sprechen, muss man etwas genauer hinschauen. Für Windows, macOS, Linux und auch Embedded Linux steht Avalonia sehr gut da. Unter der Haube wird für das Rendering das performante Rendering-Framework Skia verwendet – dieses wird etwa auch vom Chrome Browser von Google eingesetzt und zeichnet sich durch höchste Rendering-Performance aus. Daneben ist Avalonia selbst auch an vielen Stellen auf Performance getrimmt. Ein gutes Beispiel dafür ist das fehlende DependencyProperty. Avalonia teilt die Funktionalität in StyledProperty und DirectProperty auf – ersteres ist das Äquivalent des DependencyProperty von WPF und bringt dadurch mehr Ballast mit, letzteres ist eine schlankere Form, spart an Features und bietet damit eine bessere Performance. Auf anderen Plattformen wie Browser, iOS und Android gilt zwar auch das bereits Beschriebene, man merkt hier allerdings die Abhängigkeit von der Performance von .NET selbst. Insbesondere im Browser ist das deutlich zu erkennen. Es lohnt also bei einem Einsatz auf diesen Plattformen vorher zu prüfen, ob die angebotene Performance tatsächlich ausreicht.
Microsoft pushed MAUI als Cross-Platform-Lösung, viele schwören auf Blazor für Web-Apps. Wann würdest du zu Avalonia UI greifen und wann eher zu den Microsoft-Alternativen?
Roland: In dieser Frage stecken für mich zwei verschiedene Themen. Zunächst einmal müsste man sich zwischen Web oder Native entscheiden. Bei ersterem kann Blazor interessant sein, man kann als Alternative aber auch zu einem der anderen großen Web-Frameworks wie Angular, React oder Vue.js greifen. Web hat den Vorteil, dass es praktisch überall läuft, aber auch den Nachteil, dass ein höheres Maß an JavaScript/TypeScript Know-How benötigt wird – das gilt aus meiner Sicht auch für Blazor, wenn auch im geringeren Ausmaß. Entscheidet man sich für Native, dann kann man sich im zweiten Schritt mit MAUI und Avalonia beschäftigen. Ein wichtiger Unterschied ist hier bereits die Linux-Unterstützung. MAUI unterstützt Linux nicht, Avalonia hingegen schon.
Daneben ist der Rendering-Ansatz ein wichtiger Unterschied. MAUI nutzt Controls der jeweiligen Plattformen und bietet dadurch ein natives Look-and-Feel. Auf der Negativ-Seite steht allerdings ein höherer Testaufwand auf allen Plattformen. Avalonia dagegen rendert alles selbst und bietet damit auf allen Plattformen dasselbe Look-and-Feel. Der Nachteil davon ist, dass eine Avalonia-Applikation auf iOS oder Android sich optisch und beim Verhalten potentiell vom Rest auf dem Gerät unterscheidet. Es gibt noch viele andere Unterschiede, für mich ist das aber der wesentlichste. Zu MAUI würde ich greifen, wenn ich tatsächlich natives Look-and-Feel erhalten möchte. Etwa, wenn ich eine Consumer-App bauen würde, die für eine möglichst breite Benutzerbasis zugänglich sein soll. Zu Avalonia würde ich greifen, wenn ich eine kleinere, kontrollierte Benutzerbasis habe – etwa im Umfeld von Apps, die in der Industrie für verschiedenste spezifische Zwecke genutzt werden. Oder wenn mir das eigene Corporate Design sehr wichtig ist – in diesem Fall bietet mir Avalonia die volle Kontrolle darüber, wie Controls am Display angezeigt werden.
Du willst mehr zu Avalonia erfahren? Dann komm zur .NET Developer Conference 2025 vom 24. bis 27. November 2025 nach Köln. Hier erfährst Du alles rund um Microsoft .NET. Rolands Session mit dem Thema "Moderne Cross-Plattform-Applikationen mit .NET" findet am Dienstag, dem 25. November 2025, um 10.30 Uhr statt.
