Reunited and it Feels So Good (Premium)

After years of silence and misinformation, Microsoft finally made it official: It is “unifying access” to Win32 and UWP APIs and decoupling each from specific Windows versions.

The UWP era is over.

To be fair, Microsoft has been working towards this goal for years, first by broadening the types of apps that developers could provide through the Microsoft Store and later by finally decoupling UWP user interface APIs from specific Windows 10 versions and making them more broadly available to the developers that never adopted UWP. But even while doing so, the bigger problem is that the firm has been silent or even dishonest about its plans, sowing confusion.

Today, however, Microsoft finally offering some clarity and admitting to what it communicated privately to journalists last year: UWP is not the way forward, and neither is the Microsoft Store. Instead, APIs that used to be tied to UWP will be decoupled from that framework and from specific Windows 10 versions and made available to the majority of developers who never could, or never wanted to, use UWP.

This decoupling is starting with what used to be the UWP UI/UX stack and is now called WinUI. In fact, that’s one of the more interesting side-notes to this story: Aside from the name of this effort, which Microsoft calls Project Reunion, there isn’t really a lot of new news here. We’ve known about these changes since Build 2019. It’s just that so many people, inexplicably, have refused to believe it was happening. I hope it’s clear now.

And with that clarity in mind, let me reiterate the primary benefits of this change.

UWP, as I’m sure many understand, is deeply flawed. It was created as a way for Microsoft-focused developers to write apps that would run across multiple platforms, which explains the “universal” part of its name. But UWP was never truly universal: Those apps targeted only Microsoft platforms, which once included Windows 8.x/10, Windows Phone/Mobile, Xbox One, Surface Hub, HoloLens, and Windows 10 IoT.

The devices that run on these platforms are incredibly different from each other in many cases, and the UWP platform itself was compromised by this fact. It is a mobile platform, so it shares the battery- and memory-saving features we see on platforms like Android and iOS, and as originally designed was inadequate for creating powerful desktop productivity apps. This problem because exacerbated when Windows Phone failed; suddenly, Microsoft had a mobile software platform but no true mobile hardware platform on which to run those apps.

That UWP apps were unsophisticated is an understatement. They had to be written to support a least-common-denominator, which was Phone for apps with user interfaces. And while those apps might have looked fine on handsets, they looked childish and unprofessional on the desktop.

So while Microsoft’s original UWP version—“One Windows”—never made sense, in my opinion, I think most people would agree that it certainly makes no sense now. Microsoft did move to improve UWP for certain scenarios, adding for example some basic desktop features so that developers targeting Windows 10 for desktop could at least create more sophisticated looking apps than the toys we saw during Windows 8.x. (We’re all suffering from PTSD after using these terrible apps with their huge round buttons placed near the bottom corners of the screen.)

But UWP has other problems, and they’re just as serious. Each improvement to UWP was tied to a particular Windows 10 version, so developers who used new features couldn’t sell or deploy them to users on older Windows 10 versions, fragmenting the user base. This was the same problem Microsoft faced with legacy Edge, where the browser was only distributed with Windows 10; if you wanted a newer version of Edge, you need to upgrade Windows 10.

With Project Reunion, Microsoft is fixing the mistakes of the past, and belatedly—like almost a decade belatedly—doing what it did with Windows Vista and the new APIs that that system introduced: It is decoupling its modern APIs, in this case, from UWP and from specific versions of Windows 10.

As you may recall, when Microsoft announced Longhorn in 2003, the original plan was that the new frameworks and APIs—then called WinFX, Avalon, Indigo, and WinFS—would only be made available on that versions of Windows. But when developers rebelled, Microsoft made them available to all existing and supported Windows versions, not just the new one. (Longhorn became Vista, WinFX became the .NET Framework 3.0, Avalon became Windows Presentation Foundation, Indigo became Windows Communication Foundation, and WinFS kept its name but was eventually canned.)

With Windows 8.x/10 and UWP, however, Microsoft followed through on the mistake it tried to make with Longhorn. We’ve all heard the axiom about learning from one’s mistakes, but this kind of thing has to be a lot rarer: With UWP, Microsoft ignored the good decisions of the past and made the same mistake it had tried to make several years earlier.

At least they’re finally reversing that mistake.

WinUI 3.0 is now available in preview, is due in final form in late 2020, and is what Microsoft calls “one of the first components” of the Project Reunion vision. WinUI 3.0 will “unify” access to APIs that were previously locked to both UWP and specific Windows 10 versions and make them available to everyone via Win32 and Win32 frameworks like Windows Forms and WPF, plus React Native. They will be completely decoupled, again, not just UWP, but from specific Windows 10 versions. That means they will work on any supported Windows version, including Windows 8.1.

There is a second Project Reunion component: With Microsoft Edge now decoupled from specific Windows 10 versions and made available across all supported Windows versions plus Windows 7 and macOS, Microsoft is likewise decoupling its latest web application platform, WebView2, and supporting it in WinUI 3.0 apps based on .NET (Windows Forms/WPF) and UWP technologies.

I’m curious what other Project Reunion components we can expect in the future. But based on my recent experiences developing .NETpad in Windows Forms, WPF, and UWP, I can say that I’m excited to be able to create the .NETpad of my dreams, which is the WPF version of the app running on .NET Core 5 and with a WinUI 3.0 (formally UWP) user experience. I suspect many app developers will update their existing codebases to be more modern and that this flexible new approach will be appealing in ways that starting over from scratch with the limited UWP platform never was.

Ding, dong UWP is dead, the wicked UWP is dead. And we can now move forward.