There are a bunch of loyal UWP developers that are complaining because Project Reunion / WinUI isn’t available for UWP but have they really taken a step back and understood what they’re asking for. Let’s break this down a little and understand why WinUI for UWP shouldn’t exist (and why there are political reasons why it currently does exist).
Firstly, let’s set the stage by giving an update on what Microsoft has committed to, since this seems to be quite difficult to lock down, despite there being multiple roadmaps (Project Reunion / WinUI). In a recent series of responses to a GitHub issue talking about WinUI and UWP, Andrew Leader commented that Microsoft has “no plans for .NET 5 to come to UWP“. Andrew goes on to reaffirm this stating that there are “currently have no plans to make happen” in the context of .NET 5 support for UWP.
Where does this leave WinUI support for UWP. Well, according to Andrew, support for “UWP will be added back to the upcoming (non-production) 0.8 Preview VSIX“. This would indicate that UWP support is still being worked on and that it has a future. Again, this is supported by the WinUI roadmap that lists WinUI 3 in UWP apps in the Planned for a future update column.
Unfortunately this is the current situation – as a UWP developer, I have no idea whether WinUI3 for UWP is going to ship, ever. I only know that it was available, and then it wasn’t, and then it will be added back but it’s going to ship with the 0.8 release. In other words, I’m completely confused.
Let’s move on to discuss why WinUI for UWP should not exist. Before a bunch of you get all hot under the collar and start ranting at me about how Microsoft has invested so much into UWP, so of course WinUI for UWP should exist, consider this: UWP as it is today is a collection of a large number of features that were conveniently grouped together to make it easier (in theory) for developers to build apps for the Windows platform. One of the goals for Project Reunion is to make all of these features available to any Windows developer, regardless of whether they’re a WinForms or WPF developer. As such, all that investment that Microsoft put into building UWP will get carried forward and applied to a Windows app of the future (i.e. an application that references Project Reunion).
At this point you might be asking, well if Project Reunion is trying to make all these great features available to any developer, why, as a UWP developer, can I not take advantage of them? Why do I need to migrate to a Win32 based application?
In trying to answer these questions, consider this – the reality is that there is currently zero compatibility between WinUI for UWP and a standard UWP app. By this I mean that once you’ve migrated your application from vanilla UWP to WinUI for UWP (i.e. updating namespaces etc), you’re not really in a UWP application any more (at least from a UI perspective). None of your third party controls will work (unless they’ve shipped a WinUI for UWP version) and you still won’t be able to move forward from .NET Standard 2.0 (i.e no .NET 5 for you).
I can’t reiterate this point enough – your third party control libraries will not work, without the vendor generating a WinUI for UWP version of their controls. This is in addition to the WinForms, WPF, UWP, WinUI for Desktop, Xamarin, Maui etc versions of the controls they need to build, and that’s just to keep Windows developers happy. Is it any surprise that there are such a small number of control vendors left in the market? Microsoft is entirely responsible for repetitively damaging and fragmenting the Windows developer ecosystem in this way.
Hopefully at this point the penny should be dropping and you realise that WinUI for UWP isn’t going to be what you’re looking for. But hold on, if these arguments hold, why is Microsoft bringing WinUI for UWP back?
This is where it would seem internal politics seem to be kicking in (or at least, from my external viewpoint, with no knowledge of the inter-team discussions that goes on). Currently, there is no way to run a Project Reunion / WinUI for Desktop application on Xbox, Hololens or Windows 10X. I’m pretty certain that the Xbox and Hololens teams aren’t that concerned – the developer ecosystem for these platforms is relatively small and very niche.
However, Windows 10X is set to be the next big thing coming from Microsoft and nothing would damage a good product launch than a bunch of tech news ripping into the platform saying that the only way to build apps for it is using technology that’s years out of date. It would seem that by including WinUI3 for UWP, Microsoft is holding out a carrot to all those existing UWP developers, encouraging them to upgrade their applications with the false promise that everything is going to be great moving forward. The harsh reality is that this is just a not-so-clever marketing ploy to pacify UWP developers so that they don’t rock the boat.
Where does this all leave us? Well, if Microsoft continues down this path of shipping WinUI for UWP they’re going to again fragment the Windows developer market, contrary to the goal of Project Reunion. Fewer control vendors will ship controls for Windows and the ecosystem will again implode. The simple solution is to drop the façade and acknowledge that we all need to move on from UWP.
In closing, assuming Microsoft doesn’t ship WinUI3 for UWP, where does this leave Windows 10X? Well, for a start, I’m sure that Windows 10X will do just fine since it’s target market is to be the Chromebook killer (aka a glorified web browser). A perfectly valid model for targeting Windows 10X would be via a web application that can be installed as a PWA.
Long term, the challenge that Microsoft needs to address is how to get Project Reunion applications to run on Windows 10X. There needs to be some strategic effort put in to enable Win32 apps (perhaps a subset of them) to run on Windows 10X with the same security context that’s currently applied to UWP applications.