Welcome Back, WPF (Premium)

Build 2024 delivered many surprises, but among the most interesting to me was the unexpected reemergence of the decades-old WPF.

This takes the concept of What’s Old is New Again to all-new heights. That article was triggered by the many strange references to the past that Satya Nadella and others from Microsoft made during last week’s Copilot+ PC launch event ahead of Build. The repeated connections to the past—both good and bad, interestingly—fascinated me.

But WPF is something else entirely. WPF is the Coelacanth of Windows app development, something long thought to be dead, but suddenly rediscovered to be a living, breathing entity.

For those unfamiliar, WPF began life as Avalon, a new presentation system for Windows that Microsoft first introduced to the world at the infamous PDC 2003 for Longhorn. Avalon was a classic .NET app framework that would provide significant advances over its predecessor, Windows Forms. Among those advances was the introduction of an XML-based language called XAML that developers and designers could use to describe user interface, similar to the role of HTML in web apps.

And that is, itself, an interesting story: In the Internet Tidal Wave era of the late 1990s, Microsoft initially planned to adopt web technologies for Windows application development, but a civil war between core members of the company’s leadership led to a change of plans: Instead of embracing the web, Microsoft would leverage its core asset of the day, Windows, and embrace and extend the web. That it is, it would offer familiar but superior web-like technologies to compete with the web. And Avalon was a key pillar of that new strategy.

