During the Microsoft Build 2019 conference, many people asked about the future of UWP because there were very few sessions dedicated to it. It may look like nothing new is happening, but the opposite is true. Microsoft is changing the architecture of the whole stack. The visual layer is being decoupled from the operating system, and the ahead-of-time compiler with .NET implementation is being merged with .NET Core. Things are moving forward.
.NET 5
The biggest announcement of the conference was the introduction of .NET 5. It is Microsoft’s silver bullet for software development and therefore also the future of UWP. These are the words of Scott Hunter, Director of Program Management for .NET, from the .NET Today and Tomorrow interview:
We announced that UWP is on the roadmap for .NET Core 3. I mean that we would have the ability to run UWP app on the top of .NET Core 3 stack. Today, the UWP runtime is called .NET Native – AOT compiled runtime that we have for Windows Store applications. In the .NET Core 3 wave you would not have AOT compiler. You would run on the same framework we have. What we do is to take a .NET Core 3, make a package, put it in Store and the Store application is dependent on that package and run. As you get the .NET 5 wave we will then have an AOT compiler which would be the mimic of .NET Native for those applications. What it means is in the 3 wave you would have the ability of UWP application to take advantages of all features in .NET Standard 2.1 and run on .NET Core 3.
As you build UWP application today you develop locally against Core CLR and then you publish it publish .NET Native. Those are two different runtimes which means sometimes your local development experience is “it works great” and when you publish to the Store it does not work. So, I think another benefit of UWP on .NET Core is you will have the same development story as your production story. Which means it will make development easier.
UWP developers will no longer be an isolated island with their own .NET Framework profile. Human resources needed to keep UWP up-to-date with the latest .NET Standard could be moved to UWP XAML. AOT compilation will be the responsibility of .NET 5. Anders Hejlsberg, author of Turbo Pascal, Delphi, C#, and TypeScript, said in the 'Look Back' on C# interview:
Probably the biggest influence was when we added generics which was from .NET 1.0 to .NET 2.0. That was a big change and had a lot of new opcodes in the runtime and new metadata format and so forth. But then we made (what I think in retrospective was probably a mistake) in sense that .NET runtime is a Windows component and it ships with the Windows operating system and it cannot run side by side with other versions of .NET. And that in a sense put handcuffs on evolving anything in the runtime. And there was a number of years we really band over backwards to do everything in the compiler instead in the runtime. But now with .NET Core we finally got where I think we should be in the first place, which is runtime can install in directory, run side by side, you can delete it and its gone, it is like it never was on your machine. At that point you can have different capabilities in the runtime and we start to look at things we could not have done before.
All the good things of .NET Core will also be available for UWP apps. And there are a lot of things like gRPC or Java interoperability.
WinUI
Lindsay Kubasik, Senior Program Manager working on the Windows UI platform, noted the future of UWP during the Windows UI platform roadmap interview:
We are doing a lot of work to decouple the presentation platform from the core operating system which gives you the opportunity to have access to all of the new UI features we are building on downlevel versions of Windows.
Joe Stegman, Group Program Manager for UWP XAML, confirmed this strategy with some additional technical details:
On the top of DirectX, we have a visual composition layer and XAML on top of that. DirectX stays on the platform, but effectively we are decoupling the composition layer (the visual layer if you will and animation layer and some of our input layer and everything above that including the all XAML stack and the XAML framework) and making all of that available on previous versions of Windows 10. So effectively you just need a baseline application running on RS 2 and then you can use the stack on any Windows 10 machine greater than that.
This basically means that UWP apps will be as easily portable as games. They will rely only on a specific version of DirectX and Windows Runtime. As we already know, DirectX and Windows Runtime are maintained as backward compatible. Today, the biggest headache of UWP apps is the backward compatibility overhead in the user interface because user controls are embedded in the operating system. Embedded controls in the app is the approach which games already established decades ago and how it, in my opinion, should have been done in the first place.
The Windows UI Library contains controls that are decoupled from the platform. They are shipped outside Windows as NuGet packages. The upcoming version will contain Tabs control (which is used in the new Windows Terminal), input validation, or Teaching tips.
Long-term project
The truth is that UWP apps lost a lot of their relevance when Microsoft decided to stop manufacturing phones and no one else ships Windows 10 as a mobile operating system. However, when we consider why that happened, we must admit that the software infrastructure was not ready for mobiles with touch displays. Silverlight on top of Windows CE, then Windows Runtime XAML Framework, and finally UWP, not to mention Portable Class Libraries and Shared Projects, deploying apps via the Zune app and later directly from Visual Studio with a combination of all dependencies to different operating system versions, the existence of Windows Phone Marketplace side by side with Windows Store, and the fact that the first wave of devices was stuck on Windows Phone 7.8 and the second on Windows Phone 8.1 – all of that together caused one huge pain and an even bigger failure.
The fast progress made Microsoft managers happy with agile development rather than making developers happy with a rock-solid foundation for their apps, even at the cost of a delay. Microsoft has learned and is preparing itself for the future. The Windows 10 operating system and Microsoft Store are now better prepared for upcoming devices (whatever they may be) than ever before.