[sirwhinesalot]

For those unaware, the current recommended way to develop "native" apps for Windows is to use WinUI3, distributed with the WindowsAppSDK.

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.

[WorldMaker]

WindowsAppSDK (and its direct predecessor) was installed only by the OS in Windows 8 and early Windows 10 and everybody hated the OS updating it and needing to know things like which specific Windows 10 update a user was on to access features. It's a mess either way it is installed.

> 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?

The "good news" about this tool is that it is partly for making it easier to use WinUI3 from Electron, so that you can have both large distributions at the same time.

[sirwhinesalot]

I remember the problems with the WinRT APIs being tied to specific Windows versions (still are, just a smaller surface area, so less of an issue). With the old service pack model it wouldn't be an issue but with constant OS releases it was too much churn.

I thought they had solved the worst problem with WinUI2, a bit like the compatibility library in Android, so you only had to bundle the more "volatile" bits while still delegating most things to the OS.

But then they went and threw all that out the windows (pun intended) with WinUI3 which even has its own separate implementation of DirectWrite for some god forsaken reason.

Unlike the DirectX redistributables of old it's not even backwards compatible so you can't tell people "just download the WinAppSDK runtime", they have to install the specific version you used when developing your app.

You get that download "for free" if you use a .appx, but with a regular installer you're on your own. Even the way apps link to the WindowsAppSDK is a mess with a weird bootstrapping process.

Not worth the headache.

[WorldMaker]

> own separate implementation of DirectWrite for some god forsaken reason.

That reason I sort of understand: The Cold War that DirectX can't be bothered to support WinRT directly is fascinating from outside, and also just really, really stupid. DirectX is ancient COM. WinRT is essentially modern COM 3.0. But if DirectX supported WinRT's version of COM then "Oh No, those idiot and dirty C# and JS developers could use it directly" and where would the games industry be without excuses to force college graduates to use only the one true C++ like Stroustrup intended? /facepalm

For a library called DirectX they seem to really love being IndirectX. Someone in the Windows Division should have forced them onto the right path sooner, but Windows is too busy being in either the Azure or AI divisions these days to actually care about being a consistent OS and DirectX slipped into being protected by Xbox in ways that are backwards to how things were meant to work. (Xbox was supposed to be the way to encourage more software developed with DirectX not to protect more software developers from using DirectX directly.) That xkcd comic of Microsoft being a bunch of disconnected orgs in a Mexican standoff seems to apply here (directly).

[ptx]

> Win32 with no dark theme

Couldn't this "dark theme" stuff be mapped onto the user-configurable Win32 color schemes that have been there since the beginning? Did Microsoft break it in Windows 11?

[sirwhinesalot]

If you use classic unstyled Win32 controls (Windows 95-2000 style) then you can do that. If you use uxthemed Win32 controls (Windows XP onwards) then there's no official dark theme support.

[jxdxbx]

WebView on Windows is pretty good, and Chromium-based, so I think that something like Tauri is preferable to Electron.