The Future of Windows (and Other Platforms) Development

When Windows 10 was announced in 2015, Microsoft also released information about the Universal Windows Platform (UWP), a new framework for building applications that would run on any device running Windows 10. While UWP offered up a whole host of new features to make it easier to build applications, it also came with a host of limitations that made it almost impossible for existing applications to be migrated. UWP missed the mark, resulting in low adoption and leaving the Windows developer community divided. Recently, Microsoft has started to release versions of Project Reunion (which includes Windows UI (WinUI)), which is an ambitious program to reunite the Windows developer community. In this article, we’re going to look at how different groups of Windows developers will be able to adopt Project Reunion. We’ll also look at how Project Reunion, coupled with the Uno Platform, can be used to extend a Windows application across iOS, macOS, Android, Web, and even Linux.

A Brief History

Let’s back up a little and cover off what Project Reunion is. To do this, we really need to back up even further and provide some context and history. Windows has always been a platform that enables developers to build and distribute third-party applications. Over time, the tools, technologies, and frameworks that developers use have evolved and changed. I’m not going to attempt to provide a full list of every different technology that can be used to create a Windows app. Instead, we’re going to focus on some recent changes that Microsoft has campaigned to make it easier, in theory, for developers to build applications for Windows.

I’m going to squash a chunk of Windows app development history to start at Windows Forms (WinForms) that has been around almost two decades (since its release in 2002). This is still one of the most popular application development frameworks because it has a drag and drop designer that makes it easy for developers to get started. WinForms has its share of limitations, which Microsoft set out to rectify with the release of the Windows Presentation Foundation (WPF) in 2006. WPF introduced a clean separation between the layout of pages and controls, written in XAML, and the application logic, written in C# or VB.NET.

With the introduction of Windows Phone, there was a need for a framework that enabled a clear separation between applications, had a clean install/uninstall process, and limited what an application could do to affect the device and other applications. This led to successive SDKs for Windows Phone and Windows that provided the foundation for developers to build applications that could be distributed via the Windows Store (which has since been rebranded the Microsoft Store). During this time, we saw a convergence of the Windows platform. With the release of Windows 10, Microsoft claimed to have a single operating system that powered phone, tablet, desktop, Surface Hub, and even Xbox devices. Windows 10 also brought the Universal Windows Platform (UWP), which made it possible for developers to build a single application that would run across the same range of devices. UWP also provided built-in support for dealing with accessibility, localization, and more importantly, it delivered a tightened security model that isolated individual apps both from each other and from the underlying operating system.

While UWP was similar to WPF in that it used XAML to define layout and C++, C#, or VB.NET to define the application logic, it struggled to gain widespread developer adoption. The value proposition of being able to write a single application that targets a range of devices was grossly oversold. With the demise of Windows Phone, irregularity of updates for the Surface Hub, and the failed attempt to put an Xbox in every living room, there were few benefits associated with UWP. Furthermore, there were significant limitations to using UWP, namely that applications were restricted to running in a closed sandbox that Microsoft had pegged out. Developers, who were used to having almost unfettered access to Windows, rejected the limitations set out by UWP and the Microsoft Store.

One of the other reasons UWP failed to gain adoption by developers in the enterprise is that the deployment model was very regimented and often didn’t align with the way enterprises wanted to manage their environments. With WinForms and WPF, applications could be deployed in a myriad of different ways. For example, you could simply copy and paste the application folder (often referred to as xcopy deployment). Alternatively, you could create a custom installer, use ClickOnce to deploy the app and any updates, or you could generate your application as a single file that could simply be downloaded and run. None of these options were available if you built a UWP application.

Changing Direction

At this point, you’re probably wondering what all the fuss is about; surely, if UWP was so bad, why doesn’t Microsoft just stop investing in it and double down on technologies such as WinForms and WPF? Well, the short answer is that this is exactly what they’ve done. But before we get to that, let’s just look at why this isn’t as simple as it would seem.

