Hinweis: Dieser Podcast und dieses Video wurden mithilfe von KI erstellt. Dabei wurden die Originalinhalte und technischen Erkenntnisse des Autors des Blogbeitrags adaptiert.

 
Avalonia UI wurde bereits vor rund einem Jahr im Windows Developer [1] vorgestellt. Avalonia reiht sich ein in eine lange Liste von UI-Frameworks für .NET. Anders als WPF, .NET MAUI oder WinUI stammt Avalonia nicht von Microsoft. Es ist ein aus der Open-Source-Community geborenes UI-Framework und wird häufig als geistiger Nachfolger von WPF gesehen. Im April 2026 wurde die neue Version 12 veröffentlicht – ein guter Anlass, einen frischen Blick auf die Verbesserungen des Frameworks zu werfen.

Neue Page-Klassen für die Navigation

Der Bereich der Navigation war lange Zeit ein schwarzer Fleck bei Avalonia. Aus Sicht des Autors war das für den früheren Fokus auf Desktopapplikationen auch nicht schlimm. Desktopapplikationen können verschiedene Konzepte bezüglich der Navigation innerhalb der Applikation haben. Ein gutes Beispiel wäre der Vergleich zwischen einer IDE wie Visual Studio, die auf viele verschiedene dockbare Fenster setzt, und einer App wie der Microsoft Store von Windows 11, bei der es eine Hauptnavigation zwischen verschiedenen Views gibt, die wiederum nach dem Master-Detail-Pattern aufgebaut sind.

In der mobilen Welt ist dieser Punkt etwas anders. Hier gibt es viele kleine Apps, bei denen jede für sich in der Regel ein kleines Set an Aufgaben erfüllt. Bei der Navigation folgen diese meist ähnlichen Mustern. Navigiert wird über ein Hamburger-Menü, über eine feste Tab-Leiste oder nach dem Master-Detail-Prinzip. Ein Zurück-Button ist i. d. R. ebenfalls Teil des Navigationskonzepts.

Mit Avalonia 12 schließt Avalonia diese Lücke und liefert ein Set an Controls, um ebensolche Muster einfach abbilden zu können. Die Basis dafür ist das neue Control Page. Darauf aufbauend bekommen wir ContentPage, TabbedPage, DrawerPage, CarouselPage und NavigationPage. Im Cross-Platform-Template erhalten wir entsprechend eine Einstellung, ob und mit welcher Art von Page wir die Hauptseite unserer App bauen möchten.

Nutzen wir wie im Screenshot in Abbildung 1 die NavigationPage, dann erbt unsere MainView davon. Zusätzlich generiert uns das Template eine HomeView und eine SettingsView, zwischen denen navigiert werden kann. Beide erben von ContentPage, das hier entsprechend für die Inhaltsseiten unserer App gedacht ist.

Abb. 1: Neues Feld „Main View Page Type“ im Cross-Platform-Template von Avalonia

In Listing 1 sehen wir die Inhalte von MainView und HomeView, sowie in Listing 2 den Code-Behind der HomeView. Die Struktur ist dabei einfach: In der MainView wird die HomeView direkt als Inhalt gesetzt. Innerhalb der HomeView haben wir einen Button, der bei Klick im Code-Behind mittels Navigation.PushAsync eine Navigation zur SettingsView auslöst. Navigation ist dabei eine Eigenschaft der Klasse Page und ist dann gesetzt, wenn die Page in einer NavigationPage eingebettet ist; in unserem Beispiel ist das der Fall.

<!-- MainView.axaml -->
<NavigationPage xmlns="https://github.com/avaloniaui"
                xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
                xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
                xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
                xmlns:local="using:HappyCoding.AvaloniaTravelTimeTracker.Views"
                mc:Ignorable="d" d:DesignWidth="800" d:DesignHeight="450"
                x:Class="HappyCoding.AvaloniaTravelTimeTracker.Views.MainView">
  <local:HomeView />
</NavigationPage>

<!-- HomeView.axaml -->
<ContentPage xmlns="https://github.com/avaloniaui"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             xmlns:vm="using:HappyCoding.AvaloniaTravelTimeTracker.ViewModels"
             mc:Ignorable="d" d:DesignWidth="800" d:DesignHeight="450"
             Header="Home"
             x:DataType="vm:HomeViewModel"
             x:Class="HappyCoding.AvaloniaTravelTimeTracker.HomeView">    
  <Design.DataContext>
    <vm:HomeViewModel />
  </Design.DataContext>
  <StackPanel HorizontalAlignment="Center" 
              VerticalAlignment="Center"
              Spacing="10">
    <TextBlock Text="{Binding Greeting}" />
  <Button Name="SettingButton" HorizontalAlignment="Center" 
          Click="SettingButton_Click">Open Settings</Button>
  </StackPanel>
