Discussion: Have you seen real projects using WinUI?

[omikhailov]

I heard that Windows 11 preinstalled apps are made with WinUI 2, and they are being developed by a team from the Chinese office, but it would be interesting to know how and where folk use WinUI elsewhere. Do you know about commercial projects built with WinUI? What kind of apps were they? Was it a good experience?

P.S. Sorry for the flooding, I'm just curious.

[shelllet]

I have developed a simple rpa tool by c++/winui3, but I would like to say that the current progress and featurs of winui3 cannot develop commercial applications,

[llothar]

I'm listening to a lot of solo developers in the independent app scene (former known as shareware). And i can answer with a clear no. At the moment nobody i know is even planning to go this way.

[dongle-the-gadget]

Well there are many production apps currently using WinUI 2, not sure about WinUI 3 though.

[levinli303]

I have a simple unarchiver app written in WinUI3, also available on Microsoft Store. It's cross platform, sharing some objective-c(++) code under the hood with iOS/macOS. The UI part is entirely WinUI3. It is lacking some features for sure (drag and drop virtual file without needing a dll extension), but mostly it is ok as an unarchiver.

https://www.microsoft.com/en-us/p/easy-unarchiver/9nkl1jq5c62v

[MEK3DK]

As others here say WinUI 3 is not ready for commercial applications.

We did an investigation into WinUI 3, whether we could start changing some apps to use WinUI 3 instead of WPF, but there are a lot of features missing and the amount of bugs makes it unrealistic.

WinUI 3 is only for hobby apps atm, my best estimate is 2 years untill it might be ready, depending on what resources Microsoft apply.

[fredemmott]

Hobbyist with a cross-platform (mostly non-UI - UI mostly Qt, little bit of wxWidgets) background; I just ported my app from wxWidgets to WinUI3 with C++/WinRT.

There's a lot of rough edges in winui, winui's documentation, and MSIX, especially when not distributing in the MS store. MSIX is not part of WinUI, but there's such a bias towards 'packaged' apps in WinUI and the App SDK that it feels fair to bundle.

Overall, Qt is leagues ahead on documentation and raw power/usability, but I'm avoiding it given I'm not confident in their current stance on open source. Compared to wx, winui makes the easy stuff hard and the hard stuff easy. It's much easier for me to make something work with wx, but once I have something working, much easier to make it look good and feel usable with winui (except for title bars).

Concretely:

• navigation view + navbar + title bar content/back button doesn't work without a lot of manual work. I suggest MS attempt to dogfood this in the winui 3 controls gallery - which - at least in the store version - has a classic windows title bar on Windows 10.
• if you start a winui3 app (including the controls gallery) and don't move the mouse, it will show a busy spinning cursor until you move the mouse. This seems trivial, but makes winui3 apps 'feel' slow
• many things are technically documented, but hard to find - e.g. how to disable the mddbootstrapinitializer to do it by hand, how to disable the xaml generated main. Most of this is documented on /some/ page, but it's quicker for me to dig into the source than attempt to find the documentation. Documentation is spread between c++/winrt, windows app sdk, and winui 3, which makes sense - but it would be much easier if documentation were sorted by high level problem rather than the component that solves the problem. API reference documentation is great once you know what class/function/component/... you need, but finding that out (discoverability) is the problem.
• many times after searching for documentation on MSDN, I simply don't find it, so I google. Many small-but-key things (e.g. that IWindowNative exists, or that with winui contentdialogs from c++/winrt you need XamlRoot, file open/save dialogs need IInitializeWithWindow) have reference documentation, but it's very hard on MSDN to go from "I have this problem"/"I want to use this control", to "this is the API you need to make it work". Google searches almost always end up pointing me to an Old New Thing blog post or a StackOverflow answer by Raymond Chen - not the official documentation. While Raymond Chen's blog and answers are incredibly valuable, they should not be an essential resource for basic usage.
• the example C# code shown in the winui controls gallery does not always line up with the actual code for the example
• some things are completely undocumented, e.g. the fact that a NumberBox NumberFormatter must be an INumberParser, not just an INumberFormatter2
• errors are uninformative, e.g. if you attempt to set NumberBox::NumberFormatter to an INumberFormatter2 which isn't an INumberParser, you just get 'failed to set property'
• it's hard to find the link between the style guidelines (typography, colors etc) and "for these controls, these styles exist in the theme resource". As far as I can tell, the official reference is https://github.com/microsoft/microsoft-ui-xaml/tree/master/dev/CommonStyles - if you're not already familiar with xaml and styles, it takes a while to understand how these relate to what you'll see.

Ecosystem things:

• the build-time distinction between 'packaged' and 'unpackaged' seems much more pervasive than it needs to be:
  • If I want to support .zip or .msix installation, AIUI I 'should' have two builds, two .vcxproj things, and #ifdefs in my code, and keep track of twice as many .pdb files to debug user crashes.
  • Once you dig through the source code and find out what flags need setting, it's relatively straightforward to make a single winui3 exe that works both packaged and unpackaged: https://github.com/microsoft/WindowsAppSDK/issues/2216
  • mixing these up just leads to an exit code with an hresult - no exception or log event indicating what call led to that hresult. Using visual studio's packaged app debugger also gives no more information - it just immediately exits silently
