Recently I came across a twitter thread talking about WinUI 3.0 (WinUI3) and how it failed to live up to expectations. Hopefully @JaykeBirdCoding won’t mind me going through his tweets and providing my thoughts – if you get value out of this analysis, please make sure you go follow @JaykeBirdCoding! For anyone else out there considering cross platform solutions, please make sure you consider including Uno Platform and Flutter as these are for me the stand out options in this space.
Before jumping in, I will add that whilst it may appear, based on my reactions to each tweet, that I’m being a bit harsh, I do in fact understand where a lot of the confusion comes from. Microsoft in their infinite wisdom have used the same marketing term, WinUI, for two somewhat related, yet different, products.
On one hand you have a WinUI 2.x, which is a purely a control library that sits on top of UWP; on the other hand you have WinUI 3.0, which is an entire framework but does not sit on top of UWP. WinUI3 effectively replaces the UI/Application framework of UWP. If you’ve been using WinUI2.x, you might reasonably assume that you can upgrade to WinUI3 – this is not the case, there is no compatibility between UWP XAML and WinUI3; the latter replaces the former. This causes issues if you are using any third party libraries that don’t have a WinUI3 version available, as the UWP controls will not work.
- WinUI3 is completely new UI platform
Yes, the idea is to separate the UWP UI/Application framework away from Windows. However, the whole framework isn’t what I’d classify as new – the aim is to use the same XAML as UWP (except for namespace changes) and to make it as easy as possible for developers to transition across to building WinUI3 apps and to migrate existing UWP apps across to WinUI3.
The other, probably higher, priority is to allow desktop apps to leverage the same UI/App framework. Note – by desktop we are NOT saying WinForms or WPF, we’re saying apps that run on desktop Windows outside the Windows app container.
- Two options: desktop and UWP
The difference is primarily whether the app will run in the windows app container or not. However, the more subtle difference is that desktop targets .NET 5, whilst UWP still uses .NET Native.
- No support for Xbox, Hololens etc
The long term goal is to include these targets but initial focus is on bringing the UI/App framework to desktop apps. I must confess I haven’t tried to run a WinUI UWP app on an Xbox, I had just assumed it wouldn’t work.
- Assume UI/App framework could be added to “WPF and Win32 UI platforms”
Microsoft has never indicated that this would be the case (without using XAML island or equivalent). In fact, there’s never been any indication that WinUI3 will be compatible with UWP XAML.
However, I can see how easy it is to come to this false assumption given the awful job Microsoft has done communicating what WinUI3 is, and what it’s not.
- No need for XAML islands
This assumes that all UI platforms are compatible with each other, which is clearly not the case. There will be an interop story down the line but not a day 0 priority.
- Never comfortable with XAML islands
Agreed, this was a patch for allowing technologies to work together. In many ways this is no different from interop between WinForms and WPF, so I don’t see the need for this going away anytime soon.
- Only accessible to WPF via XAML islands
Not sure what was expected here – It’s never been positioned as just a control library for WPF but again I’ll concede that this comes back to a clear vision from Microsoft.
- Not used XF or UWP much
At this point my interest in this thread is waning. It seems that despite UWP being based on work that’s over a decade old (if you look at the history of the APIs from Windows Phone, Windows 8 through to Windows 10), there’s been little effort put into to learn the framework. I decided to preserve as I’m sure there are other developers who have buried their heads for this long too and would benefit from this analysis.
- XAML, so a lot of knowledge will carry over
Yep, it’s MVVM and data binding all the way. There’s a bunch of features that WPF has that are missing in UWP/WinUI but very few of them are complete show stoppers.
- .NET5 + WinUI get to access all the shiny technologies Win10 has
Yes, this combination is going to be the winning formula going forward. If you had to pick a new technology to build Windows apps today, this is going to be it. It’s worth pointing out here that if you’re building a WinForms or WPF app, you can still leverage the Windows 10 apis and in fact you can even register for identity so you can use all the apis properly!
- Super excited about Xamarin.Forms becoming Maui
Why is Maui any more interesting than Xamarin.Forms? Apologies if I’m being blunt here but Xamarin.Forms has had it’s day in the sun. There are better cross platform solutions out there now that provide a richer more extensible solution going forward.
- There’s already Avalonia
Avalonia is limited to desktop, which doesn’t address the massive iOS and Android target market. It’s pretty cool tech but the lack of support for the two most influential platforms significantly limits my interest in it.
- Disappointed that WinUI3 isn’t what you thought
You mean that you’re disappointed Microsoft isn’t building something you imagined? Not wanting to be disrespectful in my analysis but this is the thought that came to mind – how can you be disappointed Microsoft is building something that you had imagined, rather than what Microsoft said they were investing in. However, I’ll again return to the point that this is a direct result of Microsoft not clearly defining the vision for WinUI3.
- Wonder what future projects will be
This is really going to depend on what platform(s) you want to target and the relative maturity of WinUI. WinUI3 is very early days. Whilst it’s based on UWP the process of bringing WinUI3 to market is non-trivial and initially will focus on desktop scenarios.
- Don’t know what .NET Maui will support
It’s based on Xamarin.Forms which targets UWP today and in future, I would assume, WinUI.
- Using WinUI will mean dropping win7 and 8.1.
Yes, that’s correct but WPF isn’t going anywhere, so if you feel like investing time into a diminishing market, WPF is your friend. You can also target the new Win10 APIs by using .NET5 and support for WinRT and Identity.
- Expect new projects will target Win10
- WinUI and Maui both intriguing
Horses for courses – work out what platform you want to target and use the most appropriate tool. Also don’t limit to .NET world. There are other (in some scenarios better) cross platform solutions, depending on what targets you want to address.
- Thoughts all over place
This is to be expected given the state of the .NET ecosystem and the terrible job Microsoft have done in communicating. I wish I had a single place I could point developers wanting to understand the dysfunctional state of play between the various Microsoft teams: Maui, WinUI, Project Reunion, dotnet etc.
- The follow up. Summary – stick with WPF and look to Avalonia and Maui.
Stick with WPF I understand as WinUI isn’t ready to be unleashed. Avalonia and Maui aren’t great options when it comes to cross platform but lets cycle back to this after we go through the tweets in this thread.
- WinUI is UWP with new name
Yes and No.
Yes, the UI/App framework from UWP has been decoupled from Windows and is in the process of being made open source.
No, it’s not just a repacking of UWP. For example, WinUI will be able to run outside the windows app container, targeting .NET 5. It’s also a native library that can be used by C++ developers to build rich windows apps.
- WinUI3 UWP is upgrade path for current UWP
Yes, agreed but has been pushed out as not a priority for day 0 release
- WinUI3 desktop is the entire library open to Win32/C++ devs
Yes, although better way to think of it as being one framework, WinUI, that can be hosted on desktop or in a Windows app container. As it’s a native implementation it can be accessed by both managed (.NET) and native developers.
- WinUI on UWP has same restrictions
Yes because this is due to the windows app container it runs in
- No idea if it will work on Hololens or Xbox
This is on roadmap but what’s not certain is whether this will be WinUI on UWP, or WinUI desktop with opt in for windows app container. Given the direction of Project Reunion I’m going to guess it will be the latter. I don’t see WinUI on UWP getting much love and I don’t see it being the dominant platform going forward.
- UWP going into maintenance mode
I’ve already made the call that UWP is being archived but it’s not that simple. It’s actually .NET Native that’s in maintenance mode. But agreed, there’s no reason not to choose UWP unless you need to target Hololens and Xbox today.
- Exciting that C++ developers can access modern Windows UI platform
- Or use C++/CLI for Winforms/WPF
You could but why would you want to inflict that pain on yourself?
- Missing visual designer and media controls
Yes, there will be some missing elements initially but since this is the future you can expect Microsoft to be back filling these gaps quickly
- Can already access win10 apis
Yes, although it’s a bit harder if you want to use apis that require identity.
- Wouldn’t adopt UWP
Yes, UWP (as an app framework) is dead to me.
- No support for XAML islands at launch
Yes, it’s all about priorities. Just use WPF with XAML Islands to UWP controls today and then switch across to WinUI controls when WinUI3 XAML islands support is available.
- No controls that are of interest
Fair enough. The WinUI 3 controls look best on Windows and deal with themes and dpi much better that WPF but agreed there are work arounds for most of these things.
- Some nice controls
Yes, and going forward WinUI3 will be where all the investment in new controls will occur. whilst it may not appeal today, over time the controls will build and improve. WPF will stagnate and there will be less support from vendors going forward.
- Going to go to Maui or Avalonia for multi-platform
Maui will probably end up adopting WinUI3 anyhow
Neither of these solutions are viable for production ready apps any time soon.
I’m going to skip a few tweets and comment on only a few of the more relevant tweets.
- Microsoft has open sourced wpf
Companies typical open source for two reasons: growing or archiving. It’s very clear that extending WPF is not a priority for Microsoft, so it’s being open sourced essentially as a way of archiving it. I’m not sure why anyone would think there’s going to be a massive ramp up of features added to WPF. Given that there are so many apps built using WinForms and WPF, it’s important that Microsoft give these apps a fighting chance to co-exist with Windows 10 apps.
- Tweaks or bug fixes
By this you mean support for ARM64? Not sure how that classifies as a small thing. It’s clear that the priority for Microsoft around WPF is to make sure that existing investments in WPF apps continue to work well on all Windows 10 devices, rather than necessarily adding new features to WPF.
- PRs just hang around
See earlier comment about archiving. Microsoft has acknowledge in the community calls that they did change priorities with more focus going on project reunion and some key scenarios for WPF (.net 5 and ARM64 support).
- MAui/Avalonia are cross platform solutions
If you want to do Maui, you can get started with Xamarin.Forms today
Avalonia is basically a Windows only solution. Ok, you get Mac and Linux, but you don’t really want to be ignoring the ios and android platforms. If you’re building a desktop platform and you haven’t considered porting to ios and android (as priority over mac) then you’re seriously limiting your own success.
You need to look into both Uno and outside the .NET ecosystem if you’re serious about cross platform.