</ContentPage>

public partial class HomeView : ContentPage
{
  public HomeView()
  {
    InitializeComponent();
  }

  private async void SettingButton_Click(object? sender, Avalonia.Interactivity.RoutedEventArgs e)
  {
    if(this.Navigation == null) { return; }
    await Navigation.PushAsync(new SettingsView()
    {
      DataContext = new SettingsViewModel()
    });
  }
}

Die NavigationPage verwaltet nicht nur die aktuell angezeigte Seite. Sie merkt sich stets, woher navigiert wurde und baut sich mit diesen Informationen einen Stack auf. Bei der Rückwärtsnavigation wird dann schlicht zur jeweils vorherigen Page zurückgewechselt. Der Wechsel der Seite kann über eine PageTransition animiert werden, beispielsweise über einen CrossFade-Effekt. Dieses Feature ist nicht neu, PageTransitions wurden bereits vorher über das TransitioningContentControl bereitgestellt. Die NavigationPage nutzt unter der Haube die gleichen Klassen.

Eine SettingsView mit etwas Inhalt kann schließlich wie in Abbildung 2 aussehen. Der Zurück-Pfeil an der oberen linken Ecke stammt dabei von der NavigationPage, der Titel Settings kommt von der Eigenschaft Header der aktuellen ContentPage. Ein Klick auf Zurück führt das UI wieder zur vorherigen Seite, im Template wäre das die HomeView. Unabhängig vom Navigationskonzept sind Pages normale Controls, wir können die Seiten also auf die gleiche Weise aufbauen wie User-Controls.

Abb. 2: Eine Einstellungsseite innerhalb einer NavigationPage

Die NavigationPage bringt zusammen mit den anderen Page-Klassen ein breites Set an Funktionen mit. Neben der reinen Navigation sind dabei die angesprochenen Übergangseffekte (Transitions), modale Pages, Gesten, Beachtung der SafeArea bei Mobilgeräten, CommandBar und die bei Avalonia allgemein hohe Flexibilität beim Styling zu nennen. Beispiele für all diese Funktionen finden sich in der Dokumentation von Avalonia oder im Control Catalog – letzterer versteckt sich etwas, daher gehen wir im nächsten Kapitel separat darauf ein.

Insbesondere wegen der neuen Page-Klassen lohnt sich ein Blick in den Control Catalog, da sich hier sehr viele Beispiele und auch vollständige Use Cases befinden. Use Cases zeigen die Anwendung der Klassen in fiktiven Apps. In Abbildung 3 sehen wir etwa den Use Case der Restaurant-App „L’Avenir“. Ebenfalls spannend sind die Beispiele dazu, wie sich die Navigationsklassen zusammen mit dem populären MVVM-Pattern nutzen lassen.

Abb. 3: Beispiel-Use-Case „L’Avenir“ im Control Catalog von Avalonia

Beispiele im Control Catalog

Viele der aktuellen Beispiele von Avalonia sind im Control Catalog zu finden. Dieser wird zum Zeitpunkt dieses Artikels allerdings nicht als kompilierte App in den App-Stores angeboten, sondern befindet sich im Repository des Avalonia-Projekts [2]. Der Control Catalog liegt im Ordner samples, zum schnellen Testen auf dem Desktop eignet sich das Projekt ControlCatalog.Desktop. Der Autor dieses Artikels geht üblicherweise wie folgt vor:

• Klonen des vollständigen Repositorys von Avalonia

• Auf den Branch des gewünschten Releases wechseln (z. B. release/12.0.0)

• Kompilieren und Starten des ControlCatalog.Desktop-Projekts

Sollte es Probleme beim Kompilieren geben, hilft ein Blick in den docs-Ordner des Projekts. In der dort abgelegten build.md sind alle Voraussetzungen und die notwendigen Schritte zum Starten des Control Catalog beschrieben.

Barrierefreiheit und Wayland-Support unter Linux

