// the find
AvaloniaUI/Avalonia
Develop Desktop, Embedded, Mobile and WebAssembly apps with C# and XAML. The future of .NET UI
Avalonia is a cross-platform .NET UI framework using XAML and C#, targeting Windows, macOS, Linux, iOS, Android, and WebAssembly from a single codebase. It's the closest thing .NET developers have to a modern, cross-platform WPF replacement, and it's used in production by JetBrains Rider and GitHub Desktop. Aimed at C# developers who want native-ish desktop apps without switching to Electron or rebuilding for each platform.
- Genuinely cross-platform rendering via Skia — the UI looks and behaves consistently across targets because Avalonia draws its own controls rather than wrapping native ones, avoiding the lowest-common-denominator problem that plagues wrapper frameworks
- The headless testing backend (Avalonia.Headless) lets you write unit tests that actually exercise UI logic including layout and rendering without spinning up a display server — this is something WPF and WinForms never properly solved
- XAML compiler (XamlX) converts XAML to IL at build time rather than parsing it at runtime, which gives meaningful compile-time errors and better startup performance compared to interpreted XAML stacks
- Strong accessibility and automation support including UIA on Windows and platform accessibility APIs elsewhere, plus a first-class DevTools overlay for inspecting the live visual tree — practical for real production apps, not just demos
- Mobile support (iOS/Android) is functional but not first-class — the control set, platform integration points, and documentation lag behind desktop; if mobile is your primary target, MAUI or Flutter are still more mature choices
- WASM performance is limited by .NET's WASM runtime overhead and Skia rendering via Canvas2D; for web-heavy workloads the payload size and startup time are real problems, not edge cases
- The WPF-to-Avalonia migration path is rougher than the README implies — subtle API differences in bindings, triggers, styles (Avalonia uses a CSS-like system rather than WPF's ResourceDictionary style selectors), and missing controls will surface quickly in any non-trivial app
- Third-party control ecosystem is thin compared to WPF or WinForms; for anything beyond the built-in set you're often writing your own or waiting for community ports, which adds friction for teams used to commercial control libraries