Those of us who’ve written that Apple intends to switch processors in Macs, from Intel to those licensed from ARM, finally got it right: in the opening Keynote of this year’s delayed and remote WWDC, Apple confirmed that it intends to ship its first Mac with these new processors before the end of this year. This article looks past the numerous ‘hot takes’ of the last day or so at what this really means for users, developers and sysadmins.

Apple Silicon

These aren’t ARM-powered Macs any more than iPads or iPhones are: officially they use Apple Silicon, a distinction which is more than a matter of branding. Although the CPU cores are at their heart, much of Apple’s success with them is the result of integrating them into a complete System on a Chip (SoC), in which Apple has invested many years of engineering effort and money. Had it not done so, none of these products would have succeeded. If it’s any consolation, in code Apple does refer to Apple Silicon architecture as arm64, as opposed to Intel’s x86_64.

Apple has also made it clear that this switch isn’t a recent project, but the result of years of work. Rumours that go back several years weren’t actually wrong, they were just ahead of their time. Over the next couple of years, Apple intends to replace all its current models with a new range containing Apple Silicon. But macOS will continue to support current and future Intel models for the foreseeable future.

Translation and universal binaries

Apple explains to developers how it intends this to happen. To ensure that all Macs can run the widest possible range of software, and support many peripherals, developers are starting to build universal binaries, which contain native code for both Intel and Apple Silicon architectures.

Until an app reaches that, Big Sur provides Rosetta 2, a built-in code translation system, to enable Intel code to run on Apple Silicon Macs; there’s no facility to do the reverse, and run Apple Silicon code on Intel processors. Rosetta 2 does its work as soon as it can: when you install an Intel-only app on an Apple Silicon Mac, Rosetta 2 translates all its code to run native on that architecture. Some code, typically that using ‘just in time’ compilation, has to be translated immediately before it’s run, but for best performance that’s kept to a minimum.

One problem which could have arisen with this is when you run an app which is a universal binary which you want to load Intel-only code modules. Rosetta 2 doesn’t try to mix and match, so Finder provides the option of forcing the universal binary to run in Intel mode (with translation) so that it can still load Intel code when running.

Kernel extensions

There’s another important exception to Rosetta 2 translation: because kernel extensions run intimately with the kernel, they can’t be translated to enable an Intel KEXT to run with the ARM64 binary on an Apple Silicon Mac. I had been expecting Big Sur to block third-party kernel extensions altogether, but I was wrong. It does make them more slightly complex, but should enable you to continue their use until they’re replaced by a newer System Extension, DriverKit extension or similar.

When you’re running Big Sur on an Intel Mac, you can install third-party kernel extensions built for Intel Macs. Installation is essentially the same as in Catalina, and I’m hoping it’s going to prove more reliable than it has been.

To install a third-party kernel extension on an Apple Silicon Mac, you’ll need a version of that KEXT which has been built specifically to run native on the new architecture, and requires a one-time process of enabling third-party KEXTs in Recovery Mode. Once you’ve enabled that, the installation process is essentially the same as on an Intel Mac.

Rosetta 2 also can’t translate newer specialist instructions, particularly AVX and later vector instructions. Any software which relies on those will need to check whether they’re supported by the hardware it’s running on.

Other operating systems

As I suggested, Apple Silicon Macs offer virtualisation, so will be able to run Linux and other operating systems alongside macOS. What Apple hasn’t mentioned yet, as far as I’m aware, is how users might run Windows, which has of course already been built for ARM processors in Microsoft’s own Surface Pro X systems. Parallels has been credited as working with Apple to bring unspecified products or features to Big Sur, but details of exactly what’s coming haven’t been made clear yet.

Internal changes

The most significant structural change inside Big Sur is that the boot System volume isn’t protected by SIP any more, but is a cryptographically signed APFS snapshot. You can’t just disable SIP and mount the System volume for writing, and there’s no way to boot a live System volume which you can write to. Instead, if you need to make changes to the contents of the macOS System volume, you’ll need to disable its authentication in Recovery Mode, mount it, make any changes, create an APFS snapshot, then use that to boot from. Step-by-step instructions for doing this will no doubt emerge in coming days.

I had expected OpenGL and OpenCL to be casualties in Big Sur and on Apple Silicon Macs, but Apple has confirmed that they will still be supported, even though they remain “deprecated”.

Version numbering

There’s been some concern expressed at Apple designating Big Sur as macOS 11, which could break both code and scripts which rely on its existing 10.x numbering scheme. Apple has anticipated this: although Big Sur advertises itself as macOS 11, it’s generally listed internally as being 10.16, so if your script or code relies on that, it should be safe.

Outcome

After all this information about Apple’s huge long-term investment in Macs and macOS, there are still many who fear for the Mac’s future. Some claim that, because Apple Silicon Macs (not Intel models) will be able to run iOS and iPadOS apps natively, this spells doom for software written specifically for macOS, and that our Macs are being taken over by iOS and its plethora of apps.

Just because Macs have been able to run Windows using Boot Camp, or in a virtual machine, or Linux, that hasn’t resulted in those alien operating systems, or their apps, taking over our Macs. For those concerned with cross-platform integration, the one mention of Microsoft was to announce that its Office 365 apps have already been rebuilt as universal binaries and run very well indeed on pre-production Apple Silicon Macs.

This change in processors only serves to reinforce the Mac’s position at the top of Apple’s products. It’s the only hardware which will be able to run apps developed for macOS, iPadOS and iOS. Native macOS apps will continue to have full access to the far greater frameworks which support macOS, much of which has no equivalent on its other operating systems. Big Sur has the Finder and command line, and a great deal more that isn’t available to apps running on devices. When an existing iOS app can diagnose Time Machine problems or make best use of a 27-inch display, it might pose more of a threat to native macOS apps.

Corrected 25 June 2020 to describe KEXT installation accurately, thanks to @afrojer for pointing out my previous misunderstanding.