Desktop-Apps mit .NET und Skia – pixelgenau auf jeder Plattform
SerieCross-Platform Development
Teil 4 von 4
Avalonia ist ein .NET-UI-Framework, das seine gesamte Oberfläche selbst zeichnet – über Skia, dieselbe 2D-Grafikbibliothek, die auch Chrome und Flutter nutzen. Kein Webview, keine nativen OS-Controls, keine Browser-Engine. Stattdessen: pixelgenaues Rendering auf Windows, macOS und Linux aus einer einzigen C#/XAML-Codebasis.
Wie Avalonia rendert
Die meisten Cross-Platform-Frameworks delegieren das Rendering an das Betriebssystem. WPF nutzt DirectX (Windows-only), .NET MAUI wickelt native Controls (ein Button sieht auf jedem OS anders aus), Electron rendert in Chromium. Avalonia geht den Flutter-Weg: Es zeichnet jeden Pixel selbst.
Die Rendering-Pipeline basiert auf SkiaSharp – den .NET-Bindings für Googles Skia-Bibliothek. Hardware-Beschleunigung läuft über Vulkan (Linux/Windows), Metal (macOS) oder Direct2D (Windows). Wenn keine GPU verfügbar ist, greift ein Software-Renderer.
Das bedeutet: Eine Avalonia-App sieht auf jedem Betriebssystem exakt gleich aus. Kein „sieht auf macOS anders aus als auf Linux”. Kein „der Button hat auf Windows andere Abstände”. Pixelgenaue Konsistenz – das gleiche Versprechen, das auch Flutter gibt, nur in der .NET-Welt.
XAML für WPF-Entwickler
Für .NET-Entwickler mit WPF-Erfahrung ist der Einstieg kurz. Avalonia nutzt XAML – mit einer Syntax, die WPF sehr ähnlich sieht:
<Window xmlns="https://github.com/avaloniaui"
Title="Meine App" Width="800" Height="600">
<StackPanel Margin="20">
<TextBlock Text="Willkommen"
FontSize="24"
FontWeight="Light" />
<TextBox Watermark="Name eingeben..."
Margin="0,10,0,0" />
<Button Content="Absenden"
Margin="0,10,0,0"
HorizontalAlignment="Left" />
</StackPanel>
</Window>Die Konzepte sind vertraut: Data Binding, MVVM-Pattern, Control-Templates, Dependency Properties. Der größte Unterschied liegt im Styling-System. Statt WPFs Resource-Dictionaries setzt Avalonia auf CSS-ähnliche Selektoren:
<Style Selector="Button:pointerover">
<Setter Property="Background" Value="#3B82F6" />
<Setter Property="Foreground" Value="White" />
</Style>
<Style Selector="TextBlock.heading">
<Setter Property="FontSize" Value="24" />
<Setter Property="FontWeight" Value="Light" />
</Style>Pseudoklassen wie :pointerover, :pressed oder :disabled funktionieren wie in CSS. Für Webentwickler ist das intuitiver als WPFs Trigger-System, für WPF-Veteranen eine kleine Umgewöhnung. In der Praxis berichten Entwickler, dass die Produktivität nach etwa zwei Wochen auf WPF-Niveau liegt.
Was Avalonia von den Alternativen unterscheidet
Im .NET-Ökosystem konkurriert Avalonia mit zwei anderen Frameworks – und beide lösen andere Probleme.
.NET MAUI ist Microsofts offizieller Nachfolger von Xamarin.Forms. Es wickelt native OS-Controls: Ein Button auf iOS sieht aus wie ein iOS-Button, auf Android wie ein Android-Button. Das ist gut für mobile Apps, die sich nativ anfühlen sollen. Aber MAUI hat ein großes Loch: kein Linux-Support. Für Desktop-Apps auf allen drei Plattformen fällt MAUI damit aus.
Uno Platform verfolgt einen Hybrid-Ansatz: Es nutzt plattformspezifische Basis-Elemente, rendert aber auch teilweise selbst. Der Fokus liegt auf WinUI-3-Kompatibilität. Uno unterstützt mehr Plattformen als MAUI (inklusive Linux und WebAssembly), hat aber ein komplexeres mentales Modell.
Avalonia geht den klarsten Weg: Alles wird selbst gezeichnet, überall gleich. Dafür gibt es keinen „nativen Look” – Avalonia-Apps sehen aus wie Avalonia-Apps, nicht wie macOS- oder Windows-native Anwendungen. Das ist kein Bug, sondern ein Feature: Wer konsistentes Branding über Plattformen hinweg will, bekommt es hier.
| Framework | Rendering | Linux | Mobile | XAML-Syntax | Native Look |
|---|---|---|---|---|---|
| Avalonia | Self-rendered (Skia) | Ja | iOS/Android (reifend) | Eigenes XAML | Nein (konsistent) |
| .NET MAUI | Native Controls | Nein | iOS/Android (Fokus) | WinUI-XAML | Ja |
| Uno Platform | Hybrid | Ja | iOS/Android | WinUI-3-XAML | Teilweise |
| WPF | DirectX | Nein | Nein | WPF-XAML | Windows-only |
Verglichen mit den Web-basierten Frameworks aus den vorherigen Teilen dieser Serie liegt Avalonia in einer anderen Kategorie. Es gibt kein HTML, kein CSS, kein JavaScript. Die Zielgruppe sind .NET-Entwickler, die eine echte Desktop-Anwendung bauen wollen – nicht eine Webseite in einem Fenster.
Wer Avalonia in Produktion nutzt
Die Liste ist eindrucksvoll – und zeigt, dass Avalonia über den Prototyp-Status hinaus ist.
JetBrains nutzt Avalonia in Rider, ihrer Cross-Platform-IDE. Das ist kein kleines Experiment – Rider ist ein kommerzielles Produkt mit hunderttausenden Nutzern. JetBrains bietet auch den besten IDE-Support für Avalonia-Entwicklung: XAML-IntelliSense, Inspections, ein integrierter Previewer.
Wasabi Wallet ist eine Open-Source-Bitcoin-Wallet, die auf Windows, macOS und Linux läuft – komplett in Avalonia gebaut. Lunacy (Design-Tool), GritGene (3D-Engine-UI), PlasticSCM (Versionskontrolle) und Produkte von Schneider Electric, Unity und GitHub setzen ebenfalls auf das Framework.
Die wirtschaftliche Basis stimmt auch: Devolutions hat 2025 eine Drei-Jahres-Sponsorship über 3 Millionen US-Dollar zugesagt, zweckgebunden für die Open-Source-Entwicklung und vertraglich an die MIT-Lizenz gebunden. Das Unternehmen hinter Avalonia (AvaloniaUI) ist profitabel und verzeichnete im ersten Halbjahr 2025 ein Umsatzwachstum von 69 Prozent.
Version 12 und die Rendering-Zukunft
Avalonia 12.0 Preview 1 erschien im Februar 2026, das stabile Release ist für Q4 2026 geplant. Die Leitthemen: Performance und Stabilität.
SkiaSharp 3.0 wird der neue Standard-Renderer – ein großes Update der zugrunde liegenden Grafikbibliothek mit besserer GPU-Nutzung und modernerer API.
Vello ist ein experimenteller GPU-first Renderer, geschrieben in Rust. In Benchmarks zeigt er bis zu 100-fache Beschleunigung gegenüber SkiaSharp bei bestimmten Workloads. Vello wird während des v12-Lebenszyklus experimentell verfügbar sein, aber nicht als Default ausgeliefert.
Impeller ist die spannendste Entwicklung: Avalonia kooperiert mit dem Google-Flutter-Team, um Impeller – Flutters nächste Rendering-Engine – nach .NET zu bringen. Impeller ist GPU-first konzipiert und besonders energieeffizient auf mobilen und Embedded-Geräten. Für die mobile und Embedded-Zukunft von Avalonia ist das ein strategisch wichtiger Schritt.
Weitere Neuerungen in v12: ein neues Open-Source-Table-Control für tabellarische Daten, WebView wird Open Source (bisher nur kommerziell), grundlegend überarbeiteter Android-Support mit neuem Dispatcher und Multi-Activity-Unterstützung, und ein großer Dokumentations-Push.
Das Geschäftsmodell
Avalonia verfolgt ein Open-Core-Modell:
Kostenlos (MIT-Lizenz): Das gesamte Framework, alle Basis-Controls, die Rendering-Engine. Daran wird sich nichts ändern – die MIT-Lizenz ist auch vertraglich durch die Devolutions-Sponsorship abgesichert.
Avalonia Accelerate: Kommerzielle Tooling-Suite mit erweiterten UI-Komponenten, Visual Debugging und Packaging-Tools. Für Einzelpersonen, kleine Teams und Bildungseinrichtungen gibt es eine kostenlose Community Edition – laut Avalonia qualifizieren sich rund 67 Prozent der Nutzer dafür.
Avalonia XPF: Ein kommerzielles Produkt für Unternehmen, die bestehende WPF-Anwendungen plattformübergreifend laufen lassen wollen. XPF ersetzt WPFs DirectX-Engine durch Avalonia – ohne Code-Änderungen, nur Projekt-Datei anpassen. Die Preise liegen zwischen 29.500 und 249.000 Euro, was die Enterprise-Zielgruppe klar macht.
Wo Avalonia an Grenzen stößt
Mobile Support reift noch: Avalonia ist Desktop-first entstanden. iOS und Android werden unterstützt, aber mobile-spezifische Patterns (Gestennavigation, adaptive Layouts, plattformtypische Übergänge) sind weniger ausgereift als bei Flutter oder MAUI.
Kein nativer Look: Das Self-Rendering bedeutet, dass eine Avalonia-App nie aussieht wie eine „echte” macOS- oder Windows-App. Für interne Tools und gebrandete Produkte ist das irrelevant, für Consumer-Apps mit dem Anspruch auf plattformtypische UX ein Trade-off.
Dokumentation: Ein bekannter Schwachpunkt, an dem aktiv gearbeitet wird. Die v12-Roadmap enthält einen expliziten Dokumentations-Push. Bis dahin sind die Community-Ressourcen und JetBrains-Tutorials oft hilfreicher als die offiziellen Docs.
IDE-Support: JetBrains Rider bietet die beste Erfahrung. Die Visual-Studio-Extension funktioniert, gilt aber als weniger ausgereift. VS Code ist nutzbar, hat aber keinen XAML-Previewer.
Hot Reload: Nicht nativ eingebaut, sondern über das Community-Projekt HotAvalonia verfügbar. Funktioniert für XAML-Änderungen – für C#-Änderungen greift .NETs eigener Hot-Reload-Mechanismus.
Lernkurve für Nicht-XAML-Entwickler: Wer aus der Web-Welt kommt, muss sich in XAML, Data Binding und MVVM einarbeiten. Das ist kein Wochenend-Projekt – aber für .NET-Entwickler mit WPF- oder UWP-Erfahrung ein sehr kurzer Weg.
Avalonia und die Cross-Platform-Landschaft
In dieser Serie haben wir vier verschiedene Philosophien gesehen:
- Electron/NW.js: Chromium mitliefern, Web-Stack nutzen – maximale Vertrautheit, maximaler Overhead
- Tauri/Neutralinojs: System-Webview nutzen, Web-Stack beibehalten – leichter, aber mit Rendering-Inkonsistenzen
- Flutter/GPUI: Eigene Engine, eigene Sprache (Dart/Rust) – konsistent, aber eigenes Ökosystem
- Avalonia: Eigene Engine, .NET-Ökosystem – konsistent, mit Zugang zum gesamten NuGet-Universum
Avalonia ist der naheliegendste Kandidat für Teams, die bereits in C# und .NET investiert sind. Es verbindet die Rendering-Konsistenz von Flutter mit der Vertrautheit des .NET-Ökosystems. Die Skia-basierte Rendering-Pipeline liefert ein deutlich „appigeres” Ergebnis als jedes Webview-Framework – kein Browser-Feeling, keine HTML-Rendering-Quirks.
Für Web-Teams ohne .NET-Hintergrund ist der Einstieg steiler als bei Tauri oder Neutralinojs. Doch wer C# nicht scheut, bekommt ein Framework, das produktionsreif ist, von großen Unternehmen eingesetzt wird und eine klare technische Roadmap hat – inklusive der Zusammenarbeit mit Google an der nächsten Rendering-Generation.