Disclosure: This review was written by the UXDivers team. UXDivers is a software consultancy specializing in Avalonia UI development, with multiple completed desktop and mobile projects built on the framework, as well as successful WPF to XPF migration projects with measurable results.
We believe this hands-on experience gives us a grounded perspective on the ecosystem, but readers should be aware that we have a professional stake in Avalonia's success. We have made every effort to distinguish between verified facts, official announcements, and our own assessments throughout this article.
Avalonia UI has continued its trajectory as one of the most serious contenders in the cross platform .NET UI space. With version 12, the framework has doubled down on performance, rendering improvements, and expanding its reach into mobile and embedded scenarios.
However, as with any fast evolving ecosystem, separating production ready capabilities from experimental efforts is key to making informed decisions.
A partnership with Google to bring the Impeller engine to .NET has generated significant interest. The goal is to replace Skia in key areas to eliminate shader compilation stutter, also known as shader jank, and improve GPU efficiency. At the moment, the backend remains experimental and is currently paused while the team focuses on v12 and new controls.
The effort includes the public NImpeller-related work, which provides open .NET bindings to the Impeller C API. However, the full Avalonia rendering backend built on top of these bindings remains in a private internal branch. The goal is to eventually open source the backend once it reaches sufficient maturity.
It is important to note that as of late 2025, the Impeller backend exists in an internal experimental branch and is not yet publicly available or production ready.
Beyond frame rates, expectations point toward improved power efficiency and smoother animations, but these benefits remain forward looking rather than available today.
Avalonia's sustainability strategy has evolved with the introduction of Avalonia Accelerate, a commercial layer focused on tooling, documentation, and enterprise support.
The recent sponsorship agreement with Devolutions is an important milestone, but its scope is often misunderstood.
The agreement provides predictable funding directed primarily at Avalonia Accelerate's tooling and documentation, with the stated expectation that improvements will benefit the broader community. The MIT license of the core framework is contractually protected.
While the Avalonia team has indicated that this frees up resources for open source work such as Wayland support and the MAUI backend, the sponsorship itself is formally tied to Accelerate development, not to those specific community features.
That said, the boundary between open source and commercial has not been friction free. The TreeDataGrid component, for instance, has a public version in the open source core but its repository explicitly states that issues and pull requests are only reviewed for paying Accelerate customers. This kind of tiering has prompted debate within the community about the long term health of the open source contribution model.
The Devolutions sponsorship is specifically intended to reduce this tension by funding work that remains freely available to all users.
A technical mandate from Google required all apps targeting Android 15 and above that include native C or C++ code, whether directly or via NDK libraries, to support 16 KB page sizes starting November 1st, 2025. Apps written entirely in managed .NET code without native dependencies are already compatible and required no changes.
You can read more in the official Android documentation:
Android Developers
Google's benchmarks for 16 KB page sizes on Android 15 show an average of 3.16 percent faster app launch times, with improvements up to 30 percent in some cases.
It is worth noting that Devolutions is also Avalonia's lead sponsor, which means their feedback should be interpreted in that context rather than as independent third party validation.
Early Avalonia v12 adopters report smoother mobile deployments and reduced startup latency on mid range Android hardware, consistent with these platform level gains.
Avalonia has also been exploring interoperability with the .NET MAUI ecosystem.
Demos like MauiPlanets already run on .NET 10 with minimal changes. It is worth noting that this is still an early stage effort. The current build has rough edges and is not production ready.
Additionally, while the Avalonia team has developed this with feedback from engineers in the MAUI ecosystem, this does not constitute official Microsoft endorsement or a first party partnership. Enterprises requiring vendor backed SLAs should confirm support scope directly with both teams.
The .NET UI ecosystem is more competitive than ever.
Microsoft continues to position WinUI 3 for Windows exclusive applications. .NET MAUI remains a solid choice for mobile first teams that prefer native controls per platform.
Uno Platform is a direct competitor to Avalonia in the cross platform .NET space and deserves explicit mention. Since version 6.0, it also offers a unified Skia based drawn rendering engine as its default, achieving pixel perfect consistency across all targets including WebAssembly, mobile, and desktop, while additionally maintaining a native controls rendering mode as an option. Its API surface is aligned with WinUI and UWP XAML, making it a natural fit for teams migrating from Windows centric stacks.
Avalonia's differentiators in this context are more specific. Its API is closer to WPF, making it the stronger choice for WPF to XPF migrations. Its desktop and embedded Linux track record is more mature, and its single focus on the drawn model has historically resulted in a more consistent desktop experience.
The choice between Avalonia and Uno Platform often comes down to the team's existing XAML background and whether WebAssembly or embedded Linux is the primary target.
Avalonia's drawn controls model also comes with trade offs worth acknowledging.
Because controls are rendered rather than native, applications do not automatically inherit the platform's native look and feel. This is a deliberate design choice that offers consistency but may feel out of place on some platforms for users accustomed to native aesthetics.
The tooling ecosystem, while improving, still lacks a visual designer comparable to Blend for WPF. The third party control library, though growing, remains smaller than those available for WPF or WinForms.
Teams evaluating Avalonia for mobile should also note that while Android and iOS support has matured, the framework's primary investment and production track record remain strongest on desktop platforms.
One nuance worth flagging is that Avalonia's mobile story has improved significantly in recent years, but the framework's primary focus, community, and production track record remain centered on desktop. Teams building mobile first applications should evaluate current mobile feature parity and tooling carefully before committing.
Avalonia in 2026 is no longer an emerging option. It is a serious platform with real production use in demanding environments.
Understanding its actual maturity curve is critical.
Some capabilities are production ready today. Others are actively evolving. And a few remain experimental or internal.
For teams working on complex products, especially in desktop, embedded, and regulated environments, Avalonia represents one of the most compelling paths forward in the .NET ecosystem.
