With the recent excitement surrounding the announcement of Windows 11, there’s renewed interest in developing apps for the Windows platform. In this post we’re going to celebrate what it means to be a Windows App Developer, regardless of what framework or technology you chose. It’s not going to be an exhaustive list of options but hopefully enough to paint a picture of future of app development for Windows across the spectrum of developers from web through to Uno platform.
Let’s start by reiterating one of the overarching goals of the Windows App SDK (formerly Project Reunion), which is to unify Windows app developers by providing a consolidated set of APIs that are independent of Windows OS version. The idea is that any developer wanting to build an app for Windows should be able to leverage the Windows App SDK in order to access features such as Windows UI, WebView2, Notifications, Lifecycle events and more.
The Windows App Sdk includes the ability to create an application using Windows UI (WinUI3), targeting desktop (ie WinUI3 in Desktop). Whilst this is a Win32 based application it is neither a WinForms or WPF application. As such, rather than referring to it as a WinUI3 in Desktop application, I’m simply going to call it a “Windows App”.
I am building my first Windows App
If you’re starting on a brand new app for Windows the simplest options is to use the new project template for a Windows App. Currently this is the “Blank App, Packaged (WinUI 3 in Desktop)” template but I’m hoping as we get to v1 of the Windows App Sdk this template gets simplified, for example to “Blank Windows App”.
Other options for your Windows app include:
- Build a progressive web application and use pwabuilder.com to generate an application package for Windows (see more details in the I am a Web Developer section).
- Build a WinForms or WPF application to take advantage of specific third party libraries (see more details in the I am a WinForms / WPF Developer section).
- Build a UWP application to take advantage of running across different devices (desktop, Surface Hub, Xbox, Hololens) or other features that aren’t yet in the Windows App Sdk (see more details in the I am a UWP Developer section).
If you pick one of these alternative strategies, the important thing is to have a plan to adopt the Windows App Sdk so that you can eventually take advantage of new features that Microsoft rolls out in the future.
Option 1: Create new WinUI3 in Desktop app
Option 2: Use a different technology and plan to adopt the Windows App Sdk in the future
I am a UWP Developer
Whilst UWP does have some limitations, often imposed by the sandbox/container that the applications run in, the platform has some great features, so it’s not surprising that most UWP developers aren’t willing to migrate their applications across to be a WinUI in Desktop application. Over time, more of the UWP features will be made available to Windows Apps. As such, we’re likely to see a gradual migration of apps from UWP to a Windows App.
Microsoft has tried to limit the differences between UWP and WinUI3 (used by a Windows App) with a view that this will assist developers migrate their applications. Whilst some of the changes are relatively straight forward (eg namespace change from Windows.UI.Xaml to Microsoft.UI.Xaml), there are some changes that won’t be as evident until the application is being tested (eg switching from Dispatcher to DispatcherQueue). There are some UWP features that either haven’t been migrated, or will not being migrated, to a Windows App. If you’re relying on these features in your application you may need to hold off migrating or look at alternative ways to achieve the same outcome in your application.
The question this raises is what options do UWP developers have? Is it necessary to migrate to a Windows App?
Microsoft has had a preview version of WinUI3 that worked with UWP. Whilst Microsoft hasn’t come out and stated that they will never support WinUI3 in UWP, they’ve indicated that right now there are no plans to release a stable version of WinUI3 in UWP. It was observed that since Microsoft’s planning is between 6 and 12 months forward looking, a stable version would be beyond that timeframe, if it were ever to be included in the roadmap.
Microsoft has clearly stated that they plan to continue development on WinUI2.x which will target UWP. Whilst they’ve given no indication on how long this will last, it does appear that currently new features for WinUI are being developed in WinUI2.x and then added into WinUI3. If this strategy changes (eg development of new controls or features are done in WinUI3 and then back filled to WinUI2.x) this could signal a horizon for the end of further development of WinUI2.x for UWP.
Note that just because Microsoft is no longer developing new features for UWP, this doesn’t in any way signal the end of support for UWP (since Microsoft will have to support UWP in production for a long time to come).
If migrating to WinUI3 in Desktop isn’t viable right now, perhaps because of missing features, the alternative strategy is to multi-target your application to produce both a Windows App and a UWP app. The bulk of your XAML and code can be shared between the two applications; you can continue to ship your UWP application whilst you migrate and test your Windows app application. Once you’re satisfied that the Windows App application has all the features it needs, you can then ship it as an upgrade to the UWP application.
Option 1: Migrate to a Windows App
Option 2: Migrate and Maintain both a Windows App and a UWP app
I am a WinForms / WPF Developer (.NET Core / .NET 5 / 6)
Applications that are built using WinForms or WPF that have already been migrated to .NET Core should continue to upgrade to the latest .NET version in order to be able to take advantage of the Windows App Sdk. The migration from .NET Core 3.1 to .NET 5, and subsequently .NET 6 when it’s released, shouldn’t require too many changes (if any) and should be included in any roadmap for development.
Currently the Windows App Sdk doesn’t support adding Windows UI controls or pages to an existing WinForms or WPF application (this is referred to as Xaml Islands in the roadmap). However, there are other features such as localisation (resources) and app lifecycle that could be useful.
Option: Add a reference to the Windows App Sdk and plan which features you want to take advantage of
Future: When the Windows App Sdk supports Xaml Island you should consider leveraging Windows UI controls and pages within your application.
I am a .NET Framework Developer (WinForms / WPF)
For applications that are still targeting the .NET Framework, the forward strategy should be to migrate to .NET 5 (and then later to .NET 6). Applications that are stuck on the .NET Framework due to third party controls or libraries such prioritise either working with the vendor to get them to produce a .NET Core compatible version, or should look for alternatives that are compatible with .NET Core.
Option: Migrate to .NET Core and then look at incorporating the Windows App Sdk
I am a Web Developer
For web applications that want to feel like they belong on Windows, rather than just another website accessed via a browser, the recommendation is to upgrade the application to be a Progressive Web Application (PWA). This can be as simple as including a manifest file; or the application can take advantage more native-like features such as shortcuts / jumplists, notifications, file and protocol associations etc.
PWAs can appear in the Microsoft Store by using pwabuilder.com to generate a package that can be submitted to the Microsoft Store. This will increase discoverability, whilst still maintaining all the benefits of being a web application.
Option: Upgrade web application to PWA and submit generated package to the Microsoft Store for better discoverability.
Note that I do appreciate that this option doesn’t include accessing the Windows App Sdk features. However, it is still an important option when considering building applications for Windows.
I am a Xamarin.Forms Developer
Xamarin.Forms applications that target Windows via UWP will need to consider migrating to either a Windows App (see section for I am a UWP developer), or to .NET Maui. The latter will support existing Android and iOS platforms but will switch from having a UWP target (Xamarin.Forms) to a Windows App target (.NET Maui). Whilst Microsoft has already started the work on tooling for the upgrade from Xamarin.Forms to .NET Maui, the real issues will be in relation to third party controls and libraries which won’t necessarily have a clean migration path.
Option: Upgrade to .NET Maui in order to leverage the Windows App Sdk
I am a Uno Platform Developer
Most applications that make use of the Uno platform are based on UWP. However, Uno also have a version of their platform that is based on a Windows App. The Uno development team is doing an amazing job tracking the work being done on the Windows App Sdk and releasing new versions of the Uno platform that are updated for each release.
The migration for a Uno application from UWP to a Windows App involves similar steps to migrating a UWP to a Windows App. It’s also possible to continue to compile a UWP application that uses WinUI2.x as part of the same solution – I’ll do more of a drill down into this for Uno in a subsequent post but it’s not to dissimilar to the post I did on How to Upgrade a UWP Application to WinUI 3.0 which has a Windows App and UWP app using the same XAML and code.
Option: Switch to Uno for Windows App.
Summary
As you can see from this post, there are a range of different options for how to plan for the future of your Windows application. As the Windows App Sdk continues to evolve and mature, it’ll open up some of the great features in the Windows platform to all native app developers.
If you’re working on an app for Windows, now is the time to investigate the Windows App Sdk and work out how you can take advantage of some of the new features and how you can leverage the Windows App Sdk to improve your application.
Nice article, I myself am excited about windows 11 app development. Nice overview.