Avalonia and .NET MAUI
The same XAML and C#, two different architectures underneath. Here’s what that changes, and how to move between them without a rewrite.
How they differ
Same XAML. Same C#. Two different things happen underneath.
.NET MAUI maps your controls onto the widget set each operating system already has. Avalonia brings its own and draws them. It’s the model Flutter made familiar, implemented for .NET, and nearly every difference further down this page follows from it.
.NET MAUI
Four widget sets to keep in step, and a layer whose job is hiding the differences between them.
Avalonia
One widget set, drawn by us, identical everywhere it runs and portable to anywhere Skia is.
What it buys you
Three targets that come with drawing your own controls.
None of these needed a special case. They’re what happens when the framework already owns the renderer, so a new platform is a new Skia backend instead of a fifth widget set to wrap and maintain.
Desktop Linux
A tested target, not a community port.
Windowing through X11, Wayland, DRM or framebuffer. Rendering with Skia on OpenGL or EGL. Ubuntu 25.x, Fedora 43 and Debian 13 Trixie are tested against every release, and Ubuntu 16.04 onwards is kept working. Linux on Avalonia.
Embedded Linux
Straight to the framebuffer, with no desktop underneath.
DRM and framebuffer backends across x64, ARM64 and ARM32, down to Raspberry Pi OS. The same project builds for the workstation and for the panel, which is the part that makes an HMI a .NET project rather than a second team. Embedded targets.
The browser
The real .NET runtime, in the tab.
Skia through CanvasKit, drawn onto a WebGL canvas. .NET 8.0 or later, served from static files with no server-side component. WebAssembly on Avalonia.
The MAUI backend
We’re building MAUI’s Linux and browser support. Upstream, unforked, in the open.
The Avalonia backend for .NET MAUI keeps your MAUI code and replaces what draws it. Your pages, your handlers, your view models and your XAML stay exactly as they are; Avalonia takes over the rendering, and the app picks up desktop Linux, embedded Linux and WebAssembly. It’s built with the .NET MAUI team, and the changes it needs go into the official repository rather than into a copy of it.
We announced an Avalonia powered backend for .NET MAUI.
Desktop Linux, embedded Linux and WebAssembly, for MAUI codebases that keep their MAUI code. The same announcement put the macOS path at more than twice the performance of Mac Catalyst.
Read the announcementJavier Suárez joined us from the .NET MAUI team at Microsoft.
The progress update set out the architecture: one set of Avalonia handlers behind MAUI’s existing handler system, an ILayoutManager implementation, and SkiaSharp for graphics. Standard MAUI layout controls worked with no changes to them.
Read the announcementPreview 1 shipped and the repository opened.
Existing MAUI control galleries, GraphicsView, SkiaSharp.Views.Maui, WebView, animations and nested navigation all run, including under NativeAOT and trimming.
Read the announcementWhat we committed to before writing it
Anyone can say they’re collaborating with a framework team. These are the five constraints that make it true, and each one is something we gave up.
No fork of .NET MAUI.
The backend targets MAUI as Microsoft ships it. There is no parallel MAUI to keep in step.
No custom target frameworks.
It builds against the target frameworks MAUI already publishes, so your project file stays a MAUI project file.
Every change goes upstream.
Work the backend needs lands in the official .NET MAUI repository, where it benefits everyone building on MAUI.
No internal-visibility tricks, no IL rewriting.
Anything that only works by reaching past a public API is a maintenance bill we would be handing you.
General third-party integration, not an Avalonia carve-out.
The extension points we needed are open to any renderer, which is why they were accepted upstream at all.
Preview 1 is public and the repository is open. If you maintain a control library or a MAUI app with a deep NuGet graph, that’s the feedback the project most needs.
See the repositoryMoving across
You don’t have to decide all of it today.
There are three ways into Avalonia from a MAUI codebase, and only one of them is a rewrite. Most teams take the first, ship to Linux or the browser on the existing app, and decide about the rest afterwards with something running in front of them.
Keep the whole codebase
Change what draws your MAUI app, not the app.
Add the Avalonia.Controls.Maui.Desktop package, add the net11.0 target framework, and call UseAvaloniaApp on your builder. Your pages, handlers and view models are untouched, and the app picks up desktop Linux, embedded Linux and the browser.
Read the Preview 1 walkthroughKeep the controls
Move the app across and bring the components with it.
Avalonia.MAUI Hybrid hosts MAUI-compatible controls inside Avalonia views on iOS and Android. A component you aren’t ready to replace keeps working while everything around it becomes Avalonia, so the migration can run one screen at a time.
Explore Avalonia.MAUI HybridKeep the skills
Start the next project on Avalonia.
The same XAML, the same C#, the same MVVM patterns, and six targets out of one project. Nothing about a MAUI background is wasted here; the markup and the bindings are the part that carries over.
Get started with AvaloniaSide by side
The whole comparison, including the parts that are a tie.
Twenty rows, no ticks and no crosses. Where the two frameworks answer the same way the row is set back, so what’s left in full contrast is the part of the decision that actually differs.
Where it runs
How it draws
What you bring with you
Who stands behind it
Backend rows describe Preview 1, announced in March 2026. Everything else describes both frameworks as they ship today.
FAQ
The questions
worth asking.
If you’re weighing this up for a real codebase and something here doesn’t cover it, ask us directly.
Nearly all of it. Avalonia is XAML and C# with the same MVVM patterns, the same data binding concepts, styles, templates and resources, and it works in Visual Studio, VS Code and Rider. The main things to relearn are Avalonia’s styling system, which is closer to WPF than to MAUI, and the control library. Teams coming from MAUI or WPF are usually productive in days rather than weeks.
It’s a real trade-off, and which side you want depends on the app. Wrapping native widgets means a button looks and behaves exactly like every other button on that operating system, and picks up new platform behaviour for free. Drawing your own means the app looks the same everywhere, you can restyle any part of any control, and a platform without a wrapped widget set is still reachable. Line-of-business, industrial and branded applications usually want the second. A utility that should disappear into the operating system usually wants the first.
It’s in the tested matrix. Ubuntu 25.x, Fedora 43, Debian 13 Trixie and Raspberry Pi OS on embedded are Tier 1, which means they’re tested against every release and bugs on them get fixed. Ubuntu 16.04 through 24.x, Fedora 30 to 42 and Debian 9 to 12 are Tier 2, kept working on a best-effort basis. The full list is published in the Avalonia support matrix and updated with every release.
Good. We build on MAUI, so improvements to it land in the backend we ship, and the changes our work needs go upstream into the official repository where they benefit everyone. The difference this page describes isn’t a bug list that a future release closes, it’s an architectural choice. A framework that maps onto the platform’s widgets and a framework that draws its own reach different sets of platforms and hand you different amounts of control, and that stays true however good either one gets.
Avalonia has commercial control vendors including Actipro and Eremex, plus first-party components for charts, rich text editing, tree data grids, markdown and media. If you have MAUI-compatible controls you don’t want to give up, Avalonia.MAUI Hybrid hosts them inside Avalonia views on iOS and Android.
Avalonia implements each platform’s accessibility API directly: UI Automation on Windows, NSAccessibility on macOS, and the platform services on iOS and Android. Controls expose automation peers, so screen readers, keyboard navigation and high-contrast settings work through the same interfaces a native application uses.
Run your MAUI app on Linux this afternoon.
Add one package and a target framework to the project you already have, and see what it looks like on a platform it couldn’t reach yesterday. Avalonia is MIT licensed and the backend preview is public.