Can WPF applications run on macOS or Linux?

No. WPF is built on top of Win32 and DirectX, which are Windows-exclusive. It has no native support for macOS or Linux. Avalonia XPF provides a compatibility layer that allows WPF-based applications to run on those platforms by reimplementing the WPF rendering pipeline on top of Avalonia.

Do we need to rewrite the entire application?

XAML reuse typically ranges from 70–90% depending on the complexity of controls, custom templates, and attached behaviors used. ViewModels and business logic in pure .NET are generally fully reusable. Code tied to Windows APIs, system dialogs, or OS-level integrations must be abstracted or replaced.

What are the main risks in a WPF to XPF migration?

The primary risks are: (1) undiscovered Win32 and COM dependencies that break at runtime on non-Windows targets, (2) third-party controls with no Avalonia-compatible equivalent, (3) custom rendering or DirectX usage that cannot be ported directly, and (4) runtime behavior differences between WPF and Avalonia XPF in edge cases. Early dependency analysis reduces most of these risks.

When is a full rewrite a better option?

A full rewrite becomes more practical when the codebase has significant Win32 coupling throughout, relies heavily on unsupported third-party controls, uses custom DirectX rendering, or when the team wants to modernize the architecture in addition to changing the platform. For large, stable WPF codebases with MVVM patterns and limited Windows-API dependencies, XPF migration is almost always the faster path.

WPF TO AVALONIA XPF

Add macOS and Linux support to your existing WPF application

Extend your existing WPF application using Avalonia XPF. Reuse your UI layer and most of your .NET logic, without rebuilding the system.

Request migration assessment

Book a call

Learn more about Avalonia XPF

CUSTOMER STORIES

Trusted by teams building cross-platform experiences

Real teams. Real results. Built with Avalonia.

"UXDivers quickly understood our requirements and delivered results that drove confident decision-making"

Priyanka Patil

Engineering Leader, Bridgestone

"We needed macOS support, but rewriting our existing WPF application was not an option. UXDivers helped us extend the application to support macOS using Avalonia XPF, while preserving most of our existing investment."

Andreas Schmidbauer

Managing Director, EDISOFT

"No one outside the Avalonia team handles these migrations better than UXDivers"

Mike James

CEO, Avalonia

Learn more about our approach

Good fit

Ideal for most business applications

Proven patters, cross-platform ready, and easy to maintain.

Mature WPF codebase

MVVM or MVVM-like architecture

Limited Win32 / PInvoke usage

Clear need for macOS or Linux support

Stable UI patterns

Book a call

Requires assessment

Complexities that may requiere extra effort

These factors can add complexity or impact timelines.

Heavy third-party controls (DevExpress, Telerik, Syncfusion)

DirectX or custom rendering

COM / ActiveX integrations

Tight Windows API coupling

OS-level dependencies

Request assessment

Migration paths

Choosing a migration path

Choosing a migration path is not a framework decision. It is a trade-off between rewrite cost, platform reach, and engineering risk.

Full Rewrite

Rebuild everything

Stay on WPF

Maintain and extend

XPF Migration

Incremental modernization

Estimated timeline

12–24 months

N/A

3–6 months

XAML reuse

0–10%

100%

70–90%

ViewModel reuse

Low

Full

High

Third-party controls

Replace

No change

Partial compatibility

Windows-specific APIs

Rewrite

No change

Must be isolated

Target runtimes

Cross-platform

Windows only

Windows, macOS, Linux

Regression risk

High

None

No risk

Development constraints

High

None

Acceptable

Initial cost

High

Low

Acceptable

Long-term flexibility

High

Low

Very good

Key differentiation

Why teams don't handle this migration in-house

WPF to XPF migrations are not difficult because of XAML. They are difficult because of everything around it.

We identify risks early

Most teams underestimate Windows-specific dependencies, control limitations, and rendering constraints. We focus on identifying these early.

We avoid unnecessary rewrites

We maximize reuse of existing XAML and ViewModels, and isolate only what needs to change.