Anything related to WinUI, WinAppSDK, CsWinRT, C++/WinRT is a sea of bugs, broken tooling, and unfulfilled promises, that no one should bother with.
Easily confirmed by going into their public repositories over at Github, or community session recordings over at YouTube.
For those using .NET, keep using Windows Forms or WPF, or reach out to Avalonia and Uno.
For those using C++, the aging MFC has much better tooling as incredible as it sounds, or use instead VCL/Firemonkey (C++ Builder), Qt, wxWidgets,....
For anything else, whatever bindings are available on top of plain Win32.
I'm not a traditional app dev on Windows though, so I'm likely missing something. For those of you who are more familiar, what about this are you excited about?
Unlike regular Windows SDK, which lets you make use of the functionality provided by the OS, the WindowsAppSDK is entirely separate from the OS and requires the installation of a separate runtime on the user's machine. It also requires installing nuget packages on your machine to use it so good luck if you'd rather use straight CMake instead of Visual Studio.
As far as I can tell, there's no backwards or forwards compatibility, so the end user has to install the specific version of the SDK your app uses, or you need to bundle all the hundreds of DLLs with your app yourself.
A sane person might ask why not just use Qt (smaller distribution!) or Electron (about the same size) at that point, since they're cross platform and you can easily get fluent themes that look the same as WinUI3?
As far as I can tell there's no sane negative answer to this question. It's not like your app's "fluent theme" will be updated alongside the OS, it's no different from Qt or Electron in this regard.
There's no reason to do "native" windows development anymore, unless you mean using raw Win32 with no dark theme or a custom UI built on Direct2D/3D/Write. And if you are doing that, there's absolutely 0 reason to use this CLI.
Couple of months ago I used some shady C# SDK to build an implementation that interfaces with a very specific hardware component. My only option was Windows Forms, which I don't love very much but I have worked with extensibility in the past.
I did not have a lot of faith, because of how weird it feels to ask an LLM to work with a design.cs file, but what I did was just sketch all the design and let Claude do the logic with certain specification on how I wanted to corral the code... App was flawless in about 2 days of work. It's in production now with zero faults.
So, hard to now give this a shot, I already got my go-to tool. Even for something has arcane and obscure as Winforms.
(ex windows dev)