This article is more than 1 year old
Microsoft brings WinUI to desktop apps: It's a landmark for Windows development, but it has taken far too long
The look and feel of UWP without all the baggage
Hands On Microsoft has pushed out a preview of WinUI for desktop applications, making it possible for developers to adopt the look and feel of UWP (Universal Windows Platform) without having to adopt the UWP application model.
WinUI is Microsoft’s GUI framework for Universal Windows Platform (UWP), and the big news at the recent virtual Build event was the release of WinUI Preview 1 which also supports Win32, also known as desktop applications. This means developers can create a desktop application using visual components that previously only worked in UWP (leaving aside an existing hybrid option called XAML islands). What is the difference then between a UWP application and a Win32 application, if they now look the same?
The answer is that UWP and Win32 applications are different under the covers. UWP applications are sandboxed, for example with restricted access to the file system according to a complex set of rules.
A desktop application, by contrast, has the file access permissions of the user. A UWP application has an app lifecycle including a suspended state which kicks in if the user minimises it or switches away, whereas a Win32 application runs until the user closes it. Another issue is code that relies on Windows API code using window handles (HWND), which is how the operating system has worked since its first release. This code generally does not work with UWP applications, whereas it does work with WinUI for Win32.
In other words, UWP comes with a fair amount of baggage which is there for a good reason – such as security or power management or system protection – but which can also get in the way and break legacy code. The new WinUI is in effect Microsoft surrendering to compatibility above modernisation.
Under the hood
What was actually released in the preview though? WinUI 3 Preview 1 has lots of limitations, especially on the Win32 side. One of the biggest is a note that says: "WinUI 3.0 content can only be in one window per process or one ApplicationView per app" – not so much Windows as Window.
The tools are also limited. We set up WinUI 3 on a virtual machine, and it needs the latest .NET 5.0 preview bits in both 32-b-bit and 64-bit guise and the latest preview of Visual Studio 2019 (Visual Studio 2019 has been released for ages, but this is a kind of insider build of a forthcoming update). Then one adds a WinUI extension to Visual Studio, start a new WinUI 32-bit application, and get a “Hello world” XAML page with no toolbox or visual designer. Documentation is limited, and the way to proceed is to download and inspect a project called the XAML Controls Gallery which has example code for the controls that work. The master branch does not work, but there is another called winui3preview which does.
It is pretty rough. When can developers use this stuff for real? There are a couple of projected dates worth noting. The first is November 2020, when Preview 4 is scheduled. Despite the name, this will be supported for production "if it meets your needs", according to Microsoft's Community Call presentation at Build. Spring 2021 will see Preview 5 and then general availability – with the further proviso that .NET 5.0 is not a long-term support release. For that, wait until November 2021 and .NET 6.0. Better news is that compatibility with older versions of Windows is not too bad; Microsoft is talking about reaching as far back as Windows 8.1 via compatibility code called polyfills.
Nevertheless, WinUI 3 is a landmark release for Windows developers. It is not just the decoupling of the GUI API from UWP, but also the addition of needed features like input validation, which means it is maturing and better suited to business applications than before. In theory, it could bring more consistency to the Windows 10 ecosystem, currently a mish-mash of design styles including WPF (Windows Presentation Foundation, based on DirectX), old-style GDI+ Windows 7, UWP in various guises, and applications that do their own thing using cross-platform libraries – though in practice many will stay the same for as long as they continue to work.
There is also the question of the merits of Microsoft's Fluent Design System, which is the look and feel that WinUI enables. In a recent post, Microsoft's director of product design Benedikt Lehnert described the company's goals for Fluent Design, which includes cross-platform as well as Windows. "It can be frustrating when things work differently for no (or some unexplained) reason," he observed; but how do you get a user interface that works "the same" when there is an inherent contradiction between cross-platform consistency and offering a native experience for different operating systems?
Reading Lehnert's piece, it is apparent that Microsoft is focused more on getting Microsoft 365 products working consistently on Windows, macOS, iOS, Android and Web, than on fixing design issues in Windows. Third-party developers also have this problem, which is why Microsoft faces constant requests to make WinUI cross-platform, something which at Build the team said it was considering.
Microsoft says it has shipped or installed Windows 10 on more than 1 billion devices, which suggests that it remains an important target for developers. Its appeal has been damaged though by too many changes of direction, failure to establish the Microsoft Store as the main route for application discovery and install, and the necessity of cross-platform for many types of application. WinUI and the associated Project Reunion looks promising as a means of modernising applications without forcing developers to adopt UWP, but will not be fully baked until, perhaps, 2021, nine years after the release of Windows 8. It has taken far too long. ®