It’s hard to choose a Windows UI framework. After all, there are so many of them. Do you build an application using the familiar WinForms, the more modern Windows Presentation Framework, or Windows 10’s Universal Windows Platform?
Each has its benefits and drawbacks, with different sets of controls, design tooling, and supported versions of Windows. They support different design languages, with only Universal Windows Platform (UWP) controls offering support for the latest Fluent look and feel. Microsoft has been working to backport the new Windows 10 UWP controls to older frameworks, with tools like XAML Islands. They’re a good option but are limited to running on Windows 10.
A new approach to Windows UI
What’s really needed is a whole new approach to delivering Windows UI components and controls, one that’s separate from the underlying OS and able to deliver the same features on more than Windows 10, with versions for older versions and on other platforms, like the Web. Unsurprisingly it’s a project that’s been under way for some time, as part of the WinUI controls library. Earlier versions of the Windows UI library focused on UWP and on Fluent Design. The next big release, WinUI 3.0, will finally step outside the UWP framework, supporting the entire native Windows UI platform sometime in 2020.
Microsoft recently released an alpha of WinUI 3.0. It’s by no means complete, with many popular controls missing. However, it’s a good place to start with the new controls and with new ways of installing and using them. As alpha code it’s not ready for production, but it’s intended for you to try out and give feedback to the development team.
Using the WinUI 3.0 alpha release
Getting started with WinUI 3.0 is easy enough, as Microsoft has the code for a preview version of a WinUI 3.0 release of the XAML Controls gallery on GitHub. You can clone the repository and build the sample app to see the available controls. The sample does need a recent version of Visual Studio (I recommend Visual Studio 2019) and Windows 10 1803 or later. Visual Studio will need to be configured for .NET Desktop and UWP development, along with the equivalent C++ tooling if you’re working with C++ code. The biggest change is probably the move to a new namespace: from Windows.UI to Microsoft.UI.
I was able to get the sample code up and running in a few minutes, using the Git bash tools to clone the WinUI 3.0 Alpha branch of the sample app, and compiling in Visual Studio 2019 Community Edition. Once loaded you get a list of the available controls, clicking through to them displays sample code along with a rendered instance of the control. It’s a good way to see what controls are available and how you’d use them in your apps. Missing controls are grayed out, so you can see what’s planned for future releases.
Signing up for the WinUI 3.0 alpha gives you access to a Visual Studio extension that adds new WinUI 3.0-specific templates. It’s well worth installing if you’re building new WinUI apps, as it gets you started with templates for runtime components and blank apps for both .NET and C++. Don’t worry if you can’t find all the controls you want to use; this is only an alpha release and some common controls are yet to be rewritten for the new framework. With release due sometime in 2020, there’s still plenty of time for them to come to future alpha and beta releases.
Separating UI from Windows
Perhaps the most important part of the WinUI transition is the separation of UI controls from the rest of the Windows SDKs. It’s an important change that lets us finally update UI controls separately from the underlying OS, and even allows the community to work on them as part of an open source project. That’s a surprisingly big shift, moving UI away from Windows and on to NuGet. Today, if there’s a bug in a list box control, we must wait for the next semiannual Windows update for a fix. With WinUI 3.0 we’ll be able to download an updated control from NuGet, rebuild our app, and then publish the update.
That separation of UI from the rest of the Windows SDK should make it easier to update the rest of the SDK. If WinUI can successfully make the transition to NuGet, it’s clear that we can slowly carve off more elements of the Windows SDK, sending them on the same journey. That should help drive the adoption of .NET Core and the future .NET 5.0 for Windows application development, allowing it to evolve outside the Windows development timelines. New releases of Windows will always require new releases of the Windows SDK, but there’s no reason why it shouldn’t continue to evolve outside of that semiannual cycle, fixing bugs and adding new APIs and features.
Going cross-platform via WASM
Microsoft has big plans for WinUI 3.0. Not least is its partnership with the team building the Uno Platform web assembly controls, which promises browser-hosted versions of WinUI 3.0’s control library. With Microsoft promising to deliver versions of its new Chromium-powered Edge browser back to Windows 7, as well as on Linux and on macOS, you’ll be able to use these controls along with Blazor’s Web assembly implementation of .NET to deliver WinUI 3.0 apps to all these other platforms.
Delivering a cross-platform, backwards-compatible (within reason) WinUI is a sensible step. We live in a world where users have choice and computing is heterogenous. If developers want the widest possible reach, then we need tools like this which can deliver across not only modern .NET implementations but also to older platforms by whatever means available. Using WebAssembly for WinUI makes a lot of sense, as it is a truly cross-platform UI environment.
There’s a lot to like here, even if all we have is an alpha release. The WinUI 3.0 tooling is familiar and easy to use, making it simple to move existing UWP code to the new UI framework. Support for C++ Win32 apps will give you an opportunity to bring Fluent Design to what had been WPF or WinForms code, without having to jump through the XAML Islands hoops. With plenty of promise, it’s going to be hard to wait for 2020 and general availability.