Avalonia hat seine Stärken historisch am Desktop und arbeitet auch dort stets an Verbesserungen. Linux ist dabei kein Außenseiter, ganz im Gegenteil. Eine Lücke auf Linux-Desktops war allerdings bisher die Unterstützung der Barrierefreiheit. Mit Avalonia 12 wurde diese Lücke mit der Unterstützung von AT-SPI2 geschlossen.

Demgegenüber ist die native Unterstützung für Wayland noch eine Baustelle, Avalonia 12 ist weiterhin auf XWayland angewiesen. Zum Zeitpunkt dieses Artikels hat sich hier aber schon etwas getan. Ab Avalonia 12.1 steht Wayland-Unterstützung als experimentelles Paket für alle zur Verfügung – es muss aber explizit in der Program.cs aktiviert werden. Standardmäßig geht Avalonia noch den alten Weg über X11, bei modernen Wayland-Desktops damit über XWayland.

Warum dauert die Unterstützung von Wayland so lange? Das Avalonia-Team ist darauf in einem eigenen Blogeintrag [3] eingegangen. Die Herausforderung bei Linux ist, dass es in Linux nicht den einen Technologiestack für den Desktop gibt, wie unter macOS oder Windows. Unter Linux gibt es verschiedene Desktopumgebungen und viele verschiedene Distributionen. Das führt zu einer großen Zahl möglicher Varianten von verwendeten Produkten und Konfigurationen im Hinblick auf die Wayland-Unterstützung.

SIE LIEBEN UI?

Entdecken Sie die BASTA! Tracks

Mehr erfahren

Kein klassisches .NET Framework mehr

Häufig wird der Sprung einer Major-Versionsnummer dazu genutzt, alte Zöpfe abzuschneiden. Im Falle von Avalonia 12 ist hier insbesondere die Unterstützung für das klassische .NET Framework zu nennen. In den Release Notes taucht dieser Punkt mit dem Satz „We’ve removed netstandard2.0 from almost all projects …“ nur indirekt auf. Die Begründung für diesen Schritt ist dabei nachvollziehbar. Das Avalonia-Team möchte für die Codebasis moderne Features von .NET nutzen, gleichzeitig sagen die Telemetriedaten, dass die Nutzung des klassischen Frameworks im niedrigen einstelligen Prozentbereich liegt [4].

Andere Aufräumarbeiten wie das Entfernen der Unterstützung für Direct2D dürften sich nur in wenigen Spezialfällen auf Projekte mit Avalonia auswirken. Die Unterstützung für die Direct2D-Schnittstelle von Windows wurde seit Jahren nur selten weiterentwickelt. Initial wurde sie gebaut, damit Avalonia neben Skia auch andere Renderer unterstützen kann. In der Praxis wurde aber auch unter Windows standardmäßig auf das plattformübergreifende Skia gesetzt.

WebView als Open Source

Das WebView-Control, das zunächst über das kostenpflichtige Paket Avalonia Accelerate angeboten wurde, hat seinen Weg in den freien Kern des Frameworks gefunden. Das ist eine gute und wichtige Nachricht, denn eine WebView zur Anzeige von HTML-Inhalten ist praktisch ein Standardfeature in UI-Frameworks und wird in vielen Applikationen benötigt.

Avalonia Plus und Pro ersetzen Accelerate

Neben Weiterentwicklungen am Framework selbst gab es ebenso Änderungen an den vom Avalonia-Team angebotenen Produkten. Avalonia Accelerate sollte ein Zusatzpaket von kostenpflichtigen Controls und Tools sein, die sich an professionelle Entwicklungsteams richten. Da der Name „Accelerate“ eher für Verwirrung als für Klarheit sorgte, wurde der Name geändert und das Paket in mehrere Varianten aufgeteilt [5].

In wenigen Worten: Avalonia Plus erweitert den Funktionsumfang der Plug-ins für Visual Studio und Visual Studio Code. Zusätzlich stehen auch die DevTools und das Paketierungstool Parcel im vollen Funktionsumfang zur Verfügung. Avalonia Pro stellt zusätzlich weiterführende Controls wie das TreeDataGrid, einen MediaPlayer, einen RichTextEditor und ein Paket aus mehreren Charts zur Verfügung. Eine detaillierte Gegenüberstellung mit Preisen findet sich auf der Website des Projekts unter [6].

