Does that mean that all of the OS code has been recompiled for Apple Silicon / ARM? And if so, does that mean Big Sur has two binaries: 1 for ARM (new M1 Macs) and 1 for Intel (existing supported Mac devices) and there is a flag at boot-time to determine which mode it runs in?
Yes, of course.
> two binaries
Yes and no. Technically, they are single binaries. The Mach-O binary format has supported the concept of a "fat binary" at least since NeXTStep was ported to Intel. So it's a single file, a single "binary", but with different sections for different architectures. Kernel selects the right bits of the binary to executer when loading.
> flag at boot-time
Nope. On an ARM Mac, ARM code will run natively, Intel code will run via Rosetta. On an Intel code, Intel code runs natively and ARM code does not run. This is done transparently for each binary.
I think that’s quite a corner-case.
Not at all; did all the time when the PowerPC to Intel transition happened.
If you have an Intel Mac and wanted to use your universal apps on a friend’s M1 Mac mini with your operating system configured the way you like it, that's by far the easiest way to go.
I upgrade to the universal versions of Affinity Photo, Designer and Publisher earlier today; if I had to do something complex and could use an M1 Mac, that's exactly what I'd do.
Oddly, the imac is long gone, but the mini can still run ubuntu, and is still (somewhat) useful for testing bigendian bugs. It's slower than a raspberry pi of a few years back.
The operating system can on both M1 and Intel Macs; therefore, the OS has binaries for both.
Wouldn't be much of an operating system if the frameworks and APIs weren't available for applications regardless of which architecture they're running on.
I can understand apps having both, because the app needs to run on M1 or intel. But having both OS binaries is just dead disk space.
$ file /usr/bin/ssh
/usr/bin/ssh: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64e]
$ file /Applications/Numbers.app/Contents/MacOS/Numbers
/Applications/Numbers.app/Contents/MacOS/Numbers: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
Remember that all of the resources—images, text, icons, etc.—are shared between the Intel and ARM binaries.
There are a few use cases:
• For troubleshooting, you can have one external hard drive/SSD that can boot both Intel and M1 Macs. This is very handy; this was pretty common back in the PowerPC to Intel days.
• Same thing with running certain apps. You're doing some video rendering on an Intel Mac. Your buddy has an M1 Mac. You can boot his Mac with your external drive containing your Big Sur and your apps and you'll get the 3x speed up on your renders by using their M1 Mac mini or whatever. Back in the day, you could put an Intel Mac into Target Disk Mode where it would act as an external hard drive and boot a PowerPC from it.
• When Intel Mac users running Big Sur buy M1 Macs, they can use Apple's Migration Assistant which will transfer all of their settings, apps, etc. from the Intel Mac to the M1 Mac. No need to re-install the apps—they'll just work on the M1 Mac. The Universal apps will run natively and the Intel-only apps will run using Rosetta 2.
These Universal apps (or fat binaries as they were known back in the day, going back to NeXTStep in 1989 or 1990) aren't just a Mac-thing. When Apple transitioned iOS from 32-bit ARM to 64-bit ARM, apps contained the binaries for both. They later updated the OS to only download the version for your particular device, which made sense, since iOS devices then had far less storage than today's devices have.
- again, yes it would make sense to have this if you're booting from an external drive. Should be optional to have both binaries though.
- yes, the apps themselves will have binaries for both. That makes sense to me since you want one download link for an app and a lot of users don't want to think about what kind of mac they have.
the OS update tool should be smart enough to just get the OS binaries I need. Unless it's some kind of external boot disk like you mentioned, but that seems like a special case to me.
Drives were much smaller and slower back then; getting rid of a few megabytes of unused across a bunch of apps could make a difference then.
The first Intel Mac mini in 2006 [1] started with a 60GB, 5400 RPM hard drive, so yeah optimizing space was a big deal back then.
There will come a time when macOS will only be updated for M1 Macs and there won't be a need to ship Intel code any longer. But that's at least 3-4 years away.
[1]: https://everymac.com/systems/apple/mac_mini/specs/mac_mini_c...