I bet that Apple won't rely that much on emulation this time (like back when switching from PPC to x86), instead either require app-store apps to be uploaded as LLVM bitcode, or upload fat-binaries with ARM and x86 machine code (NextStep aka OSX did this already a quarter century ago), or maybe even statically translate x86 machine code to ARM on the app store "server side".
Most command line code installed through homebrew is compiled on the user machine anyway, which leaves the closed-source and legacy UI applications not distributed through the app store (but by the time Macs switch to ARM, OSX probably will forbid to run those anyway).
> I bet that Apple won't rely that much on emulation this time (like back when switching from PPC to x86), instead either require app-store apps to be uploaded as LLVM bitcode
LLVM bitcode remains architecture-specific (if not platform-specific), you can not just recompile x86 bitcode for ARM.
> or upload fat-binaries with ARM and x86 machine code (NextStep aka OSX did this already a quarter century ago)
That doesn't obviate the need for a transition compatibility layer, complex software can take years to port to different architectures.
> I bet that Apple won't rely that much on emulation this time (like back when switching from PPC to x86), instead either require app-store apps to be uploaded as LLVM bitcode, or […]
LLVM bitcode is platform specific. It deliberately isn't designed to be portable.
Most command line code installed through homebrew is compiled on the user machine anyway, which leaves the closed-source and legacy UI applications not distributed through the app store (but by the time Macs switch to ARM, OSX probably will forbid to run those anyway).