As we’ve just been through, there are reasons why UWP isn’t suitable for all applications wanting to run on Windows. However, there are many features of UWP that are the cumulation of years of investment in the underlying technology stack and shouldn’t just be discarded. These include the XAML UI layer, the way resources are managed for different localizations, screen resolutions and device families, and the app lifecycle that allows for efficient handling of suspending and resuming the application.
If developers weren’t going to migrate away from their technology of choice, Microsoft needed to find a way to lift the features out of UWP and package them in a way that they could be used within any Windows application. This is the goal of Project Reunion.

We just jumped a few steps in the timeline. Microsoft worked on a number of technologies that predated the announcement, a year ago, of Project Reunion.
Seeing that both WinForms and WPF were still significantly more popular than UWP, Microsoft set about moving the goalposts. Both WinForms and WPF have received several updates to transition them off the old .NET Framework and onto .NET Core, with subsequent updates for .NET 5 and in time .NET 6. This migration was critical because it meant applications didn’t rely on having versions of the .NET Framework pre-installed. Support is also in the works for ARM64, which will extend support for a new wave of hardware devices.

In parallel, Microsoft also created a new packaging technology, MSIX, which made it possible for developers to package their existing WinForms and WPF applications so they could be distributed via the Microsoft Store. Furthermore, this also allowed for UWP applications to be augmented with "full trust" components that could be used to step out of the sandbox – for example, if you want to interact with the system tray, you could build a component that would do the heavy lifting.

Microsoft also invested in XAML Islands, which provided a mechanism for integrating UWP components into an existing WinForms or WPF application. They had also been investing in the next generation of the Windows UI control library so they could take the UWP XAML framework and detach it from the Windows OS. This not only meant that the XAML framework could iterate independently from the operating system, it also meant that the XAML framework could be used by non-UWP applications. Microsoft realized that if the XAML framework could be lifted out of UWP and made available to WinForms and WPF applications, they must be able to do the same with other components. Project Reunion became the ship vehicle for the UWP components that will be made accessible to Win32-based applications.

You may have noticed I made a subtle change from referring to WinForms and WPF to referring to Win32-based applications. This is because there is now a new type of application that isn’t WinForms, WPF, or UWP. Currently, it’s referred to as a "WinUI 3 in Desktop" - but I’m going to guess that this name will evolve into something more palatable by the time Project Reunion gets to version 1.0. Essentially this type of application is similar to WinForms and WPF in that it is a Win32 application. However, the user interface is defined using WinUI.

Did Microsoft just introduce yet another framework for developers to use when building applications with? Yes, they did, and with it, it will come the same developer and tooling fragmentation that we’ve seen in the past. Here’s the difference: behind all the discussions on GitHub, the Windows Community calls, the Build announcements etc., there appears to be a common goal around uniting Windows developers. As a developer looking at the Windows developer space, you’d be correct in thinking, often out loud, "what a mess" and "why is Microsoft investing in yet another framework," and I can only lay the blame for this at Microsoft’s feet.

Vision for Windows App Development

Let’s try and spell out what the vision for building apps for Windows looks like, based on the releases and roadmap of Project Reunion and WinUI.
A key mantra of Project Reunion appears to be that regardless of which technology you’re using to build for Windows, you should be able to leverage all the features of the Windows 10 platform. This should include the vast set of Win32-based APIs (i.e., Desktop APIs) and WinRT APIs (i.e., UWP APIs). It should also include application-level features such as those that relate to the application lifecycle and notifications.

Project Reunion is about reuniting Windows app developers through a consolidated set of APIs [source: Windows Blog]

In other words, the vision for the future of building apps for Windows is that it shouldn’t matter whether you’re working on an existing application, using an older technology, or starting a new application. You should be able to harness the power of the Windows platform via Project Reunion the Building Awesome Apps for Windows toolkit (BAAW).

Ok, the last bit was tongue in cheek, but Microsoft really does need to come up with a better name than Project Reunion to sell this vision.

