Ok, I know this post is probably going to annoy all those UWP loyalist out there that can’t unpackage their love for the platform and realise that Windows development is in the process of moving on. One of probably the biggest marketing nightmares that Microsoft has unleashed is UWP. To different people, UWP means different things such as the syntax of UI/XAML, the way apps are packaged, the runtime, the app model etc. In this post I’ll talk about why this needs to end and why we should agree on a definition for UWP and then park it and just let it be.
There’s a lot of debate on what UWP means but we’re going to assign it a very simple definition. For your average developer, if you were to ask them to build a UWP app today they would open Visual Studio and create a new project based on the “Blank App (Universal Windows)” template. I feel this is a good place to start the definition of what we mean by UWP. Of course, this encompasses things like .NET Native, APPX/MSIX packaging, App model/lifecycle but the point is that it’s a very tangible thing.
If we use this definition of UWP (i.e. an app produced from the uwp project type in visual studio) then we can start to talk about the future of UWP. It’s a pretty short discussion actually – the best option for UWP is that it is parked in its current form. Developers targeting UWP today should be continued to be supported and should be able to leverage the benefits of WinUI2.x. However, there won’t be any significant changes coming to this project type. It’ll continue on .NET Native (which is now in maintenance) and will continue to support deploying to Xbox, Hololens etc.
But does this mean that UWP developers are being hung out to dry? The answer is no, as there will be a migration path to the Windows platform of the future (aka Project Reunion / WinUI3). The migration path isn’t simply adding or updating a NuGet package. It’ll involve changing namespaces, changing third party NuGet references, commenting out features that either don’t work or aren’t yet support. The end goal is that existing UWP projects will come across to be a WinUI desktop project, with features like app container, app model and packaging enabled.
Unfortunately the migration path I’ve just described doesn’t work and isn’t possible. Using the current Project Reunion / WinUI3 bits you can’t easily take your UWP app and have it run using the WinUI desktop project type without dropping features that aren’t yet supported.
So, what does this mean for UWP developers of today? Well there are two options:
- Migrate to WinUI desktop and accept that certain features aren’t supported yet
- Stay on UWP until all the features you require are supported by the new Windows project type.
In summary, the marketing term, UWP, needs to be sidelined. The future is that Windows developers will be able to use WinForms, WPF and WinUI3, coupled with Project Reunion (call this the new Windows SDK if you will) to build apps for the Windows platform (and other platforms, leveraging Uno Platform)
There is a third option, if one needs to rewrite code from scratch anyway, port to another cross platform stack that it take us away from the mess started with Windows 8.
Not my favourite option, but certainly something that many companies fed up with Microsoft way of handling all the rewrites since Windows 8 (5x times by now) will be looking into.
I know, right! Much as I think Flutter is great, the Microsoft stack is quite compelling from a corporate perspective. I’m hoping that with Reunion (aka the new Windows app framework/tech) + Uno will be a compelling offering in the near future.