One of the key advances with Avalon, later renamed to the Windows Presentation Foundation (WPF), is that developers could create object-oriented classes compromised of both XAML and the .NET programming language of their choice (typically C#). That is, instead of defining a class solely with C#, as would normally be the case, WPF divided this task between the presentation—XAML code—and the logic (C#) by default. The compiler would combine each partial class, from XAML and C#, into a fully implemented single final class.

The XAML part of this equation is called declarative programming, and its use in WPF heavily influenced future app frameworks. Today, modern frameworks like Swift UI (Apple) and Flutter (Google), use this same technique, though both use more traditional programming languages (Swift and Dart, both of which are analogous to C#) instead of an XML dialect to describe UIs. And here in the Microsoft world, XAML has pushed forward with several renditions, each slightly different, which have been used in developer initiatives like Windows Runtime (WinRT)/Universal Windows Platform (UWP), Xamarin.Forms (third-party), MAUI, and others.

WPF launched alongside Windows Vista in late 2006, and while it was well-received outside of Microsoft, it was tainted by the Longhorn/Vista failures and never adopted en masse inside the company. We have Steven Sinofsky to blame for that: As the leader of Office, he refused to adopt WPF for those crucial apps’ user interfaces, and as the leader of Windows post-Vista, he ensured that nothing .NET-related would sully his creations. For Windows 8, his team created the Windows Runtime (WinRT), relegating .NET and WPF to the backwater he felt they deserved.

WinRT morphed into the Universal Windows Platform (UWP), which morphed into the Windows App SDK, and failed to attract meaningful developer attention. (Not helping matters, the Office teams of those days also refused to adopt these technologies, helping to ensure their failures.) But WPF somehow endured. It was always popular with third-party developers, and still is, especially those inside the corporations Microsoft can’t ignore. And as the years rolled by, and subsequent Windows app platforms came, failed, and went, these codebases just kept working. Unlike their supposed successors, they survived.

So much has changed since the flawed initial plan for .NET and WPF. With the Windows team abandoning .NET in Windows 8, the .NET organization regrouped and embraced open source and a new future as a cross-platform platform, first as .NET Core and then just as the new .NET, replacing the classic, proprietary, and Windows-only original .NET. And older frameworks like Windows Forms (WinForms), which is not .NET-based, and WPF, which is, were given new leases on life, via open sourcing and community support, so that fans and those who relied on these technologies could address lingering issues and add new features.

Heading into the 2020s, Microsoft’s story for developers who want to create Windows apps was as diverse as it was vague. It would support them where they were, an oft-stated phrase these days that means exactly what it sounds like: Instead of creating a single app platform that it expected most developers to adopt, it would instead provide options. Many options. Maybe too many options. And the emphasis shifted from creating new apps only for Windows. Going forward, the focus would be on cross-platform solutions—primarily web apps built with technologies like React Native—for new apps and various solutions for modernizing existing apps.

WPF helps address that latter need. Where the Windows App SDK provides a way forward for classic desktop apps (Win32) and mobile (UWP) apps, WPF is being reinvigorated to do so for apps built with that platform. Modernization means a few different things in this context. There’s the user experience layer, which has evolved dramatically since 2006, and multiple times. And then there’s the underlying system capabilities: Windows as a platform is much more sophisticated than it was two decades ago as well. And while there are contorted ways for WPF app maintainers to add modern features to their apps, this new formal support from Microsoft will make doing so much more straightforward.

I’m still sorting through the announcements Microsoft made at Build 2024 in this space, paying particular attention to the tidbits revealed in various sessions. For those interested in this topic, Microsoft’s new Enhance Windows Client Development collection on Microsoft Learn is a good starting point. And for WPF in particular, two sessions from Build 2024 stand out: Navigating Win32 App Development with WinUI and WPF and How to create superior experiences with WinUI and WPF.

Those session titles provide a few clues about the direction Microsoft is taking here.

Despite being based on .NET, “a thing on a thing,” Microsoft is promoting WPF as native (“Win32”) way to create desktop apps, perhaps in part to differentiate it from the WinRT/UWP mobile app platforms of the past. But WPF isn’t “native,” it’s a managed code app framework that provides all the benefits of such a thing (memory management, for example). In the past, managed code environments like .NET countered those advances with some overhead that, in some cases, might be seen as performance issues. But modern PCs are so powerful that such differences are moot, especially for the types of standard desktop productivity apps one would create with WPF.

It’s also notable that both of those session titles reference WinUI, Microsoft’s current UI framework. WinUI (literally, Windows User Interface) arrived with WinRT and was updated to WinUI 2 with UWP. But the latest version, WinUI 3, is part of the Windows App SDK, and wasn’t (and won’t be) backported to UWP. Because greenfield (new) app development for Windows only is basically dead, Windows App SDK isn’t particularly compelling for new apps. And to date, the only easy way to implement a WinUI 3 user interface has been with MAUI, the cross-platform replacement for Xamarin.Forms. But MAUI is problematic for new apps as well, if you care about desktop platforms: It’s used to create mobile apps that run across iOS and Android (and Windows and Mac) that lack the sophistication of desktop apps.

You should wonder why those sessions refer to this technology as WinUI and not WinUI 3. The presenters of those sessions noted above that it’s just a simplification. But I’ve been told it’s because WinUI as a brand is going away and that the future of Windows user interfaces will be based instead on, wait for it, WPF. That is, in updating this legacy app platform for this modern age, Microsoft is putting all its UX eggs in one basket. And that basket will be WPF, not WinUI. This commingling of WPF and WinUI in the Build 2024 sessions is thus purposeful.

(I’m not sure what to make of that. Having watched these sessions now, I feel like WinUI makes sense as a brand for the user interface, regardless of whether developers use Windows App SDK or WPF on the desktop.)

This makes a bit more sense than may be immediately obvious. WinUI was itself based on WPF, and it uses a similar flavor of XAML with many of the same namespaces and conventions, to define app user interfaces. And so moving back and forth between WPF XAML and WinUI XAML is apparently somewhat straightforward. (I have little experience with WinUI, so I can’t claim to be authoritative on that topic.)

In the pre-WinUI 3 days, Microsoft offered a technology called XAML Islands to bridge the gap between the UX technologies of the past (WinForms, WPF) and WinUI 2, but it was complicated, and I’m not aware of any major success stories in that space. (Or, as Microsoft put it, “behavioral insights and customer interviews raised some signals about how developers were using it.”) So the strategy changed with WinUI 3, with this technology supporting desktop app platforms natively and dropping support for UWP.

The Build 2024 announcements position WPF as an alternative to Windows App SDK for desktop apps. That itself is a major strategy shift with the caveat that, again, no one is creating new desktop apps that only run on Windows anymore. But the language here is still interesting.

“If you are looking to develop native Windows applications using our preferred UI development language, XAML, we recommend using either WinUI 3 or WPF,” Microsoft corporate vice president Pavan Davuluri writes in a post about the Windows Copilot Runtime and other Windows developer topics from Build 2024. “We recommend you first consider WinUI 3, and if that meets your app’s needs, proceed with it for the most modern experience. Otherwise, WPF is an excellent choice. Both WinUI 3 and WPF can take advantage of all Windows has to offer, including the new features and APIs in the Windows App SDK, so you can feel confident in creating a modern application in either technology.”

So there it is: The Windows App SDK is no longer the only place to get the full set of new Windows features, not just WinUI, but also the new AI and Volumetric app capabilities that Microsoft announced last week. (AI got all the attention, but Microsoft is partnering with Meta to “make Windows a first-class experience on Quest devices,” extending Windows apps into 3D space. Microsoft calls these apps “Volumetric apps,” and it will supply a volumetric API at some point.) What’s not clear is how Microsoft will implement Windows App SDK features in WPF. My guess is that all new APIs will be added only to the Windows App SDK, and that WPF-based developers will simply be able to call into that namespace and access them that way.

Also unclear is the schedule for updating/modernizing WPF with new Windows platform features, general Windows App SDK support, Windows Copilot Library API support (for AI), volumetric API support, and whatever else is coming. Microsoft has updated its Windows Dev Center As promised, WPF has been elevated to a new position of prominence on the Developing apps for Windows part of that site, under WinUI (which it notes is part of the Windows App SDK). (Developers now have simple WinUI templates/workloads in Visual Studio, which is interesting, as these are really Windows App SDK projects.)

The WPF documentation on Microsoft Learn hasn’t been updated that I can see, but there is a major new app, called WPF Gallery, that works like the similar WinUI 3 Gallery in that it shows off how to create modern, WinUI-based interfaces in WPF. The release notes for that app explain that it applies to “.NET 9 and onwards,” so there’s the end game from a schedule perspective: .NET 9 ships this coming November, so we can expect pre-release versions of some WPF-based advances between now and then. The announcement for the recently-released .NET 9 Preview 4 didn’t mention WPF.

Some of the coming improvements will arrive as part of the Windows App SDK 1.6, which arrives mid-year(ish), and before .NET 9. This release will add modern title bar capabilities, Windows 11 theme support, new controls like ItemsView, and modern APIs for dialog boxes, notifications, and more. Developers interested in any of these things need to install Visual Studio 2022 17.11 Preview 1 (or newer) and configure it with the appropriate workload(s)—.NET desktop development for WPF and Windows application development for WinUI—plus the Windows App SDK C# Templates in the optional installs list.

This raises an interesting point. I have a WPF project that could be modernized, the WPF version of .NETpad that’s available on GitHub. This project was updated for .NET 6 about two years ago, and is a good candidate for all kinds of updates stemming from .NET 9 and the Windows App SDK. So I’m getting started with that work right now, and have already gotten it updated with the Windows 11 look and feel (as shown up top), which is fun. But there’s so much more that could happen here. So I’ll keep plugging away at it.

More soon.