Not necessarily even for managed languages. Sure, you can in theory just package an ARM runtime, but the devil is in the details. For example, it's typical tha

Not necessarily even for managed languages. Sure, you can in theory just package an ARM runtime, but the devil is in the details. For example, it's typical that packaging tools only build packages for the platform they run on. So if you run the tool on Windows Intel, you get packages for Windows Intel. Want ARM? You need to run it on Windows ARM. Don't have such a machine? Tough cookies. This is one of the problems that motivated me to write Hydraulic Conveyor, and so it can build packages for every platform portably including Windows Intel and ARM regardless of what OS or CPU you run it on. It knows how to download all the different runtimes for all the different OS/CPU combinations and make and sign all the packages in parallel, without any native tooling. It knows how to strip out native binaries that appear in managed dependencies, but don't match the target. It makes download pages that detect what CPU you have (on Chrome, Safari lies unfortunately), or for Windows an installer that detects the user's CPU and downloads/installs the right arch for the user. So it handles all these details and lets you release for hardware you don't have. But that's a fairly unique party trick. For every other system you're going to be reliant on multi-platform CI, which may or may not support every target (ARM Macs took a long time to come to GitHub Actions), and in which adding extra platforms increases the cost of every build - sometimes by a lot! Apple relied not only on Rosetta but also their whole fat binary infrastructure, and they have sticks like notarization and carrots like the App Store to encourage devs to do the work. Also Mac apps tend to be well maintained and gaming is not so common. MS don't have the same advantages, so apps will presumably be running in emulation for a lot longer and have more compatibility warts.