An der grundlegenden Strategie, die das Avalonia-Team in den letzten Jahren eingeschlagen hat, ändert das wenig. Der Kern des Frameworks steht als Open Source jedem zur Verfügung – egal ob für freie oder kommerzielle Projekte. Features, die für kommerzielle Projekte Relevanz haben und die man bei anderen UI-Frameworks eher von Komponentenanbietern dazukauft, befinden sich im kostenpflichtigen Zusatzpaket. Die Einnahmen aus diesen Zusatzpaketen tragen zur Weiterentwicklung des Avalonia-Projekts bei.

Ein wichtiger Hinweis an dieser Stelle betrifft die IDE-Unterstützung. Die Erweiterungen für Visual Studio und Visual Studio Code stammen vom Avalonia-Team und sind im vollen Funktionsumfang kostenpflichtig. Die IDE Rider von JetBrains dagegen bringt eine hervorragende Unterstützung für Avalonia direkt mit und ist in der Rider-Lizenz bereits enthalten.

CompiledBinding wird zum Standard

Neben den genannten neuen Funktionen liefert Avalonia 12 viele Verbesserungen an der Basis. Einer der wichtigsten Punkte dabei ist eine Änderung am CompiledBinding – dieses ist jetzt die Standard-Variante. Wurde in einem Avalonia-Projekt nichts anderes konfiguriert, ging der XAML-Compiler von Avalonia bisher von ReflectionBinding aus, mit Version 12 ändert sich das zu CompiledBinding. Ein Opt-out ist via AvaloniaUseCompiledBindingsByDefault in der .csproj-Datei nach wie vor möglich (Listing 3). Der Autor rät, diesen Weg maximal für eine Übergangszeit zu nutzen. CompiledBinding bringt viele Vorteile und sollte der Standard in den allermeisten Avalonia-Applikationen sein.

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <AvaloniaUseCompiledBindingsByDefault>false</AvaloniaUseCompiledBindingsByDefault>
  </PropertyGroup>
</Project>

Daneben gab es viele kleine Verbesserungen, so wurde die Version von SkiaSharp hochgezogen und ein GroupBox-Control eingeführt. Das Fokus-Handling wurde überarbeitet und für macOS-Applikationen gibt es jetzt die Möglichkeit, sich in das Menü des App-Icons einzuhängen.

Die genannten Punkte sind nur Beispiele, die tatsächliche Liste ist deutlich länger. An dieser Stelle ist auch zu erwähnen, dass das Avalonia-Team in den letzten Monaten intensiv an der Dokumentation gearbeitet hat.

Responsive Layouts mit Container-Querys

Einige wichtige Features veröffentlicht das Avalonia-Team nicht mit dem Major-Release, sondern in den Releases dazwischen. Ein aus Sicht des Autors nicht zu unterschätzendes Beispiel sind die mit Avalonia 11.3.0 eingeführten Container-Querys. Das Feature ist den Media-Querys in CSS nachempfunden und ermöglicht es, Styles abhängig von der Größe des Fensters bzw. des Bildschirms zu definieren. Was zunächst unspektakulär klingt, ist tatsächlich eine der Grundlagen für Responsive Design, also dafür, dass sich eine Applikation automatisch an die Größe des Geräts anpasst.

Listing 4 zeigt eine Container-Query, bei der die Ausrichtung eines Controls innerhalb eines DockPanel abhängig von der Größe des Fensters angepasst wird. Ist das Fenster breit genug (mehr als 600 Pixel), wird das Control links angedockt. Ist das Fenster schmaler, so wird das Control oben angedockt. Das Ergebnis sehen wir in Abbildung 4: links in der breiten und rechts in der schmalen Variante. Die Position des Controls zur Anzeige der aktuellen Temperatur wird via Container-Query gesteuert.

<ContainerQuery Name="LayoutArea" 
                Query="min-width:600">
  <Style Selector="DockPanel.LayoutAreaMainDock">
    <Setter Property="MinHeight" Value="NaN" />
  </Style>
  <Style Selector="HeaderedContentControl.LayoutAreaDockedChild">
    <Setter Property="DockPanel.Dock" Value="Left" />
    <Setter Property="Width" Value="300" />
    <Setter Property="Height" Value="NaN" />
  </Style>
</ContainerQuery>
<ContainerQuery Name="LayoutArea" 
                Query="max-width:600">
  <Style Selector="DockPanel.LayoutAreaMainDock">
    <Setter Property="MinHeight" Value="600" />
  </Style>
  <Style Selector="HeaderedContentControl.LayoutAreaDockedChild">
    <Setter Property="DockPanel.Dock" Value="Top" />
    <Setter Property="Width" Value="NaN" />
    <Setter Property="Height" Value="150" />
  </Style>