To help explain this vision, let’s work through what this might look like for developers coming from a few different starting points. This isn’t an exhaustive list but hopefully enough that you can work out how it applies to other scenarios. Note that these scenarios represent an extrapolated view into the future of what it might look like based on the current releases and the proposed roadmaps.

New Application – This is the easiest scenario as you can simply create a new application using the Blank App (Windows) template in Visual Studio. You’ll be able to decide whether you want to package your application (suitable for the Microsoft Store), or leave it in an unpackaged format, allowing distribution in a variety of ways. Targeting some platforms (e.g., Xbox, HoloLens, or Windows 10X) may require enforcing additional restrictions such as running in a container or restricting certain API usage.

Existing WinForms / WPF Application – In order to take advantage of the new features, existing WinForms and WPF applications need to be migrated forward to .NET 5 (and then ideally onto the .NET 6 LTS release once it’s available). Once migrated, by adding a reference to Project Reunion, the application can start to take advantage of the features being progressively added. For example, applications will be able to embed WinUI controls and/or pages, or they may use notifications, or the app model for better power management. The idea is that developers can choose to migrate some, all, or none of their application to WinUI, and yet still take advantage of the Windows platform features exposed by Project Reunion.

Existing UWP Application – UWP applications, as they are built today, will continue to run and be supported. However, that grouping of technologies won’t evolve much beyond what it is today. This means that to take advantage of the Windows platform features being added to Project Reunion, UWP applications need to be migrated to be a WinUI 3 in Desktop application.

Beyond UWP

As a side note at this point, let me expand on this last scenario as it links back to what I said earlier about Microsoft no longer investing in UWP. In the previews for Project Reunion and WinUI 3, we saw two project types: WinUI 3 in Desktop and WinUI 3 in UWP. The 0.5 release of Project Reunion, only WinUI 3 in Desktop is supported, which caused a bit of an uproar from UWP developers as they felt they were being abandoned.

Here’s the problem with Microsoft shipping WinUI 3 in UWP – it would seem logical from the naming that WinUI 3 in UWP would allow existing UWP developers to simply integrate WinUI 3 controls, in much the same way they did with WinUI 2.x. This is not the case, and it’s unlikely that this will ever work because the two XAML frameworks essentially conflict with each other. In essence, supporting WinUI 3 in both Desktop and UWP is in effect releasing not one but two additional technologies that third-party control vendors must support. You might argue that it’s the same binaries, so a vendor only needs to build the control once, but the issue is that the test and support matrix blows out uncontrollably.

If Microsoft were to ship and support WinUI 3 in UWP, it would have to yield a significant benefit to developers. At present, WinUI 3 is roughly equivalent to UWP XAML + WinUI 2.x, so not much if anything to be gained. Furthermore, the investment in Project Reunion is all about lifting UWP features to make them available for Win32 app developers, so again, there’s nothing that a UWP project would gain from being able to adopt Project Reunion. The logical path forward is for UWP developers to stay with UWP and continue referencing WinUI 2.x until such time that Project Reunion has the set of features on which the UWP application relies.

For example, if you have a very simple UWP application that is just XAML with some basic functionality, you could decide to migrate across to a WinUI 3 in Desktop application today. However, suppose you’re making use of the application lifecycle or notification features of UWP. In that case, you’re most likely going to want to wait for version 1.0 of Project Reunion to make the switch. If you need to target Xbox of Windows 10X, you’re most likely going to have to wait until a future version of Project Reunion before you can make the switch. Limitations on these platforms currently prevent Win32-based applications from running. It won’t be until a suitable workaround is developed that Project Reunion applications will be able to run on these platforms. This may even be a contributing factor to the rumored delays on the Windows 10X, and - of course - the dual-screen Windows devices, such as the Surface Neo, by which the community were so blown away when Microsoft announced it in 2019.

