What is WPF? A 2026 guide for .NET teamsXAML and .NET

What is WPF? A 2026 guide for .NET teams

What is WPF? A 2026 guide for .NET teams

Two decades after it shipped, WPF still sits underneath an enormous amount of the world's business-critical desktop software. Trading platforms, medical imaging, lab equipment, CAD tooling, point of sale: a surprising share of it is WPF.

So what is WPF, and why does a framework from 2006 still matter in 2026? This guide covers what WPF is, where it came from, what it's good at, where it falls short, and what your options are when "runs on Windows" stops being enough.

What is WPF, exactly?

WPF (Windows Presentation Foundation) is Microsoft's UI framework for building Windows desktop applications on .NET. It shipped in 2006 as part of .NET Framework 3.0, and its big idea was separating the look of an application from its logic. You describe the interface in a declarative markup language called XAML, and you write the behaviour in C# (or another .NET language).

Three things made WPF different from what came before it:

  • Vector-based rendering. WPF draws its own UI using DirectX rather than relying on the operating system's built-in controls. Interfaces scale cleanly across resolutions and DPI settings, which mattered little in 2006 and matters enormously on today's high-density displays.
  • Data binding. WPF's binding engine lets the UI observe your data and update itself when that data changes. This single feature gave rise to the MVVM pattern (Model-View-ViewModel), which remains the dominant way to structure .NET desktop applications.
  • Styling and templating. Every control in WPF can be restyled or completely retemplated. If you want a button shaped like a hexagon with an animated border, WPF will let you build it without subclassing anything.

If you've used WinForms, the contrast is stark. WinForms wraps the classic Win32 controls; WPF replaces them with a rendering engine and a composition model of its own.

A short history of WPF

WPF arrived under the codename Avalon as part of the Longhorn project, and shipped publicly with Windows Vista in 2006. Through the late 2000s it became the default choice for serious Windows line-of-business software, and Visual Studio itself moved its shell to WPF with the 2010 release. That's still true today: the IDE most .NET developers spend their day in is a WPF application.

When Microsoft rebuilt .NET as the cross-platform .NET Core, WPF made the jump too. Since .NET Core 3.0 in 2019, you can run WPF on modern .NET with all the runtime and tooling improvements that brings. The catch, which we'll come to, is that only the framework moved to modern .NET. The Windows dependency stayed.

In the years since, Microsoft has positioned WPF as a supported, maintained platform rather than a frontier of innovation. It receives accessibility work, theming improvements (including Fluent styling work in recent .NET releases) and ongoing servicing. What it doesn't receive is the kind of investment that changes what it fundamentally is.

What WPF is good at

There's a reason so much commercial software still runs on WPF, and it's not inertia alone.

It's deep. WPF's layout system, binding engine, templating and animation stack can express almost any interface you can design. Very few frameworks, on any platform, match its flexibility.

It's stable. A WPF codebase from 2010 still builds and runs. For organisations with software that has to last decades, that stability is worth a great deal. Breaking changes are vanishingly rare.

The ecosystem is mature. Component vendors such as DevExpress, Telerik and Syncfusion have spent nearly twenty years building grids, charts, schedulers and editors for WPF. The answers to most problems already exist on Stack Overflow, and experienced WPF developers are easy to find.

The skills transfer. XAML, MVVM and data binding aren't WPF-only ideas. They carry directly into WinUI, .NET MAUI and Avalonia. Time invested in WPF patterns isn't trapped in WPF.

The catch: WPF is Windows-only

Here's the hard limit, and it's worth being precise about why it exists. WPF isn't Windows-only because of a licensing decision or a missing port. Its rendering pipeline is built on DirectX, its windowing on Win32, and its media stack on Windows components. The Windows dependency runs through the framework's foundations, not its surface. That's why WPF didn't become cross-platform when .NET did: the runtime moved, but the framework's roots stayed planted in Windows.