</ContainerQuery>

Abb. 4: Responsive Layout mit Hilfe von Container-Querys

Impeller kommt zu .NET

Avalonia setzt beim Rendering auf Skia bzw. auf den .NET-Wrapper SkiaSharp. Skia ist eine moderne Rendering-Engine für 2D-Grafik und wird etwa von Google Chrome eingesetzt. Für Avalonia war das stets eine gute Wahl, da Skia auf allen relevanten Plattformen funktioniert und dabei einen hohen Featureumfang und eine gute Performance aufweist.

Für die Zukunft arbeitet das Avalonia-Team daran, die Rendering Engine Impeller des Flutter-Teams in die .NET-Welt zu bringen und über sie einen neuen Renderer in Avalonia bereitzustellen [7]. Der Grund für diese Entwicklung ist eine weitere Steigerung der Performance. Impeller ist neuer als Skia und nutzt Features moderner GPUs besser aus. Einer der durch Impeller adressierten Punkte betrifft sogenannte „Junks“, kurze Einbrüche in der Framerate beim Rendering mit Skia. Diese entstehen, weil Skia zur Laufzeit Shader kompiliert. Wenn also etwas zum ersten Mal auf dem Bildschirm gerendert wird, kann es bei Skia etwas holpern. Impeller adressiert und verbessert solche Performanceprobleme.

Ausblick auf Avalonia MAUI

Ende 2025 hat das Avalonia-Team ein weiteres Mitglied der Avalonia-Familie mit dem folgenden Statement angekündigt: „.NET MAUI is Coming to Linux and the Browser, Powered by Avalonia“ [8]. In der Zwischenzeit gibt es bereits eine Preview, die man ausprobieren kann [9]. Die Idee dahinter klingt zunächst einfach. .NET MAUI rendert Controls im Gegensatz zu Avalonia nicht selbst, sondern nutzt die Handler-Architektur, um XAML-Controls auf die jeweiligen nativen Controls der Plattform zu mappen [10]. Aus einem Button in XAML wird unter iOS ein UIButton, unter Android ein MaterialButton und unter Windows ein WinUI-Button. Das bringt natives Look-and-Feel, hat aber den Nachteil, dass die Unterstützung weiterer Plattformen mit hohem Aufwand verbunden ist – eine Linux-Unterstützung gibt es in .NET MAUI daher bis heute nicht.

Die Idee hinter Avalonia MAUI ist nun, Handler bereitzustellen, welche die Controls von .NET MAUI auf die Controls von Avalonia mappen. Im Ergebnis ist es damit möglich, .NET MAUI auf Plattformen wie Linux und in den Browser zu bringen, die .NET MAUI nicht von sich aus unterstützt. Inwieweit man auch von anderen Vorteilen von Avalonia wie dem Headless-Modus für automatisierte Tests profitiert, wird sich zeigen. Eine spannende Entwicklung ist es aus Sicht des Autors auf jeden Fall.

Fazit

Ist Avalonia durch die vielen neuen Features eine gute Wahl für mobile Applikationen? Aus Sicht des Autors entwickelt sich das Framework mehr und mehr dorthin und schließt verschiedene Lücken bei der Navigation und beim Responsive Design. Wenn Avalonia hier weiter investiert und ebenso weiter am Tooling arbeitet, wird es für viele .NET-Teams eine solide Basis ihrer Apps sein. Stand heute bringt es schon einen großen Funktionsumfang mit und grenzt sich durch das eigene Rendering sinnvoll von Microsofts hauseigenem Cross-Platform-Framework .NET MAUI ab.

Nutzt man Avalonia, bekommt man eine einheitliche Codebasis sowie ein einheitliches Look-and-Feel über alle unterstützten Plattformen hinweg. Der Umfang der bereitgestellten Controls braucht sich vor anderen UI-Frameworks nicht zu verstecken. Obendrauf bekommen wir einen Headless-Modus für automatisierte Tests geschenkt. Gerade für Business-Apps sind das Punkte, die zählen.

Dem Hauptnachteil von Avalonia, der überschaubaren Anzahl an Drittherstellern für zusätzliche Controls (etwa ein mächtiges DataGrid), begegnet das Avalonia-Team mit dem Produkt Avalonia Pro selbst. Das Avalonia-Team wird damit selbst zum Lieferanten erweiterter Controls für das eigene UI-Framework.