Building next-generation applications with the Windows Application SDK

One of the biggest problems Microsoft faces is how to make Windows an attractive platform for developers again. It’s easy to put a web front end on a cloud-native application that supports desktop and mobile users, no matter what devices and operating systems they’re using.

We’re in an odd place where the only applications that take advantage of the latest PC hardware are tools like Office, Photoshop, and games. That makes Microsoft’s announcement of a new hardware standard in its Copilot+ PCs an interesting pivot point. It’s intended to bring AI inferencing to the desktop and (outside of support for the WebNN local inferencing standard) requires native code to use that new hardware.

How then is Microsoft to get developers to turn back to the desktop and Windows? Part of the problem has been an inconsistent and fragmented approach to Windows development. Do you use Win32 and the Windows SDK or build.Net apps with WPF and WinUI? Or do you take the approach delivered with Windows 8 and go with the WinRT APIs?

That’s where the Windows Application SDK comes in. Best thought of as a way of packaging APIs and components that come from outside the Windows SDK, it’s how Microsoft delivers new features to developers outside the normal Windows release cycle. As Microsoft notes, it’s not a replacement for existing tools and technologies. Instead it’s designed to work with them, so you can continue building Windows applications using familiar languages and frameworks, adding in the Windows App SDK as a way of modernizing your code.

Getting started with the Windows App SDK

The Windows Application SDK ships as a mix of Visual Studio extensions and application components. These add templates to quickly build new projects. You’ll need to install the Win UI 3 tool to use its user-facing features. Other tools help migrate code to new frameworks.

Once installed, it provides new libraries that help you build applications that work with modern Windows features. These include Win UI 3 controls, improved text rendering for better readability in text-first applications, better application life-cycle management (including taking advantage of OS-level power management features), and new window management tools. Other new features offer better application resource management, including support for multiple language strings, an improved notification framework for both push and local operation, and packaging tools that ensure appropriate runtimes are included with your binaries and other application artifacts.

Microsoft provides plenty of documentation, including all-important migration guides. With Microsoft actively encouraging use of Win UI 3 and the Windows Application SDK (if not deprecating older Windows frameworks), these are an important tool as they help you move from, say, UWP to newer ways of working. Migration should be simple, first migrating controls from Win UI 2 to Win UI 3, changing namespaces as you do so, before copying across application business logic. Things are easier if your code was written in.Net, as the.Net Upgrade Assistant will help move C# UWP code to the Windows Application SDK, automating much of the process.

It’s well worth spending time with the documentation, as it helps map UWP features to the Windows App SDK, allowing you to update low-level code. Some changes are a matter of changing namespaces, while others require new classes to replicate older features. Most features are supported, though in rare cases you may need to develop your own libraries and controls. Microsoft provides a table that shows the most common mappings, which should help with migrations.

Some bigger platform-level changes come with a migration. UWP offered application-level isolation, and this is lost when moving to alternate frameworks. However, there are options, like Windows’ new Win32 App Isolation tools, which take advantage of newer Windows security features to run your code in an isolated sandbox.

You can find a list of the differences between UWP applications and the Windows Application SDK on Microsoft’s Learn site. This includes where there may be workarounds, as well as features that haven’t been migrated yet. One key issue is performance, as applications will use more RAM and will take longer to load.

Download channels show upcoming features

The Windows App SDK is available in three different channels; you can choose between the current stable release, a preview release for features that should ship soon, or an experimental channel where new features are trialed. The current supported release is Version 1.5.5, released early in July 2024. The next major release will be in six months or so. The current preview release predates the current build, so a new version should be available soon. Experimental builds are based on the development tree of the planned 1.6 release, with a second release in July 2024.

Microsoft provides a list of the features available in each channel, along with the current support life cycle. Versions are supported for a year from initial release, so the current 1.5 release will be in support until the end of February 2025, with Version 1.4 dropping out of support at the end of August 2024. There’s one unusual caveat to the Windows App SDK support: Although it offers compatibility back to Windows 10 Version 1809, technically only in-support versions of Windows are covered.

The Windows App SDK and the Copilot Runtime

The Windows App SDK is intended to be a key component of the Copilot Runtime, hosting, among other features, artificial intelligence APIs based on the Phi Silica local generative AI model and AI-powered OCR services. However, these promised features are still missing from the current Version 1.6 experimental builds, two months after Build. If Microsoft wants to shift developers’ attention to Windows, it needs to capitalize on the capabilities of its new hardware and ship Copilot Runtime APIs as soon as possible and accelerate the transition of Version 1.6 from experimental to production.

The early launch of Copilot+ PCs seems to have been a way to get hardware out in the market, but at the rate Copilot Runtime features and development tools are rolling out, we won’t be able to take advantage until late 2024 or early 2025 at best. That slow progress not only in the Windows App SDK’s AI features, but across all the elements of the Copilot Runtime stack remains disappointing.

You can’t ship code based on SDK releases to the Windows Store, as it’s not supported. Users are expecting to be able to use software that’s built on these new capabilities, and while improved battery life is a big win for the new Arm-based hardware, the longer we have to wait for new AI endpoint features, the harder it will be to justify developing apps that use them. Releasing the Copilot Runtime piecemeal over months won’t drive developers to use it, and workarounds using ONNX make it hard to package and deploy apps.

It’s time to port your code

Still, it’s worth beginning the process of porting applications to the Windows App SDK. At the very least it gives you a way to future-proof code and take advantage of Microsoft’s preferred Windows development path. As it builds on familiar.Net tools and open source technologies, there’s a shallow learning curve. There are also options that go beyond Microsoft’s tools, allowing you to bring in third-party controls and cross-platform tools such as Uno and Avalonia UI.

Microsoft provides sample code to help you add Windows App SDK features to your code via its Learn platform or via ready-built applications. In the past, I’ve touched on the Windows Community Toolkit, a sampler that provides examples of features as well as the code used to implement them. The application updates regularly; the current release is Version 8.0. It’s not purely for demonstrating how to use controls and UI; it includes code for handling complex mathematical operations, which are essential for working with vector and graph search algorithms.

The Windows App SDK is important for modernizing your desktop application development process, bringing support for new features to new and existing code. If you’re building for Windows, you need to be using it, as it provides access to essential APIs and libraries, as well as providing guardrails and guidelines for the best use of modern Windows features.