In light of articles talking about the supposed death of UWP and related discussions I recently saw on Twitter, I wanted to pause and think about what it means for Windows and .NET to be in a post-PC era.

The Future of .NET

.NET Core 3 and .NET 5

Microsoft has recently announced the releases timeline for upcoming versions of .NET, which will now be released once a year, around November.

dotnet releases timeline

They’re more notably unifying the .NET platform under a single name (brand), a single SDK, targetting all platforms. No more .NET 4.* & .NET Core for Windows, and .NET Core only for macOS and Linux systems. No need to explain what’s the difference between all those plus their contracts with .NET Standard.

.NET 5 will notably embrace all platforms, taking into account their very own specifics like iOS requesting all code to be compiled ahead of time (AOT) unlike say Windows, which obviously allows just-in-time code compilation (JIT). On a side note, I’m incredibly excited by this global effort as it will yield great benefits for the .NET ecosystem including Unity3D (WebXR apps using Unity!), Blazor (web frontend using .NET!), Uno (cross-platform apps including the Web!), etc.

Windows is the exception in this picture

In Richard Lander’s announcement, the third sentence says:

[…] you will be able to use it to target Windows, Linux, macOS, iOS, Android, tvOS, watchOS and WebAssembly and more.

What a difference a few years (and probably one of the most radical company values evolution in recent history) make.

The statement is clear and leaves us with no doubt: Windows, once the only target for .NET developers, is now just one of the plethora of compatible platforms. Windows is in no way considered as a third-class citizen in the .NET eco-system, not at all. With WPF+Windows Forms support in .NET Core 3 for Windows and UWP using .NET Core 3, one could argue the countrary is happening.

However, I can’t help but wonder what it means for .NET to be able to target so many platforms. It opens a world of possibilities for the .NET ecosystem and at the same time, it feels like it might benefit more those new targettable platforms and the .NET ecosystem itself than Windows. It took me a while to realize .NET would be pretty much a (very, very) slowly dying ecosystem if they didn’t open-sourced it and ported it to as many platforms as they could. In a world where .NET would have stayed Windows-only, it would have been ultimately put in maintenance mode to satisfy the many businesses which still need and want to target Windows and Windows Server.

Instead, .NET is now becoming a first-class citizen of both sides of the Computing Edge. It runs in Docker containers, on a Raspberry Pi, on your Android phone and even on your Apple Watch. It has a much brighter future. This opening of .NET happens while Windows 10 is suffering (just like Windows Phone and Windows 8) from the lack of UWP / Modern Apps, preventing it from staying relevant in the consumer world.

The slow yet expected death of UWP

In fact, Microsoft is struggling to clearly define what UWP truly means in practice, raising debates on social media; Kevin Gallo more or less implicitly acknowledged developer adoption for UWP is disappointing. A few days ago, Microsoft announced they now allow game developers to publish Win32 games to the Windows Store, meaning they don’t even have to rebuild them as UWP (which theoretically in many cases is not a huge deal if you use Unity3D or a recent version of Unreal Engine). On top of that, the Edge web browser is being rebuilt as a heavily-modified version of Chromium instead of being a UWP app (with Joe Belfiore stating “UWP is not a 35-year-old mature platform that a ridiculously huge amount of apps have been written to”).

The whole UWP strategy therefore seems to be a failure. Let’s try to analyse what happened and went wrong.

Software editors don’t want to rewrite existing apps

Developing software has a cost but even more so maintaining it. If an app already runs fine on Windows 10, there’s a good chance requiring devs to rewrite part of the app’s codebase for UWP compatibility won’t be a popular idea and will be rejected. We could have a great Spotify experience on Windows by leveraging unique features of UWP (that would be awesome!), but there’s no real need, considering there’s already an app that’s kinda works, even if it is slow to start and animations are laggy on a powerful PC. I took Spotify as an example but you could make the same point with many of the apps people use like Slack, Notion, Microsoft Word (it seems Microsoft is dropping the UWP version), plus of course internal corporate software and apps.

There are actually quite a few reasons a port to UWP would be a great idea, such as getting first-class support for devices with touch input, but the small market and low usage of such input in Windows (also due to the terrible touch input experience on Windows 10 compared to Windows 8) sort of defeats the purpose.

Lack of backward compatibility

a reminder Windows 10 didn’t reach the initially expected KPIs

An entirely different app model

It forced developers to rebuild a lot of logic, deal with many APIs being forbidden, and a sandbox-based app model

The benefit of UWP is just too shy compared to the added complexity

At Minsar we make an app that’s compatible with most AR/VR platforms. Developing for HoloLens is an extremely frustrating experience (similar to iOS) as it runs on UWP. This means to properly and thoroughly test your code you need to export a Visual Studio solution from Unity3D which in turn will let you build an appx file you can deploy and debug on-device. It is time-consuming and while it is possible to try to debug most of the code from within the Unity Editor, you will need at some point to code and test some platform-specifics feature on the device. Developing for the Magic Leap One is comparatively a delightful experience. It runs standard, vanilla .NET Standard 2, so it is possible to test and debug their platform-specific APIs right from the Unity Editor, with the app running live on the headset thanks to their Zero Iteration tool.

Developing Spatial Computing apps in C#/.NET is a better experience when targetting LuminOS compared to Windows Mixed Reality. Let that sink in!

.NET Core was approximately born at the same moment the Windows team tried to advertize UWP as the go-to-platform for their operating system, but this strategy alienated Windows from the other platforms and therefore placing it into a weak spot. At a time where Windows relevancy in the consumer world was questioned, all we had was yet another application model and set of constraints to support.

Redefining a new Universal Platform

With .NET Core and then .NET 5 this will only be mistakes from the past and we will finally have one .NET to target all platforms. If it sounds familiar, it’s because that was the whole point of the UWP strategy; the main fault being thinking Universal and Windows could be in the same name whereas running on Windows didn’t mean being universal at all.

If they convince iOS, Android, Web, Unity3D developers

Getting apps back on Windows

The narrative has somewhat shifted to Progressive Web Apps (which is a pretty nice tech and could work for many apps at the cost of losing access to some platform-specific features), but we have yet to see this strategy succeed.

“Values, mindset, of the Windows PC world versus the rest of the world, basically”.

Spatial Computing apps as a trojan horse

I don’t believe being able to write once and deploy everywhere with .NET 5 will massively appeal developers more than what happens with Xamarin. It won’t be a raz de maree.

However there’s a special kind of apps that mostly runs on C# .NET even on Android and iOS, and it is video-games. Apple and Android mostly rely on Unity (and Unreal Engine), which means they all rely on .NET and C#.

Closing