• packaged is 'recommended', but if you're not using the MS store, key logistical features are currently only available on windows 11 insider builds, and it's unclear if they will ever be available on windows 10, e.g.:
  • support for automatic updates: https://docs.microsoft.com/en-us/windows/msix/app-installer/auto-update-and-repair--overview
  • being able to replace code signing keys when CN changes (especially for non-organizational certificates): https://docs.microsoft.com/en-us/windows/msix/package/persistent-identity
• Given the libraries are only distributed as an msix/exe, distributing an 'unpackaged' app still really wants an installer; 'extract this zip and double click' isn't practical. This is added complication - though I do appreciate how easy it is to make a basic msix package with dependencies compared to msi.
• If you're a cross-platform developer that happens to be working on a windows-specific app (or a cross-platform app with platform-specific frontends), the coupling to visual studio/nuget/msbuild is an extra painful step; c++/winrt is great and feels like an attempt to engage with and attract the broader C++ community, but the windows app sdk + winui coupling to MS-specific tools feels contradictory and like a lock-in attempt. MSBuild in particular is unavoidable, due to it being the only supported way to invoke the xaml compiler. For C++, CMake is the standard - cross-platform apps and libraries can not move fully to msbuild, and integrating the two is painful.

I'm mentioning these as if I stuck with wxWidgets, 'statically link everything' is a very practical approach, avoiding all of these issues. While WinUI3 isn't the source of these problems, using WinUI3 means that they do become problems I need to address, and need to be weighed as part of 'is winui3 worth it for my app?'.

Despite all of that: I'm happy overall with the results, and would probably do it again for a hobby app, but I definitely wouldn't consider it for a larger project - or any project with multiple developers - at the moment. If I were working on a commercial C++ project with a windows GUI, I'd use Qt.

[StephenLPeters]

@ryandemopoulos FYI

[wherewhere]

Mine! Mine! Mine! APK Installer However, I use it only because it can use process. In fact, I don't like Windows App SDK at all. It write like UWP, looks like UWP. But it doesn't feel like UWP. What we need is a UWP which has the same permission and functions as WPF. Not a WPF which only looks like UWP. I want UWP back 😭.

[ryandemopoulos]

