Project Reunion: An End to Microsoft’s UI Madness?

After years of confusion, Windows development is about to improve… slowly

Matthew MacDonald
May 22 · 7 min read

Sometimes, being a Microsoft developer seems like Mark Twain’s old joke about the weather. You know the one — if you don’t like the API they’ve given you today, wait a week and try the next one.

My favorite example of Microsoft’s constant reinvention is database APIs in the late 1990s, when they unleashed an alphabet soup of different three-letter technologies (RDS, DAO, ADO, OLE DB). But in the decade since, no one has suffered more than business developers trying to write graphical Windows applications.

Two decades of Windows applications

When .NET 1.0 first hit the scene, life was straightforward. If you were a .NET developer who wanted to build a Windows desktop application, you used Windows Forms. It was easy (almost VB-like in its drag-and-drop simplicity), and relatively feature-complete. Yes, you might need to work around the odd limitation and make a call to the Win32 API every once in a while. But if you wanted a straightforward line-of-business application that looked respectable and didn’t need custom chrome, the world was a good place.

Good ol’ MDI in Windows Forms

Then things took a turn. Microsoft knew they could never incrementally improve their way out of the limitations baked into Windows Forms — things like poor support for high-DPI displays, and weak performance with custom rendering. There was no built-in way to do 3D, animation, partial transparency (thanks, Vista), or any of the things that were considered to be cutting-edge UI at the time. So Microsoft launched a massive reinvention project called WPF (Windows Presentation Framework).

WPF changed almost everything, from the way windows were defined (now declaratively, using an XML grammar called XAML) to the hardware underpinnings (DirectX, the same technology that powers high-performance games). WPF’s new features were impressive enough to keep programmers on board, though some of the changes were painful. For example, the first release of WPF had no way to drag-and-drop a basic window into existence — a feature that had existed in the Microsoft world since the first version of Visual Basic.

Custom drawing in WPF

WPF was successful, but not successful enough to replace the dead-easy, run-everywhere Windows Forms toolkit. So both technologies coexisted — one as a mature platform for legacy apps, and the other as the best place for new, future-facing development. And for a while, this seemed like a reasonable compromise.

Everything changed with Microsoft’s 2010 identity crisis. The company decided it needed to go in an entirely different direction, and compete against a new set of competitors. It wanted a safe, painless Microsoft Store for installing apps, like the iPad and iPhone had. It wanted a sandboxed environment, so it could compete with single-page web apps written in JavaScript. It wanted a new operating system with a dozen different editions so it could support low-power mobile devices (like tablets, the Surface RT, and the mostly forgotten Windows Phone). The solution to all this paranoia was yet another Windows development framework, called UWP (Universal Windows Platform), and also known — in its early days — as Metro.

The problem was that UWP was hardly universal. Yes, it ran across different types of Windows 10 devices, unlike WinForms or WPF, but it didn’t support any previous version of Windows. This single fact was enough to discourage established developers from making the jump to UWP. Even if they didn’t need the features of a full desktop application written in something like WPF, they didn’t want to lock themselves into a smaller box of computer compatibility.

UWP failed to replace either of the desktop toolkits that had come before it. Combined with the failure of other parts of Microsoft’s grand vision — the dead Windows Phone, the shriveling Microsoft Store, the faltering mobile operating system Windows RT — the value proposition of UWP kept shrinking. It wasn’t that UWP was a bad technology, just that for all its compromises, it solved very few people’s problems. After all, if you were willing to build a modern, sandboxed application from scratch, why not consider using JavaScript in a browser?

That brings us to the state of Windows development today. All three frameworks for Windows desktop applications still coexist, filling slightly different niches. On top of that, developers are still maintaining C++ applications built on MFC and the Win32 API.

Four Windows UI frameworks, all still in use in 2020

Enter Project Reunion

For a while, it seemed like Microsoft was just waiting out the era of desktop computing, hoping its loyal developers would eventually trade in their windowed applications for a web-based framework like Blazor. But at this year’s Build conference, Microsoft pulled back the curtain on a new strategy to gradually harmonize their different desktop models. That journey starts with something called Project Reunion.

Project Reunion is a move to decouple and share the user interface parts of UWP. In other words, Microsoft is separating the UI toolkit from UWP (called WinUI 3) so that it can be used in other types of applications. Yes, you can still use WinUI to make UWP applications, which still run in their sandboxed environment (even if they don’t need to be deployed through the increasingly-sidelined Windows Store). But — more importantly — you can also use the WinUI toolkit in other types of applications. In fact, you can use it with all the Windows application frameworks Microsoft spent the last two decades creating, from legacy MFC applications to WinForms and WPF.

This is valuable, because WinUI includes controls for building Fluent user interfaces — a web-influenced style of design that helps you create modern, beautiful interfaces. Thin borders, transitional animations, and reflowable layouts are some of the hallmarks of Fluent UI.

The humble Calendar app uses Fluent UI

If you spent the last few years ignoring Fluent UI because it also came with a bunch of extra baggage — like the Windows Store and a sandboxed environment — you no longer have to pay that tax. Now you can build a .NET 5 desktop application with full hardware support that uses the WinUI library.

However, there is a catch. Like UWP, WinUI requires Windows 10. That appears to rule it out for the large swath of developers still supporting fossilized business environments — but maybe not. That’s because Microsoft has plans to extend WinUI compatibility back to Windows 8.1. And it’s not just a pie-in-the-sky hope. Microsoft needs Windows 8.1 compatibility to support the Windows React Native project, which also uses WinUI.

WinUI today

The big questions are obvious. How can you migrate a WPF or WinForms app to WinUI? And should you?

Even though WinUI is compatible with older types of desktop applications, its user interface model is different. There’s compatibility, but not harmony. One path to migration is to refactor as much code as possible out of your UI, and then graft on a new WinUI-built skin. Another option is to go piecemeal. A single application can combine windows that use WinUI with windows that use WinForms or WPF, using a technique called XAML Islands. This gives you a way to tiptoe slowly into the future (but it also guarantees that your application will have a somewhat schizophrenic visual style that jumbles together the old fashion and the new). Either way, Microsoft promises solid IDE support. For example, not only will you be able to easily add WinUI views to a WinForms or WPF project, you’ll also be able to use project templates that mix together the different UI frameworks.

The next question is obvious — is it ready?

Today, WinUI 3 exists in a public preview version. It’s good enough to start playing with, or even planning your next release. But it isn’t ready for production. Planned features, like Xbox and HoloLens support, are still lacking. The final release of WinUI 3 is set in November, at the same time as .NET 5.

The short-term plan for WinUI 3

It remains to be seen whether WinUI 3 is a case of too little too late. After the partial failure of UWP, many desktop developers moved on to making desktop apps with web technologies like Electron. But for those who need to remain in the Windows desktop world, the path to the future looks more promising than it has in years. Sanity has returned to the crowded world of desktop APIs. And the next step forward isn’t another completely new framework, but an attempt to reunite what we already have.

For a once-a-month email with our best tech stories, subscribe to the Young Coder newsletter.

Young Coder


Matthew MacDonald

Written by

Teacher, coder, long-ago Microsoft MVP. Author of heavy books. Join Young Coder for a creative take on science and technology. Queries:

Young Coder

Hack. Code. Think. Stories about science, tech, and programming.

Matthew MacDonald

Written by

Teacher, coder, long-ago Microsoft MVP. Author of heavy books. Join Young Coder for a creative take on science and technology. Queries:

Young Coder

Hack. Code. Think. Stories about science, tech, and programming.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store