macOS, iOS and Android have built in solutions for years, to just publish Packages with multiple architectures and the system executes the appropriate binary.
I have mostly learned to live with it, but I certainly do not like it.
Or did I mix up something?
My prediction: there won't be any ARM builds for most of the applications for the next 10 years. It must become super easy, like in Xcode or Android studio, where you just tick a check-box for another architecture and it gets build and bundled automatically.
Honestly, I've become more appreciative over the years how on Macs everything is a .app in the Applications folder instead of being scattered across the OS, and if you want to back them up or uninstall them you can just move them around like files. I was hoping just a little that with Microsoft's sandboxing efforts we'd get a sandboxed .app-like file for Windows, but no luck.
The biggest problem, I think, that Microsoft has is that if I'm a company, there is literally almost zero reason to support ARM. It's technically complex, the userbase is tiny, the performance is slow on the few computers that have it, and those users don't technically need it for your app to run. So why bother?
It's almost the same level of asking a company to support Linux machines. There are probably more Linux machines floating around than Windows on ARM. It would almost make more financial sense to port your app to MacOS than Windows on ARM if you do cost/benefit.
Every packaging framework I used on windows introduced it's own problems so far. It can take literally hundrets (!) of development hours until your Installshied, MSI or MSIX package works on all your customer systems. If you have a big user base it can happen that customer support spends thousands of hours to anlyse and fix installer issues.
No, it's more than that. It's a mix-and-match of x86, and arm binary code, so you don't have to keep a two separate copies of every binary.
x64 or x86 Windows will still require the old binary format. So you once again have to build and deploy two versions.
That's what a fat binary is. Multiple architectures supported by a single binary. In the simplest case, simply by including both, though some de duplication of data segments can be managed.
Not just duplication, but they want to make the gigatons of binary only software, and libraries available for WinARM without their authors doing a thing.
Most commercial companies would simply not care enough about WinARM to move a finger.