Reassessing Project Reunion (Premium)

Like some real developers, I’ve gone through what I call the three stages of irrational exuberance with Project Reunion only to land back in reality.

Frankly, I miss the fantasy.

As you may recall, Microsoft announced Project Reunion during its Build 2020 virtual conference in late May. At the time, it was described as a way to unify the Windows 10 application development experience, but my take at the time was that it is a modern replacement for UWP and a way to use APIs that were locked into UWP in other developer frameworks.

That view is correct, actually. But it only hints at the full strategy and, more to the point, the full scope of what Reunion really is, and what role it plays in the broader strategy.

But I spoke of the three stages. They are:

1. Ding, dong, the witch is dead. My initial impression was that Microsoft was finally (if only implicitly) admitting that UWP failed and was finally (if belatedly) moving past UWP. I felt this one personally because I accurately reported what a key decision-maker in this part of Microsoft said at the previous Build (2019)—that they had “killed” UWP—and was roasted repeatedly for this accuracy.
2. No, there is another. Project Reunion only addresses Windows 10 app development. As I’ve noted elsewhere, the notion that any developer would start a Windows-only app here in 2020 is, of course, ludicrous. No, what developers need today is some cross-platform solution. My opinion is that that platform, ultimately, will be the web. But Microsoft has its own cross-platform framework coming. It’s called .NET MAUI, but it won’t arrive until November 2021 in 1.0 form. And that might be too late, because, well, Flutter exists.
3. Reality bites. Put simply, Project Reunion is not the way forward, just like UWP was never the way forward. What it really is, for the most part, is a way to bring modern features, starting the previously-locked UWP user experiences, to existing apps. This is the primary role that Project Reunion will play. At least in the short term.

Some of my cartwheeling there was self-inflicted; Microsoft released so much information at Build 2020 that it was hard to absorb it all, let alone understand it. I didn’t fully understand what was happening with .NET MAUI, for example, until days later. And the evolution of my understanding of what Project Reunion really is was informed by me actually using it and creating both WinUI Desktop and WinUI application projects in the preview version of Visual Studio.

But even that creeping understanding was undercut by the fact that Microsoft never adequately or fully explained Project Reunion. And as is so often the case when it comes to developer topics, I have my friend Rafael to thank for clarifying this for me, and for the world.

“Project Reunion isn’t a new application model or platform from Windows,” he tweeted last week, addressing the many misconceptions about this strategy. Project Reunion isn’t a new packaging or isolation model. Project Reunion isn’t a new security or privacy model. Project Reunion isn’t a way to run your app in the cloud. [Instead,] Project Reunion is a set of libraries, frameworks, components, and tools that you can use in your apps to access powerful Windows platform functionality from all kinds of apps on many versions of Windows.”

This is accurate.

And this is also in keeping with the conversations we’ve had here on Thurrott.com about the future of app development on Windows. Many, myself included, have at one time or another figured that Microsoft would “replace” UWP with some next-generation framework, just like UWP (sort-of) replaced WPF and WPF, previously, replaced WinForms.

But over time. I’ve come to understand that there is no one path forward. That there is no one thing coming to save all developers from the fragmented hell of Windows app development today. That Microsoft will instead do for developers what it does for all of its customers today. It will meet them where they are. It will, in short, continue supporting a wide array of ways for developers to write applications that run on Windows.

This why I noted above that my initial view of Project Reunion—that it is a modern replacement for UWP and a way to use APIs that were locked into UWP in other developer frameworks—was essentially correct. It is the next step forward for those audiences (Win32 developers, including WinForms and WPF, and UWP developers). But since no one was creating new Windows-only apps anyway, my stage 3 realization is also correct: Project Reunion is not the way forward, just like UWP was never the way forward, at least the bits we have right now. WinUI is for existing apps. A way to modernize them.

But there’s more

See, Microsoft didn’t fully explain Project Reunion. So, as Rafael also pointed out on Twitter, Microsoft has finally published a more complete explanation of Project Reunion, on GitHub. It’s basically what I wrote above, albeit in more detail. But the interesting thing, to me, is how they flesh out the components of Project Reunion and give us a more complete view of the strategy.

We knew that WinUI was coming to XAML across Win32 and UWP apps, and you can test that now if you want. We knew that MSIX-Core was the new packaging model, and if you do create a WinUI app now, you’ll see that there are two projects in the solution, one for the app and one for the MSIX package you’ll use the deploy the application, to the Store, via the web, or otherwise. And we implicitly understood that there would be what Microsoft calls “projections” across both C# and C++; this document adds Rust as a supported language to that list.

But there’s more coming too. Most of it reads as vague and not super-interesting…

The Chromium Edge-based WebView2 is coming this year, adding HTML+JS support for WinUI.

Microsoft promises something called “Modern Lifecycle helpers” that will help apps be more sensitive to power management and user state. This includes the ability to automatically restart the app after a PC reboot and reduce update-related reboots.

A new set of Startup Tasks will likewise auto-start your app (or, as Microsoft comically puts it, “make your app come alive”) when the user signs-in and reduce the app’s impact on startup time and performance.

Update Scan Integration will help keep apps up-to-date automatically during system maintenance tasks.

AppContainer-based apps will be supported, providing access to Win32 features like the clipboard, inter-process communications, and the Windows shell namespace.

And Modern Resource Tooling will bring ResX/ResW support to Win32 applications.

As for how this stuff will be delivered, even Microsoft’s not sure yet.

“Some functionality will be delivered first as Project Reunion components,” it explains. “As we think about evolving the platform[,] it’s important to make sure new functionality and features are available to our developer community just as soon as they’re ready to go. Where there’s newer in-platform functionality to use Project Reunion will help you adopt that as soon as it’s widely available, without you having to retarget or rewrite – the same Project Reunion API surface will continue to work.”

What this all means, really, is that Project Reunion is an evolution of the various ways in which developers already create apps that only run on Windows. It’s possible with MAUI that this will shift to include some cross-platform capabilities, too, but that’s 18 months and is sort of beside the point since MAUI right now is literally unrelated to Project Reunion as I write this. They’re two different things.

Put even more simply, Project Reunion is a lot less interesting to me than was originally the case. I will still take a look at porting the WinForms or WPF version of .NETpad to use WinUI 3 when possible. But this isn’t the future. And that’s why I’m examining Xamarin.Forms, Flutter, and web developer (probably to settle on React/React Native) now.

Project Reunion is not the future, it’s a way to modernize the past. The web, most likely, or some truly cross-platform framework, probably Flutter, is the future.