Avalonia 12.1.1 targets six platform families with C# and XAML
Avalonia 12.1.1 is a UI framework for Windows, macOS, Linux, iOS, Android, and WebAssembly. A .NET team can keep C# view models and XAML interface work in one project family instead of choosing a separate toolkit for each operating system. The framework includes its own styling model and is distributed through NuGet. This is a better fit for installed product software than for a website whose interface already belongs in HTML and CSS.
The development path will feel familiar to a Microsoft-stack team. The README points to project and control templates, XAML previewing, completion, diagnostics, and navigation in the Visual Studio extension. VS Code has an Avalonia extension with similar goals. Rider handles code work directly, though XAML previewing depends on a community-maintained plugin. The official samples repository and starter tutorial give a new application a clearer entry point than the framework source tree itself.
The WPF resemblance stops short of 1:1 compatibility
The Avalonia 12.1.1 README calls the framework a spiritual successor to WPF and immediately says it is not a 1:1 copy. That distinction should drive the buying decision. Developers can reuse C#, XAML habits, and familiar application patterns, but an existing WPF codebase still needs a migration assessment. Controls, platform behavior, styling, and dependencies deserve proof on the operating systems you plan to ship.
Avalonia XPF is the closer compatibility offer for an existing WPF application, and it sits outside this open-source framework. The README describes XPF as a commercial product licensed per app and per platform for running WPF software on macOS and Linux with few code changes. Teams comparing the free repository with a rewrite should include that license in the decision. The open-source path is strongest for new products or migrations that can accept code changes.
What happened when we ran it
Our 2026-08-27 sandbox did not run commit 38402fc. The container had 3 CPUs and 8 GB of RAM, but our harness had no supported C# ecosystem and Avalonia had no Dockerfile it could use as a project-supplied route. We therefore have no first-party install, build, or test result. There is also no failure log to diagnose because execution never began.
That outcome is a limit of our harness, not proof that Avalonia fails to build. It still matters to a reader expecting a container-ready source checkout: the repository does not provide that tested path for us. Our review can judge the instructions and current project activity, but it cannot turn the README's setup commands into measured evidence. Before adopting Avalonia, run a representative application on every target and record cold start, rendering, input, accessibility, packaging, and update behavior yourself.
The full source tree requires workloads that desktop-only work avoids
Avalonia's build guide says contributors need the .NET SDK version selected in global.json and an IDE that supports at least .NET 10. A full clone must include submodules. Building the broad solution also calls for Android, iOS, tvOS, Mac Catalyst, and WebAssembly workloads, while the desktop solution filter avoids extra workloads. That smaller solution is the sensible entry point for someone fixing a Windows, macOS, or Linux desktop problem.
Platform work adds platform tools. Native macOS libraries require Xcode and a separate native compile task. The guide also warns that SDK releases can break builds, which is why the repository pins a known compatible version. None of this is unusual for a framework spanning six platform families, but it makes a source contribution more involved than installing an Avalonia package into an application. App developers and framework contributors have very different setup burdens.
Avalonia 12.1.1 has fresh Wayland and headless-test reports
Open issue 22064 reports that DispatcherTimer runs late on GNOME Wayland with Avalonia 12.1.1 and .NET 10 when the window is idle. The report says pointer activity masks the behavior and that the same application is unaffected on X11. We did not reproduce it, so treat it as a focused compatibility check for timer-driven Linux interfaces rather than a verdict on the entire Wayland backend.
Open issue 22072 describes a separate discovery failure when Avalonia.Headless is paired with xUnit.v3 4.0.0. The posted stack ends in a missing method during discovery, before the sample tests execute. A team standardizing on that exact runner combination should confirm a fix or pin compatible packages before moving its UI suite. Headless testing is useful, but an adapter break can stop the suite before application assertions get a chance to run.
GNOME styling still has an open first-party request
Issue 22051 asks for an official Adwaita package and says Fluent is the only modern first-party theme available. That is a contributor request, not an accepted roadmap item. It gives Linux product teams a practical design question: consistent Avalonia styling may be acceptable, while an application expected to match GNOME closely may need community packages or its own control themes. Do not read the request as a promise that official Adwaita support is coming.
A separate open report, issue 21255, shows italic text clipping with Avalonia.Fonts.Inter on Windows in both the 11.x and 12.x lines. This kind of rendering defect is why a shared UI codebase still needs screenshot and accessibility checks per platform. Cross-platform source reduces duplicated application code; it does not make Windows, Wayland, macOS, mobile, and browser behavior identical.
The August 2026 activity supports a production trial
GitHub showed 31,401 stars and 1,896 combined open issues and pull requests when we fetched the repository. The last push was August 27, 2026, and several issues and pull requests had changed that day. Release 12.1.1 was published on July 29 with fixes across core behavior, controls, XAML, Windows, macOS, Linux backends, Android, iOS, and headless sessions. The large open count includes issues and pull requests, so it requires careful searching before adopting a control or backend.