WinUI 3.0 hits alpha preview, gives all developers access to native UWP controls

By Dan Thorp-Lancaster
last updated

Windows 10 Cloud Wallpaper
Windows 10 Cloud Wallpaper (Image credit: Microsoft)

What you need to know

  • WinUI 3.0 is now available in alpha preview.
  • This version of WinUI tears down developer barriers, giving all dves access to native features and controls.
  • More previews are expected in 2020 for Windows 10 desktop and Windows 10X.

At its Ignite 2019 conference today, Microsoft announced that the next version of its Windows UI library, WinUI 3.0, has entered the alpha preview stage.

This updated version of WinUI is meant to operate as a full UI stack for every Windows developer. With it, developers will get access to the same native controls and features in the UWP XAML framework for any Windows app. That includes Win32 apps, covering even .NET Core developers who work in native C++.

The result of all of this is that Windows 10's native UI controls and features will be separated from the UWP SDK and expanded to all developers. Every app will now just be a "Windows app," without requiring developers to repackage their apps for UWP to gain access to these controls and features.

Developers who want to get an early look at this full-stack UI solution can now give it a try. In 2020, Microsoft says that more previews for Windows 10 desktop and Windows 10X, the OS that will power Surface Neo and other dual-screen devices, will become available.

Dan Thorp-Lancaster
Dan Thorp-Lancaster

Dan Thorp-Lancaster is the former Editor-in-Chief of Windows Central. He began working with Windows Central, Android Central, and iMore as a news writer in 2014 and is obsessed with tech of all sorts. You can follow Dan on Twitter @DthorpL and Instagram @heyitsdtl. 

8 Comments
  • Except the reason uwp lagged and never caught on enough to replace win32 is that nobody likes the uwp controls... they all look too primitive and childish... like the uwp GUI components were written by amateurs..
  • Speak for yourself, I like the modern UWP controls and no, the UI design isn't why it never caught on. Keep in mind that the "childish" Metro controls that a lot of UWP apps still use are not UWP controls, don't confuse them together, there are not that many apps using UWP controls completely. Microsoft To Do is the latest one that is doing UWP as it intends to be used. UWP failed to caught on as a whole because Microsoft was too late to evolve it to be useful for the devs. No multi-window support, no cross app process support, etc, confusing sandboxing rules with Microsoft Store requirements for the first few years. The desktop bridge should've been done first, no 3-4 years later and same for Win32 support. By forcing a lot of rules like UWP only in MS Store and releasing SDK that was severely limited, UWP turned into a flop. For UWP controls, they are decent and modern enough that they're worth using if done properly.
  • UWP failed because Microsoft ceased development of Windows 10 Mobile. Without W10M UWP was/is doomed.
  • It makes it harder without mobile but it's certainly not "doomed"
  • Definitely not true. I would argue that the sole reason it didn't work out is that developers couldn't easily package and use the native controls from UWP in Win32 apps and it had to go through the store.
  • UWP apps look better and more modern than the their predecessors from an objective design evolution perspective (that is, they represent the general direction design is taking on other platforms). Apple and others have even copied much of this style. UWP's lack of adoption is not for aesthetic reasons. It's based on developer inertia ("I'll just use what I've used in the past") constraints and requirements tying UWP to the Store, but not providing a full enough feature set to allow all apps to use them (even if the developer would have been happy to publish to the MS Store).
  • UWP controls are not childish. They are boring.
  • When Windows 10 was released back in 2015, the API surface available to UWP apps paled in comparison to the, by then, well developed and mature APIs available to Win32 apps. Many software developers that would've been interested in porting or creating apps for UWP were unable to do so because what their software needed to do just wasn't possible at the time. This made it a simple choice of sticking with their "legacy" Win32 applications that were already working just fine with "old" APIs. From a technical point of view, you can see this to some extent in the evolution of the .Net Standard APIs. Version 1.0 was quite basic, .Net Standard was still compatible with Windows 8.1 up to version 1.2. It wasn't until .Net Standard 2.0 that the API surface was significantly augmented and actually became useful for most projects. If Microsoft had done a better job of, before Windows 10 came out, determining what the most popular applications would need from an API to have better informed the development of the initial UWP API, and made it possible to piecemeal convert existing "legacy" applications over to UWP at a pace that worked for the developers rather than trying to force complete "ground up" re-writes then I think UWP would have stood a better chance of being accepted from the start. Unfortunately, that isn't what happened.