Both macOS and Windows can translate existing legacy x86 code into native ARM64 code. This allows apps written for Intel Macs to run on Apple Silicon (using ...
It’s mainly a difference in philosophy. Apple has long seen translation/compatibility layers as exclusively transitional rather than something that can be leaned on indefinitely, because even the best of that kind of technology comes at a cost to performance and efficiency, not to mention if you let it hang around for too long you can end up with multiple compatibility modes in play which compounds those losses.
As such, they push devs to release updated binaries that run natively. This isn’t a difficult for the vast majority of Apple platform apps, usually involving little more than ticking a new arch checkbox in Xcode thanks to AppKit/UIKit long having been architecture-agnostic. The software that suffers tends to be cross platform, where major assumptions have been made (“I don’t need to think about anything but x86” and similar).
It’s mainly a difference in philosophy. Apple has long seen translation/compatibility layers as exclusively transitional rather than something that can be leaned on indefinitely, because even the best of that kind of technology comes at a cost to performance and efficiency, not to mention if you let it hang around for too long you can end up with multiple compatibility modes in play which compounds those losses.
As such, they push devs to release updated binaries that run natively. This isn’t a difficult for the vast majority of Apple platform apps, usually involving little more than ticking a new arch checkbox in Xcode thanks to AppKit/UIKit long having been architecture-agnostic. The software that suffers tends to be cross platform, where major assumptions have been made (“I don’t need to think about anything but x86” and similar).