This is good timing, so thanks for starting the discussion @omikhailov -- our community call next week will talk to this a bit. We have a couple partnerships with substantial apps (Fortune 500 companies that aren't Microsoft) happening right now, but I can't share specifics due to agreements with those companies. One or perhaps both of those apps will ship this year and we'll be able to talk about them once they are public.

As mentioned, most of the inbox apps in Windows use WinUI 2 today -- one of them is very close to being converted to WinUI 3 already, and others will move to WinUI 3 over time. Tune in to the Wednesday call next week as we'll be releasing a new roadmap for the WinAppSDK and talking more about how we're prioritizing getting WinAppSDK and WinUI 3 into more industry-leading apps this year.

[wbokkers]

Xelion is using WinUI 3 for their Windows app. It's a big app. You need a Xelion account to run it, so there's nothing I can show you. https://appinstaller.xelion.com/winapp/v8/

[float34]

@ryandemopoulos

one of them is very close to being converted to WinUI 3 already, and others will move to WinUI 3 over time

Do you mean that internal Windows apps that are currently "Win32/UWP + WinUI 2" (e.g. Settings, Store, Paint, the shell) will be converted to "Win32/WPF/etc. + WinUI 3" over time? Thanks.

[JanRajnoha]

I'm currently creating cash system in WinUI 3 and sometimes it is really hard to solve problems :/ on the other hand, every time i found solution

[charlesroddie]

key logistical features are currently only available on windows 11 insider builds, and it's unclear if they will ever be available on windows 10, e.g.: support for automatic updates: https://docs.microsoft.com/en-us/windows/msix/app-installer/auto-update-and-repair--overview

Support for automatic updates has always been the key advantage of MSIX. I think this may be a misunderstanding of the confusingly worded documentation, and that the doc banner ("The following article discusses settings currently available in Windows Insider build 22415 and newer") really means that "this page applies to Windows Insider build 22415: some of these features work on Win10 but we are not telling you which ones!".

[fredemmott]

@charlesroddie thanks :D the documentation on schema versions is missing entries, and there's basically no docs on which features work on which windows versions...

I need to do some more testing, though provisionally, https://github.com/OpenKneeboard/OpenKneeboard/blob/29214c012ac95024419c858daeb38b3e43956222/autoupdate/preview.appinstaller is fine back to 19044.1288 (I don't have access to earlier version). Some notes:

• 2021 schema is not allowed
• MainBundle is allowed, but it inserts 'neutral' in to the name. ProcessorArchitecture is not supported in the 2018 schema. If you have a single msix, use MainPackage instead
• UpdateUris and RepairUris aren't allowed in this schema

[octaviordz]

Since documentation is mentioned in this thread, has that improved? I'm trying to find WinUI3 documentation without much success. I see the documentation on the API but, is there any high level documentation for example on how the layout system work, what is the designed way to compose the controls?

Thanks.

[fredemmott]

I’m still using winui 3 for my hobby project, but this is only because as a hobby project I don’t currently have the time to rewrite the UI layer.

there are many bugs - even crashes - for over a year; it seems that they are only worked on if they affect a company that is partnering with Microsoft.

Open source seems to not just be delayed but no longer even talked about, so I have no expectation that I will be able to contribute fixes.

To me it’s no longer an issue of “winui 3 has a few rough edges, mostly docs”: if you use winui 3, there’s a fair chance you’ll eventually hit a case where your app crashes, and there’s nothing you can do about it; my app currently has 2 different known crashes due to known winui 3 bugs without workarounds. Winui 3 is not suitable for real world apps unless you have a contractual relationship with Microsoft to support your use.

[wbokkers]

In App Center I can see that only 0.1 to 0.15% of the users or our Xelion app see crashes. We have 30k active users. Currently, we don't get many support tickets about crashes.

So, WinUI 3 can be successfully used in a real world app. But there is still room for improvement.

[fredemmott]

So, WinUI 3 can be successfully used in a real world app

Yeah, it depends on what features you use, and what your app does; but there isn't a way to find out if your app design is possible to do in winui 3 without crashing except by trying it and seeing if you're lucky. That - combined with known crashes in winui3 not being fixed - makes it a strong "do not recommend", even if there are some apps that don't need the features that crash.

[wbokkers]

I can almost safely assume that our app is among the most complex WinUI 3 apps available. We use almost every corner of the WinUI3 library. It's not a simple forms over data app.

[tajbender]

I’m still using winui 3 for my hobby project, but this is only because as a hobby project I don’t currently have the time to rewrite the UI layer.

Well, coming from WinForms I never used XAML before, so it was a hard time for me..

However, with some patience I've learned some patterns and I love the layout system, as I love Hot Deploy and Hot Reload. So sure, it's a lot of try & error.

But there are Open Books, published by Microsoft, and - no joke - https://www.bing.com/search?q=chatgpt can help, too! 🚀

[fredemmott]

I can almost safely assume that our app is among the most complex WinUI 3 apps available. We use almost every corner of the WinUI3 library. It's not a simple forms over data app.

The facts are that there are known crashes in WinUI3, in the issue tracker here, acknowledged by Microsoft, and not showing signs of being worked on. I'm glad your app doesn't happen to trigger them.

My meaning is not "only simple apps can be done in WinUI3" - it's "doing a complex app in WinUI3 is a risk - you might get lucky, or you might be in an unfixable hole".

[wbokkers]

I agree there's lot of rough edges and much room for improvement. But I am not just feeling lucky I didn't run into an issue. I ran into many issues... and fixed them one way or another. This is far from ideal. WinUI 3 should be stable in all circumstances and it isn't.

[llothar]

Well the sad fact is that the good old rule that a new software technology still needs 5 years to be useable and 10 years to mature are real. WinUI3 is in year 1.5 now. So we need patient to see it become bug free.

By the way, Swift-UI is almost as unuseable (more stable, but it still lacks so many features) as WinUI3 and both companies have almost unlimited money they could throw at the projects. But they know it wont help to speed things up. At least Swift-UI and UIKit is not fully interoperable in both ways. We still cannot host a good old win32 control inside a XAML.

[tajbender]

time passes, updates pass

[legistek]

First off, WinUI is based off of tech that was first released in 2012 - WinRT - so the "it takes time" excuse doesn't work. They had to reboot it twice because it was a commercial and technological failure. WinUI3 is in fact the third flavor of WinRT but so far appears to be faring no better than its predecessors. Someone at the company seems determined to keep the tech alive at all costs when all evidence is that it should've been scrapped 10 years ago.

Plus they appear to be very slow to respond to bugs, for example this one. In no other Microsoft repo that I've ever submitted a bug to have I gone a week without any contact from an official project member.

The most frustrating part is that they HAD an amazing, mature, versatile framework for commercial applications - WPF - but rather than modernize it they put it out to pasture in favor of something newer and shinier. Had half the resources spent on WinRT and its progeny been poured into modernizing WPF we'd be in an amazing place right now.

At the end of the day, one cannot escape the conclusion that third party application development for Windows is not even close to a top strategic priority. At this point they're just going through the motions, and barely doing so at that. Windows
ceded the consumer market a long time ago other than for games, and the business market will put up with LOB apps built on obsolete frameworks until the last stragglers move to the web. The big players - Office, Adobe, etc.. - who have a strong strategic interest in modern desktop apps can afford to make their own proprietary frameworks and probably would do so no matter what.

WinUI3 is strike 3. It's time to look elsewhere for solutions.