Comment by WorldMaker
5 hours ago
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.
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.