WPF is twenty years old this year. It was the most ambitious desktop UI framework Microsoft ever shipped, and two decades later, it still powers a huge amount of the mission-critical software in almost every industry. From trading desks, hospital information systems, satellite ground stations, audio mixing consoles, CAD packages, airline operations terminals, and manufacturing HMIs. If you have used a piece of professional Windows software in the last two decades, the chances are very high that it was built with WPF.
The decision a CTO makes in 2026 about what to do with a critical WPF investment is not a tooling question. It is a 10- to 15-year commitment that will shape aspects such as recruiting, deployment, security posture, customer experience, and roadmap velocity. If they get it right, they free up engineering capacity to build what their customers are actually asking for. Get it wrong, and they spend years effectively reinventing the wheel by rewriting a working product into something that looks similar enough that customers will assume you're not investing in the software.
I work at Avalonia, so I have an obvious horse in this race, but I've also spent most of my professional career working with teams that face this exact scenario. While an organisation may migrate a WPF app once or twice, we help customers do it every week. That knowledge gives us a unique perspective on what a pragmatic migration in 2026 looks like.
While directing everyone to Avalonia would be easy, it's not always the right choice. We're always happy to tell a prospect that they've missed something critical or that we think their strategy is poor, even when that means recommending alternative solutions. A phrase I used to use at Microsoft (much to my manager's frustration) was "I work for the customer, Microsoft just happens to pay my wage". That's a strongly held belief and one I apply to Avalonia. We're outcome-driven and would rather recommend against ourselves on this opportunity and remain a trusted partner than burn our credibility for a short-term increase in revenue.
With all that said, what I want to do in this piece is something the existing literature on WPF modernization has refused to do, which is to give you a complete, fair, opinionated tour of every serious option in 2026, including the competition. Most WPF modernization guides published this year discuss every option except the one with the largest community and the broadest production footprint, which suggests the authors' competitive anxiety rather than the technology landscape. Better to acknowledge the bias upfront and earn your trust through the quality of the analysis than to ignore the elephant in the room.
Here is the conclusion stated plainly so you can decide whether to keep reading.
For most WPF applications in production today, the right answer is often to stay on WPF. If you absolutely must run the app on macOS and/or Linux, you can do so with Avalonia XPF, which will get you up and running on the new platforms quickly and reduce your risk.
For applications that truly need a rewrite, the most sensible target in 2026 is Avalonia, but even that depends on your tolerance for risk, long-term goals, competitive landscape and many other factors.
Let me walk you through how I think about WPF modernization.
The question almost everyone asks first is the wrong one
The conversation usually starts with a comparison of frameworks. Someone forwards a link to a "5 best frameworks for X" article, the architects start arguing over XAML dialects, and reasonably quickly, a spreadsheet with green ticks and red crosses is passed around the leadership team. This is the wrong place to start.
Do I need to modernize?
The right starting question is whether you need to modernize at all. WPF isn't deprecated. It ships with .NET 10, is open source, has maintainers, and works. "Do I need to modernize?" is not the same question as "Are my users complaining today?" It's a strategic question about your application's future. Will it be critical to the business for the next decade, or is it a legacy system that could be retired in a few years? Is the team maintaining it growing, or shrinking? Will the customers you want in 2036 accept a Windows-only product? If the application has a finite remaining lifespan and your users are not asking for new platforms, the most disciplined answer is to do nothing. Save the rewrite effort and budget for features your users actually want. There is real wisdom in leaving a working system alone. But if the app is software the business absolutely depends on for the long term, "nobody is asking for macOS yet" is not the same as "nobody will ever ask for macOS," and the cost of acting later is almost always higher than the cost of acting now.
Why are we doing this?
The second question, which is only relevant if you've decided you need to do something, is whether the change is driven by platform reach or by user experience. These are completely different problems and require different solutions. A team that needs to port their existing functionality to macOS because three large customers run on Apple silicon has a platform reach problem. A team whose UI feels dated and whose touch story is broken has a user experience problem. Conflating the two is how teams end up choosing rewrite when they could have chosen port, or choosing port when they actually needed to rewrite.
Do we have the ability to execute this?
The third question, and this one matters more than any framework choice, is what your team can realistically execute. A two-year cross-platform rewrite by a team that has never shipped on anything other than Windows is a different proposition from the same rewrite by a team with deep macOS and Linux knowledge. Be brutally honest about your starting position. The right answer for a 50-person engineering organisation is not the same as the right answer for a three-person team holding together a 2.5-million-line WPF application that nobody fully understands.
Once you have answered those three questions, then we can talk about frameworks.
The costs nobody puts in the comparison spreadsheet
Before we walk through each option, it's worth discussing the factors we consistently see that influence whether a migration succeeds or fails, since they typically don't appear on any comparison feature matrix.
Stability
The first is the churn rate of the framework itself. Microsoft's XAML history is a strong case study in how to erode developer confidence in a framework's future. WPF arrived as the rich desktop future for .NET. Silverlight pulled XAML towards the browser and the cross-platform plug-in era, then was discontinued. Windows 8 introduced Metro and WinRT XAML. Windows 10 recast that work as UWP. Desktop Bridge and XAML Islands then tried to glue UWP back onto the Win32 and WPF surfaces it had been positioned against. WinUI 2 repackaged the UWP controls. WinUI 3 moved the UI stack out of the OS and into a separately shipped framework. The Windows App SDK is now the umbrella story bundling modern Windows features across WinUI, WPF, WinForms and Win32, and Microsoft's current guidance is that the SDK is the recommended way to access modern Windows platform features from both existing desktop apps and new WinUI 3 applications. Whether that guidance still holds in 2036 is anyone's guess.
Mobile has a similar story, albeit a shorter read. Xamarin.Forms gave .NET teams a single XAML-based way to target iOS and Android. It matured over the better part of a decade, and built a real ecosystem of control vendors, libraries and shipping applications from some big names. Rather than iterate on Xamarin.Forms, .NET MAUI arrived as a successor and effectively reset the ecosystem. The XAML dialect changed, the project structure changed, the handler architecture replaced renderers, and the third-party control vendors had to rebuild against a new surface. Teams that had invested in Xamarin.Forms found themselves doing migration work rather than feature work, and the community momentum that had taken years to build had to start accumulating again from a lower base.
The timing made it worse. MAUI shipped earlier than the engineering was ready for, and the early reception reflected that. Teams who picked it up in the first wave found themselves working around bugs and gaps that would have been caught with another release cycle, and the impressions formed in those months have been hard to reset since. The deeper problem, though, was that the ecosystem MAUI launched into looked nothing like the one Xamarin.Forms had launched a decade earlier. When Xamarin.Forms appeared, the realistic alternatives for a .NET team were "stay on .NET" or "rewrite in two native codebases", and the answer was obvious. By the time MAUI shipped, Flutter was mature, React Native was widely deployed, and a team being told to rewrite their mobile application had a genuine question to ask: if we're rewriting anyway, why are we rewriting into another .NET MAUI rather than onto a platform with a larger talent pool and a faster-moving ecosystem? For a meaningful slice of the Xamarin.Forms install base, the honest answer was that they weren't, and they left.
Each of those transitions required work from teams who had bet on the previous step. In aggregate, those teams have spent years rewriting working software to keep up with a strategy that kept changing underneath them. None of that engineering time produced a feature that their customers asked for.
There is a pattern at the centre of all this: the two frameworks that have survived everything are the ones Microsoft has invested in the least. WinForms is twenty-five years old and still the safest pick for an internal Windows tool. WPF is twenty years old and still powering the most demanding desktop applications. They survived precisely because they were left alone. No annual reorg, no rebranding, no urgent migration to the next 'latest thing'. They just kept working. For enterprise software, that kind of stability is a feature.
Hiring pool
The second is hiring. The pool of developers who have already shipped a production application in your chosen framework determines how fast you can grow your team and how much you pay each hire. It also determines how quickly a new joiner becomes useful, which is the cost most teams underestimate.
WPF has a deep talent pool to hire from. Two decades of enterprise software have produced millions of experienced WPF developers, and they are not a scarce resource. The strategically important point is that any experienced WPF developer will be productive in Avalonia within a few days, because the concepts they took years to internalise (XAML, the dependency property system, MVVM, control templates, styles, data binding) all carry over. The dialect has been refined, but the mental model is the same one they already have. Our WPF to Avalonia migration guide walks through the differences in detail and is the fastest way to confirm this for yourself before you commit to anything.
That single fact effectively collapses the WPF and Avalonia hiring pools into one. No other cross-platform .NET UI framework can make that claim. Every alternative on this list asks your hiring manager to find developers in a smaller, less proven, more expensive market, or asks your existing senior engineers to spend months becoming productive in a framework where their WPF expertise no longer compounds.
A decent senior engineer will become productive with almost any technology, but the cost shows up in a subtler way. The further the new framework sits from the engineer's mental model and lived experience, the more you are paying for capability without paying for scars. The senior who has shipped a production WPF application has internalised a long list of unwritten lessons. All of that needs to be built from scratch with a new framework.
Hiring and team enablement are where community size shows up most painfully when you've made the wrong choice, and it shows up constantly.
Framework Ecosystem
The third is the third-party ecosystem catching up to you. If you adopt a framework whose control ecosystem is tiny, you will end up writing controls that off-the-shelf vendors would have built for you. The cost of building a custom data grid or PDF viewer is not just measured in weeks. It is measured in years of ongoing maintenance, in the small army of edge cases that ships with every serious control, and in the engineering attention diverted from the parts of your application your customers actually pay for.
UI frameworks live and die by the ecosystem that they exist in. A framework with a deep, healthy ecosystem of commercial and open-source controls is one your team can build on without reinventing the wheel for every new feature. A framework whose ecosystem is shrinking, or never quite materialised in the first place, is one where every release surfaces another control you now have to own yourself. The economics are straightforward and unforgiving. Once a framework loses the confidence of its vendor ecosystem, winning that confidence back is extraordinarily hard.
WinUI is a vendor-ecosystem cautionary tale. The control vendors who built early WinUI support found that the sales did not justify the engineering investment, and the churn discussed earlier meant the work they had done kept needing to be redone. The shrinking of a 3rd party control ecosystem is a death knell for any platform.
Avalonia is on the other side of that dynamic. The vendor list now includes Actipro, Steema, yFiles, and a growing roster of others, with new conversations starting every quarter as adoption compounds. The open-source control ecosystem has matured to cover most categories a serious application needs. And because XPF is API-compatible with WPF and can be mixed with Avalonia in the same application, an Avalonia team can today consume the entire mature WPF control ecosystem, including DevExpress, Syncfusion, Telerik, and Infragistics, without waiting for those vendors to ship native Avalonia versions. By any reasonable measure, Avalonia has the largest third-party ecosystem in cross-platform .NET, and the gap is widening rather than narrowing.
This is the part of the framework decision that compounds quietly. Once a framework becomes the centre of gravity in its category, vendors invest there because that is where the buyers are; buyers stay because that is where the controls are; and the chicken-and-egg dynamic protects against late entrants.
Sustainability
The fourth is the framework vendor's commercial sustainability, which sits underneath the other three and tends to determine how each of them plays out over time. Stability, hiring pool depth, and ecosystem health are all downstream of whether the people building the framework are still building it in five years, and on what terms.
Avalonia is not a side project that subsidises something else, and it is not a marketing surface for a different business model hiding underneath. It's the business. If we stop investing in it, the company will cease to exist. That alignment of incentives is the structural reality that determines what we can and cannot afford to ignore. Customer satisfaction, engineering quality, and long-term roadmap velocity are our priorities, and they aren't competing with another product line for engineering attention or board time. We have been deliberate about the kind of company we're building, and we have rejected the kinds of investment that would have changed that.
The practical consequence is that the questions an enterprise customer asks before they commit ("will you still be here in five years", "will the engineers I trained on this framework still be here", "will the roadmap still match what I need") have the same answer year after year. That predictability isn't glamorous, but it is the part of the relationship that does the heavy lifting once the migration is done and the engineering team has moved on to other things.
Keep these four costs in mind as you read the framework-by-framework analysis that follows.
What is actually on the table in 2026
The shortlist most teams arrive at includes some combination of WPF (stay put), Avalonia XPF, Avalonia, .NET MAUI, Uno Platform, OpenSilver, WinUI 3, Blazor Hybrid and Electron.
Each solves a different problem, has a different cost profile and carries a different set of risks. The trick is to be precise about what each one actually is, because everyone in this category, ourselves included, tends to describe their own product in language that blurs the boundaries more than they should.
Stay on WPF
Worth saying out loud again. WPF in 2026 is in better shape than it has been for years. It's open source, works with the latest version of .NET, gets (modest) improvements with each release, and the Visual Studio experience is the most mature you will find anywhere. If your users are happy on Windows and your roadmap does not require new platforms, doing nothing is a legitimate, low-risk choice. Doing nothing will free your team to work on differentiated functionality, which can be far more impactful for your business than additional platform support.
The reason most teams decide that doing nothing isn't a workable strategy is that Windows isn't the default anymore. The share of macOS usage among professional users keeps climbing, Linux has become standard for engineering and infrastructure customers, and a meaningful slice of buyers will not even put your product through procurement if it's Windows-only. If any of that describes your customer base, you'll need to address it. But that doesn't always mean "rewrite the app".
Avalonia XPF
Let's start with the option I am most confident about, which is also the option we (Avalonia) created, so take this as a very biased perspective.
Avalonia XPF is a cross-platform fork of WPF. It's the same XAML dialect, the same control set, the same data binding, the same triggers, the same templates. You take your existing WPF application, update the target SDK, and it'll run natively on macOS and Linux with little to no changes required. The codebase remains WPF, but it can run on additional platforms.
From a technical perspective, XPF is a fork of WPF that replaces the Windows-specific rendering (MILCore), windowing, and input layers with cross-platform implementations built on Avalonia. The XAML parser is the same. The dependency property system is the same. The visual and logical trees behave identically. Triggers, templates, styles, data binding, commands, routed events, and the whole conceptual machinery are preserved. What changes underneath is the part nobody outside the framework team should ever think about.
The deployment story is equally as simple. On Windows, the application can keep using WPF or switch to XPF for consistency. On macOS, you ship a native .app bundle that signs with Apple Developer ID, notarises through Apple's notary service, and installs the way macOS users expect. On Linux, you can ship AppImage, Flatpak, deb or rpm depending on your customers' distributions. The application is a real native application on each platform, not a wrapper around a web view, not a virtualised Windows runtime, not a translation or emulation layer with a noticeable performance penalty.
Being built on top of Avalonia allows mixing XPF and Avalonia code in the same app, including the same views. That means XPF can act as a stepping stone rather than a destination. A team can adopt XPF first to gain immediate cross-platform reach, then incrementally port to Avalonia, ultimately ending up with a 100% Avalonia application, without having to pause development for years to migrate.
As a small, engineering-led company, XPF's sales process is pretty simple. We try to get you onto a trial as quickly as possible, so you can see your apps on new platforms yourself. We don't have a single 'XPF Pitch Deck' or sales script in the company. We found that the product sells itself far better than we can.
Who uses XPF, and why
The XPF customer list is concentrated in industries where any issues with the software are not acceptable outcomes. Our customers include KLM, Autodesk, Siemens, Stryker, Solid State Logic, Keysight, COMSOL, OMRON, Komax, Okta, and RocketLab. They adopt XPF because they have mission-critical applications that must continue to work, and the risk and time required for a rewrite are too high.
What makes the XPF unusual is the repeat purchase behaviour. XPF is a perpetual licence. WPF is stable. There is no contractual reason to renew an XPF license. Despite that, most organisations decide to renew their licenses. When a customer buys a perpetual licence and then comes back to buy again, that tells you something about the product.
The honest caveats
XPF is commercial software with a licence fee, and it's worth addressing the cost directly. If compared to a paid component library, the number will look significant. But that is the wrong comparison. XPF is not a set of UI components. It's a risk-reducing modernization strategy that gets your application onto new platforms in weeks rather than years, backed by SLA support from the team that built the cross-platform rendering pipeline underneath it. The right comparison is the cost of a rewrite: the engineers, the timeline, the opportunity cost of features not shipped, the risk of a half-finished migration that never quite lands. Against that number, XPF is a fraction of the cost and risk. If anything goes wrong, you have the best cross-platform .NET engineering team available to get you unblocked. That's what the licence buys you.
XPF's sweet spot is desktop: Windows, macOS, and Linux. While we do support mobile and WebAssembly through our Enterprise tier, it's worth understanding why we try to avoid this. Taking a desktop WPF application to a mobile device or to the browser is a fundamentally bigger lift than taking it to another desktop platform. The interaction models are wildly different, and the assumptions baked into a decade of desktop UI design do not translate automatically. It works, and we have the engineering team to support customers through it, but the pricing reflects the reality that this is closer to a guided modernization engagement than a drop-in migration. In most cases, we will steer you towards a more pragmatic route first, whether that is Avalonia native for mobile or adopting Blazor, because the right answer for our prospects matters more to us than selling a license.
Although XPF includes almost all of the WPF APIs, if your app P/Invokes Win32 APIs, you'll still need some work to go cross-platform. It's the reason to run a trial, because the trial will tell you very quickly whether your codebase is one of the easy ones or one of the harder ones to migrate.
For most teams with a meaningful WPF investment, this is where the analysis ends.
Avalonia
If you have concluded that a rewrite really is the right call, perhaps because the UI is dated, the architecture is groaning, or your team wants something more modern to work on, then the question becomes what you rewrite into. My (biased) recommendation is Avalonia.
Avalonia is a drawn UI framework for .NET. It runs on Windows, macOS, Linux, iOS, Android, WebAssembly and embedded Linux. It's open source under the MIT licence, has been in production for over a decade, and is used by JetBrains, AMD, GitHub, Lenovo, Samsung, Unity, and thousands of other organisations, large and small. In 2025 alone, more than 2.1 million unique projects were built with Avalonia, with growth running at roughly 30 per cent month over month. We are, by a clear margin, the leading cross-platform UI framework in the .NET ecosystem.
The technical reason Avalonia is the natural rewrite target from WPF is that the API is familiar. XAML, data binding, MVVM, styles, control templates, dependency properties. A WPF developer can be productive in Avalonia in a day or two. The dialect is not identical, but the concepts are close enough that it feels like expertise rather than starting over.
The strategic reason Avalonia is the right rewrite target is structural rather than technical. The framework is the product. The company exists to build it; revenue comes from people who depend on it; and there is no second business waiting in the wings to absorb the engineering team's attention. Most of the alternatives on this list have a different relationship with the people who build them, and over a decade-long commitment, that relationship matters more than any single feature comparison.
Why the technical design matters
Three pieces of the Avalonia architecture explain why the framework has captured a dominant position.
The first is the drawn UI. Avalonia doesn't abstract over native controls. Every pixel is rendered by Avalonia's own pipeline, ensuring pixel-identical behaviour across all platforms. There is no "well, it works on Windows, but the macOS native control doesn't have that property" conversation, because there is no macOS native control involved. Every cross-platform UI framework that wraps native controls eventually runs into the wall where the platforms expose subtly different surfaces, and the rest of your life is spent writing platform-specific workarounds. The drawn approach sidesteps the problem entirely.
The second is the XAML dialect. Avalonia didn't set out to clone WPF's XAML. It set out to take a XAML dialect that's already known, had two decades of production validation behind it, and ask what could be done better with the benefit of fifteen years of hindsight. In some places, the answer was nothing. The answer in others was a small change with a meaningful payoff. Selectors borrow from CSS, which gives you a styling model most of your developers already understand from the web. Data binding has been simplified in places where WPF's design produced verbose code. The property system was rebuilt with lessons learned from watching real WPF applications run for a decade, including those where memory pressure became a problem at scale. These changes were made because the original WPF design was strong enough to preserve, but worth a little bit of refinement.
The result is that a WPF developer recognises almost everything. They open an Avalonia project, and the structure is immediately legible. They write a binding, and it works the way they expect. They write a style, and it does what they meant. The rough edges they had grown used to working around in WPF, the ones they assumed were just how XAML had to be, are mostly gone. That is not a small productivity gain. It is the part of working in Avalonia that experienced WPF developers comment on first, because the framework respects what they already know and quietly removes the friction they had stopped noticing.
The third is ecosystem trajectory. The third-party control story for Avalonia has matured substantially over the past two years, and the trajectory is accelerating. Actipro ships Avalonia controls today, yWorks and Scheema are in the market, and the open-source control ecosystem has grown to cover most common categories. We have active relationships with the major .NET control vendors, and more are investing in Avalonia support as adoption compounds. Two years ago, the ecosystem was a genuine gap. Today it is a strength, and for most application categories, a serious product can be built on familiar commercial and open-source components rather than from scratch.
There is also a path that no other framework can offer. Because XPF is API-compatible with WPF and can mix with Avalonia in the same application, you can use an XPF licence to consume existing WPF controls inside an Avalonia application. That means the entire mature WPF control ecosystem, DevExpress, Syncfusion, Telerik, Infragistics, and the rest, is available to an Avalonia team today, without waiting for those vendors to ship native Avalonia versions. No other cross-platform .NET framework can make that claim.
The honest caveats
Avalonia isn't a drop-in replacement for WPF. The XAML dialects are similar but not identical, so a copy-paste rewrite will not work. Some advanced WPF features have different idioms in Avalonia, and the control set, while comprehensive, is not bug-for-bug compatible. If your goal is to keep your existing codebase running unchanged, you want XPF, not Avalonia. Avalonia is the right answer when you have decided a rewrite is justified.
One more thing worth being upfront about. Avalonia is MIT-licensed, and the framework is free, but the tooling that professional teams depend on is not. We provide a Visual Studio Code extension entirely for free, but our Visual Studio extension, DevTools, and advanced tooling require a paid subscription. This is how we fund the development of Avalonia itself, and it is a model we believe in: the framework is open and free forever, the productivity tooling that sits on top of it sustains the engineering team that builds and maintains it. You can build a production application without paying us a penny. Most professional teams choose to pay because the tooling makes them meaningfully faster.
.NET MAUI
MAUI is Microsoft's official answer to cross-platform .NET. It is built primarily for mobile, descended from Xamarin Forms, and targets iOS, Android, Mac Catalyst and Windows. Its strengths are real: the mobile story is mature, the Visual Studio integration is deep, the Microsoft brand reassures procurement, and there is a respectable third-party control ecosystem.
The honest weaknesses are also real. MAUI has no Linux support and no announced plans to add it. The XAML dialect diverges meaningfully from WPF. The desktop story on macOS, via Mac Catalyst, is essentially "iPad app running on a Mac", which is not what most professional desktop users want. And the control set on the desktop is missing pieces that a WPF developer takes for granted.
For a WPF migration specifically, MAUI is rarely the right answer. The XAML rewrite cost is high, the Linux gap is disqualifying for many teams, and the desktop experience does not match the polish a professional WPF customer expects. If you have already committed to MAUI and you want Linux or web, our MAUI partnership is a path that does not require you to rewrite anything. But if you are starting from a WPF codebase and choosing fresh, build on Avalonia directly and skip the abstraction layer.
Uno Platform
Uno Platform is a .NET UI framework that implements the WinUI 3 API surface across additional platforms, including macOS, Linux, iOS, Android and the browser. The technical achievement is significant. They have reached a wide platform matrix, their WebAssembly story is mature, and their Hot Design runtime designer represents serious engineering effort.
For a WPF team specifically, there are four things worth weighing before committing.
The WinUI dependency
Uno implements the WinUI 3 API surface, which means Uno does not control its own API. Microsoft does. If Microsoft changes direction on WinUI, Uno follows.
This is not hypothetical. Uno was originally a reimplementation of UWP. When Microsoft replaced UWP with WinUI, Uno had to reimplement against the new surface. That's the structural cost of building on someone else's API, and it is the risk that does not exist with Avalonia because we own ours. For a framework choice measured in decades, API ownership is one of the most consequential differences on this list.
Community and ecosystem size
The gap between the two communities is larger than you might imagine, and the public signals are unambiguous. On GitHub, Avalonia has significantly more stars, more contributors, and several times as many dependent repositories as Uno. That last figure is the most telling, because dependents measure real adoption rather than enthusiasm.
NuGet download totals are less reliable for comparison because both projects publish pre-release and nightly builds that inflate the raw counts. But on stable releases of comparable age, Avalonia sits at roughly three times Uno's volume. Across every public adoption signal that actually tracks production use, the direction is the same.
Uno has done genuinely good work on marketing and community enablement, and we have historically been weaker at both. For a decade-long framework choice, though, the question is whether the community is large enough that your questions get answered, the controls you need already exist, and the framework still has momentum in 2036. Community size and community visibility are different things, and the former matters more for the decision you are making.
Funding model
Uno is venture-backed, and Avalonia is not. That is a structural difference worth understanding, because it shapes incentives.
Venture-backed companies have to grow into their valuations, and when a market does not grow fast enough to support that, the company pivots. Xamarin, at its peak, reached a run rate of roughly $50 million a year as the undisputed market leader in cross-platform .NET before Microsoft acquired it. That is a useful reference point for the ceiling on this category. It is a healthy market that can sustain a strong independent business.
Whether it is a market that can deliver venture-scale returns is a different question, and it is the question that every venture-backed company in this space eventually has to answer for their investors.
Avalonia is funded by customer revenue and long-term sponsorship. Our incentives align with our customers' long-term stability, year after year. We are not building towards an exit. We are building a durable business whose interests stay aligned with the interests of the people who depend on it.
The rendering architecture
For most of its life, Uno mapped its controls to native platform primitives. Avalonia took the opposite approach from day one and has always been a drawn UI framework. The case we made, that drawn UI is the only way to deliver consistent behaviour across platforms and to control performance from the ground up, was the minority position for years.
In 2025, Uno switched their default renderer to SkiaSharp, which is the same architectural approach Avalonia has used since the beginning. We welcome the convergence, and it is worth being direct: the industry has now validated the architectural choice we made a decade ago. While Uno adopts SkiaSharp to close the rendering gap, we are already working with Google's Flutter team on the Impeller GPU renderer as Avalonia's next-generation backend.
Where Uno fits
None of this is to say that Uno isn't a serious framework. It is, and the engineering team behind it is capable. If you already have a WinUI 3 project and need to extend it to other platforms with minimal disruption, Uno is a reasonable choice. For a WPF migration specifically, the picture is different. You would be learning a different XAML dialect, committing to a Microsoft-owned API surface the broader market has not adopted, and accepting a smaller community and ecosystem than the alternative. That is a lot of structural commitment to take on when there is a more independent, more widely adopted option that controls its own API and is funded directly by the customers it serves.
OpenSilver
OpenSilver is an open-source reimplementation of Microsoft Silverlight that compiles .NET to WebAssembly and renders through the browser DOM. The team behind it, Userware, has layered WPF-flavoured APIs on top of the Silverlight core, and they make their money helping you complete the port, which means their incentive is genuinely aligned with your migration succeeding. The DOM-based rendering also gives you browser-native accessibility, text selection, screen reader support and zoom essentially for free, which is a real advantage if browser-native behaviour is a hard requirement.
The challenge for a WPF team is that the heritage is Silverlight, not WPF, and those were always two different frameworks. Different control sets, different XAML dialects, different binding systems, different lifecycles. When we say XPF is cross-platform WPF, the claim is verifiable at the source level: we forked the WPF codebase and replaced the rendering engine. OpenSilver took a different path. It reimplemented Silverlight and added WPF-inspired APIs on top, which is a legitimate engineering approach, but the distance between "WPF-inspired" and "WPF-compatible" is where production migrations will get stuck.
The third-party control story is where this matters most in practice. None of the mature WPF control vendors work with OpenSilver. If your application depends on DevExpress, Syncfusion, Telerik or Infragistics controls, and most serious WPF applications depend on at least one, you are looking at either reimplementing those controls yourself or commissioning someone to build them. Compare that to XPF, where those same vendor controls work without modification because XPF is WPF. For most production applications, that single difference determines whether a migration finishes at all.
Silverlight reached its end of support in October 2021, and the addressable market for pure Silverlight migrations has largely moved on. OpenSilver's pivot towards WPF compatibility is a sensible commercial response, and the team deserves credit for finding a path forward. But for a team evaluating this as a WPF modernization strategy, the gap between the Silverlight foundation and WPF's full surface area is structural, not cosmetic, and it is worth understanding before you commit engineering time to this approach.
Where OpenSilver fits well: if you have an actual Silverlight codebase that never migrated, or a relatively simple WPF application that lives within the Silverlight feature subset with no heavy third-party control dependencies and browser-native rendering as the binding constraint. For those scenarios, it is a genuinely good option. For a complex production WPF application with a deep control dependency graph, the other paths on this list will get you further.
WinUI 3 and the Windows App SDK
WinUI 3 is Microsoft's current Windows desktop UI framework, the successor to UWP, packaged inside the Windows App SDK. It is the framework that Uno has reimplemented for other platforms.
For a WPF team, the analysis is brief. WinUI is Windows-only, full stop. There is no cross-platform path. The XAML dialect is similar in concept but different in detail, so a port is non-trivial. Some WPF controls have no direct WinUI equivalent. And Microsoft's long-term commitment to WinUI as a strategic platform has been less than emphatic.
If you wanted a Windows-only modern XAML framework, you already have WPF, and WPF has a more mature ecosystem and a much larger community. The latest version of WPF ships with a Fluent theme, and WPF applications can be distributed through the Microsoft Store. The two arguments that were used to justify choosing WinUI over WPF no longer apply. If you want cross-platform reach, WinUI does not provide it. It is difficult to find a scenario in 2026 where WinUI is the right answer for a WPF team.
Blazor Hybrid
Blazor Hybrid puts a web-rendered UI inside a desktop shell, letting you build screens in Razor and HTML and reuse them on the web. None of your XAML, styles, templates or controls work transfers. You are writing HTML, CSS and Razor, which is a different programming model in nearly every respect. Your XAML developers become web developers, with all the retraining that implies.
The rendering surface is a WebView, which means your performance ceiling is set by the underlying browser engine. On Windows, that is WebView2, on macOS, that's WKWebView, and they do not behave identically. Linux desktop support is not first-class.
For a team whose application is fundamentally form-and-table heavy, Blazor Hybrid is a reasonable choice. For a team coming from WPF with custom rendering, complex control composition or smooth animations, it is the wrong answer. And if your tolerance for risk, cost, and timeline is high enough that Blazor Hybrid looks like a serious contender, it is high enough to warrant evaluating every other option on this list, because several of them will get you further for less.
Electron and web shells
Electron means walking away from .NET as a UI surface. You can keep .NET on the back end if you want, but the front end is now JavaScript and HTML. You are not modernising your WPF application. You are replacing it. The resource cost is also non-trivial: each Electron app bundles its own browser engine, with the typical baseline starting around a hundred megabytes of disk and a couple of hundred megabytes of memory before your application has done anything.
VS Code, Slack, Discord and Figma are all excellent Electron products. If you are happy to leave the .NET ecosystem for your client, Electron is a real option. If you want to stay in .NET, it is not on the table.
What a sensible migration actually looks like
I think it's worth being clear about realistic timelines.
For an XPF migration of an existing WPF application with around 2M lines, and a typical control mix, the realistic timeline from first commit to a macOS build running in front of a real customer is 3 to 6 weeks. Mileage varies. Our quickest trial-to-sale, including vendor onboarding with procurement, was two weeks. Most customers know within a day or two whether their application will run well enough to continue testing.
The honest reality is that most WPF applications were never designed to run on anything other than Windows. The first few hours of an XPF trial are usually spent fixing assumptions that nobody ever had a reason to question: hardcoded backslashes instead of Path.Combine, registry calls and other Windows-only assumptions. These are not XPF issues to fix; they're decisions that were perfectly reasonable when the application only had to run on Windows, but that surface immediately when it does not. Once those are fixed, the next few weeks are incremental polishing of the macOS and Linux behaviour, and the final stretch is hardening, packaging, signing, notarization, and deployment plumbing.
For a full Avalonia rewrite of a comparably sized application, the realistic timeline is six to eighteen months. The well-run rewrites we see have a few things in common. They ring-fence a small senior team, accept that the rewritten application will look different rather than pixel-identical, ship internal builds early, avoid adding new features during the rewrite, and involve customer success in defining what "good enough to release" means. The rewrites that go wrong almost always do so because the team tried to redesign the application while porting it.
For a .NET MAUI, Uno Platform, Blazor Hybrid, or Electron rewrite, the timeline is comparable to or longer than an Avalonia rewrite, because the underlying work is similar in scale, and the additional cost of learning a less familiar programming model offsets any framework-specific advantage.
Whichever path you choose, my advice is to plan for the unknown. The first 80 per cent of any UI migration goes faster than expected. The last 20 per cent is where the platform-specific subtleties live, and that last slice determines whether you ship on time.
Where this leaves us
If you have been counting, the matrix shrinks fast once you apply the constraints of a real WPF migration.
Stay on WPF if you do not need new platforms. Adopt XPF if you do need new platforms, but the codebase is fundamentally sound. Rewrite to Avalonia if the codebase truly needs replacing, or you need mobile and web reach. The other options are either Windows-only, a different programming model entirely, or carry structural risks that should give a pragmatic architect pause.
The reason this is the answer for most teams is not that Avalonia is technically perfect. No framework is. It is that the combination of API familiarity for WPF developers, true cross-platform reach including Linux and embedded, an MIT-licensed open-source core, a profitable independent company behind it, the largest community in the .NET cross-platform UI category, and a serious enterprise customer base adds up to a risk profile no other option can match. You are picking a framework you will live with for a decade. The right question is not "what has the slickest demo today" but "which choice gives me the highest probability of still being happy with this decision in 2036."
The questions every WPF engineering team asks before they commit
Four questions come up in almost every conversation we have with WPF teams considering Avalonia or XPF. They need clean answers before any procurement process can start.
Licensing
Avalonia is free. MIT-licensed open source, no per-seat cost, no per-deployment cost, no commercial restriction. You can purchase improved tooling, advanced UI components and support, but it's entirely optional.
Avalonia XPF is commercial because maintaining a WPF-compatible API surface against an evolving Avalonia core is a non-trivial ongoing investment. The Internal tier is €9,500 per year for WPF applications used inside your organisation. The Business tier is €29,500 per year for applications shipped to customers. Mobile and WebAssembly support starts at €124,500 per year. There is no per-deployment fee inside any tier and no surprise scaling charges. The model is designed to be predictable for a five to ten-year planning horizon.
Support
Both Avalonia and XPF come with SLA-backed commercial support. Support contracts include defined response times, escalation paths, security advisories, and access to private builds for hot fixes when an enterprise change window will not wait for the next public release.
Third-party controls
For Avalonia, the vendor list now includes Actipro, yWorks, Steema, and a growing roster of others, alongside a mature open-source control ecosystem.
For XPF, the picture is simpler still: XPF is API-compatible with WPF, so the major component vendors, including DevExpress, Syncfusion and Telerik, work without code changes. You bring your existing licences and dependencies across, and they work. That is one of the largest practical advantages XPF has over every alternative on this list.
Roadmap
For Avalonia, the headline items are the Impeller renderer in partnership with Google's Flutter team, deeper integration with our MCP server and AI-assisted development workflow, ongoing investment in professional developer tooling, and the work to land MAUI on Avalonia.
For XPF, the next major release is XPF 2.0, due later this year. Built on Avalonia 12, it brings Wayland support, Linux accessibility, native media player support, and substantial performance improvements. For new customers evaluating XPF now, the 2.0 release lifts the platform's ceiling considerably, particularly on Linux.
The pattern across both roadmaps is the same: we invest in the platform our customers depend on, year after year, with funding from customer revenue and long-term sponsorship. That predictability is the part of the roadmap that matters most for a decade-long commitment.
How to start
If you are a WPF team thinking through this decision, the cheapest and most informative move you can make this quarter is to take your application, follow the XPF migration guide, and see how close you get to running on a Mac or Linux VM in an afternoon. The trial is free, it requires no commitment, and it will tell you more in a day than this entire article has. We have a team of engineers ready to help if you get stuck.
If you have decided on a rewrite, install the Avalonia templates from NuGet, work through one of the tutorials, and have a single experienced developer build a small but representative slice of your application. Two weeks of focused work will tell you almost everything you need to know about whether Avalonia is the right rewrite target for your codebase.
If you want to talk it through, I am reachable. The conversations I enjoy most are with teams who are honest about the constraints they are working under, because those are the conversations where we can be honest in return about whether what we build is the right answer. Sometimes it is not, and I'll always be up front about it when that's the case.
WPF modernization is the most consequential client-side decision a .NET shop will make this decade. Ask the right questions in the right order, and pick the option that gives you the best chance of still liking the decision in ten years. For most teams, the options are Avalonia or XPF.
The Avalonia documentation is at docs.avaloniaui.net, the XPF product page is at avaloniaui.net/xpf, and you can reach the team through the contact form on the site or in our community spaces on Telegram, Discord and GitHub Discussions. We're reasonably easy to find.