The last comment I’ll make about migrating from UWP to Project Reunion is that all UWP application developers should start investigating this today. While it may be 6, 12, or more months before you make the switch for your production app, you need to start planning for the inevitable. My recommendation is that you move the bulk of your application logic into either a shared or multi-targeted project and then have both a UWP and a WinUI 3 in Desktop project that references the project with the application logic. You should then be able to progressively test and refine your application with the knowledge that once Project Reunion has the features you need, you can simply publish the WinUI 3 in Desktop version of your application and retire the UWP version.

2021 Roadmap

I’ve walked through what the vision for building applications for Windows could look like, but where are we on this journey. The WinUI 2021 Roadmap provides a good overview of this. We’ve already seen both the first release of WinUI 3 in conjunction with version 0.5 of Project Reunion, and two updates, 0.5.5 and 0.5.6, which addressed some critical issues. As we move towards version 1.0 of Project Reunion, we’re likely to see some of the more significant gaps being filled for UWP developers wanting to migrate. These include the application lifecycle, notifications and XAML Islands, which will enable existing WinForms and WPF applications to integrate WinUI components.

WinUI and Project Reunion Roadmap [source: Windows UI Library Roadmap on GitHub]

For WinForms and WPF developers, the current release of Project Reunion doesn’t offer many features that can be easily consumed. MRTCore, which provides a modern approach to resource (strings and images) management, can be used, but it’s really provided as a building block technology for WinUI. It won’t be until XAML Islands are available, closer to the 1.0 release, that WinForms and WPF developers will really be able to leverage some of the UI improvements offered by WinUI.

Another question that often comes up is the interrelationship between Project Reunion / WinUI and .NET. You’ll notice in the timeline, version 1.0 of Project Reunion is due prior to the proposed release of .NET 6 in November. This is indicative of the independent approach that Microsoft is taking with Project Reunion – just as there are minimal dependencies on the version of Windows 10, there’s also minimal dependency on .NET. The core features of Project Reunion have a native implementation, making it possible to consume them from both C++ and .NET applications. With .NET 6, we are likely to see improvements for Project Reunion applications. For example, there’s work being done to add support for AOT, which may have a significant impact on the startup performance of apps.

Multi-Platform

So far, our focus has been on explaining the current and future vision for developers building applications for Windows. However, a large percentage of applications need to target other platforms. Most consumer applications need to target iOS, Android, and Web; Enterprise applications typically want both Windows and web versions but increasingly need to support macOS users. As developers building applications for Windows, wouldn’t it be nice to be able to take that application and have it run on other platforms?

This is where the Uno Platform comes in. Initially, the Uno Platform has been all about adapting a UWP based application and have all, or some of it, run on iOS and Android. Recent innovations have taken the Uno Platform to the web (via WebAssembly), to macOS, to Linux (using Skia + GTK), and even to older versions of Windows (via Skia + WPF host). Furthermore, the Uno Platform is now able to support developers wanting to build WinUI / Project Reunion applications, allowing them to target the full range of platforms.

As developers using WinForms and WPF start to adopt Project Reunion and WinUI for parts of their application, it’s important to also consider how the Uno Platform can be used to reach other platforms. For example, if you add a new set of pages to the application using WinUI, those same pages, along with all the application logic, can be packaged together using the Uno Platform as an application for other platforms.

Contributing

Over the next 6 to 12 months, the developer ecosystem for building applications for Windows will be changing. Microsoft is encouraging all developers to engage with both the WinUI and Project Reunion teams via GitHub in order to help drive the future of the Windows developer platform. If you’re building applications for Windows, you should be looking to understand how you can take advantage of Project Reunion and consider looking at broadening the reach of your application to other platforms and devices using the Uno Platform.

About the Author

Nick Randolph runs a consulting company, Built to Roam, that specialises in developing cross-platform applications using a variety of technologies. He’s been developing applications for Windows and other platforms for 20+ years and is a Microsoft MVP (Windows Development) for his contribution to open source projects, user groups and conferences, and blog posts.