For years that didn't matter, because the desktop meant Windows. It increasingly does matter. macOS has a serious share of professional users, particularly in design, science and engineering. Linux desktops are growing in government, defence and finance, and several governments have active programmes to reduce their dependency on Microsoft. If your customers start asking for macOS or Linux builds, WPF has no native answer.

Where Microsoft is taking WPF

The honest reading of Microsoft's roadmap is this: WPF is maintained, not advanced. It's open source, it ships with every modern .NET release, and Microsoft has publicly committed to supporting it. Teams with WPF applications aren't being abandoned, and anyone telling you WPF is about to be deprecated is selling something.

But Microsoft's client innovation now goes elsewhere: WinUI 3 for modern Windows UI, .NET MAUI for mobile-first cross-platform work. Neither is a successor to WPF in any practical sense, and the result is a fragmented picture we've unpacked in WinUI vs WPF vs UWP. The summary for WPF teams: your framework is safe, but it's not going anywhere new, and it's never leaving Windows.

The cross-platform question

If you have a WPF application and you need it on macOS or Linux, you have two sensible paths, and which one fits depends on your codebase and your timeline.

Migrate to a cross-platform framework. Avalonia is the natural destination for WPF teams: it's open source, MIT licensed, XAML-based, and runs on Windows, macOS, Linux, iOS, Android and WebAssembly with 70+ built-in controls. Because Avalonia deliberately follows WPF's concepts (XAML, bindings, styles, MVVM), an experienced WPF developer is productive quickly. It's a real porting effort, though, and for a large application it's a project you should scope properly. Our expert guide to porting WPF applications to Avalonia walks through what's involved.

Run the WPF app as-is with Avalonia XPF. Avalonia XPF is a cross-platform WPF compatibility layer. It implements the WPF API surface on top of Avalonia's renderer, so an existing WPF application, including ones built on third-party component libraries like DevExpress and Telerik, can run on macOS, Linux and Embedded Linux without a rewrite. For teams with hundreds of thousands of lines of WPF, this is usually the difference between shipping cross-platform this year and not shipping at all.

There's also a third path worth naming for completeness: rewriting for the web. For some applications that's the right call, and if your software is mostly forms over data with no desktop-specific requirements, a web app may serve you better than any desktop framework. For software that needs local hardware access, offline operation or desktop-class performance, it usually isn't.

For a broader look at how teams are weighing these choices, see WPF modernisation in 2026 and our guide for .NET developers exploring cross-platform UI frameworks.

FAQ

Is WPF still used in 2026?

Yes, heavily. WPF remains one of the most widely deployed frameworks for Windows line-of-business software, and Microsoft ships it with every modern .NET release. New WPF projects are still started every day, particularly where Windows-only is acceptable and a mature ecosystem matters.

Is WPF dead?

No. It's maintained, supported and open source. What it isn't is the focus of Microsoft's client innovation, and it will never run outside Windows natively.

Should I learn WPF in 2026?

If you work in the .NET ecosystem, yes, the concepts are worth learning: XAML, data binding and MVVM transfer directly to WinUI, MAUI and Avalonia. Whether you'd start a brand-new product on WPF is a different question, and depends mostly on whether Windows-only is a constraint you can live with for the product's lifetime.

Can WPF run on macOS or Linux?

Not natively, and it never will, because its rendering and windowing are built on Windows components. Existing WPF applications can run cross-platform through Avalonia XPF, and new cross-platform applications can be built with Avalonia using the same core skills.

What's the difference between WPF and Avalonia?

WPF is Microsoft's Windows-only desktop framework. Avalonia is an independent, open source, MIT-licensed framework that takes WPF's best ideas (XAML, binding, styling, MVVM) and implements them with its own renderer across Windows, macOS, Linux, mobile and the browser.

Where to go from here

If you're maintaining a WPF application and the cross-platform question has started to come up, the cheapest way to answer it is with evidence rather than meetings. Take your actual application, point Avalonia XPF at it under an extended trial, and see how much of it runs on macOS or Linux in the first week. The result, either way, tells you more than any framework comparison can.