With the arrival of macOS 11.0 Big Sur and Apple’s first Silicon Macs drawing ever closer, next week I’m going to ask whether you should consider upgrading to them, and how you should prepare for that. As a prelude, this article highlights some potential issues which you could experience with third-party products running under Big Sur, and on Apple Silicon Macs.
Big Sur has all the fundamental requirements of Catalina, in terms of 64-bit only software, loss of old 32-bit QuickTime support, and its separate System and Data volumes. If you’re migrating software from before Catalina, those still apply, in some cases even more stringently, as I’ll explain. If your software relies on any 32-bit components, or needs modifications to be made to the directories at root level, then look first at running a Mojave (or earlier) Virtual Machine, which could save you a lot of trouble.
Sealed System Volume
Big Sur goes far beyond Catalina in putting the System volume out of bounds, with its new Sealed System Volume (SSV), which I’ve previewed here. When the macOS installer has done its job writing all files to the System volume, a complete hierarchy of cryptographic hashes is constructed to seal that volume, its snapshot is made, and the new system is delivered by mounting that snapshot from the read-only SIP-protected volume.
Although it is possible to configure and run Big Sur without the trappings of the SSV, doing so is likely to be experimental, and not something to try in production. Modifications to the System volume are thoroughly discouraged.
Backups on APFS
One big step forward is that Big Sur now supports making Time Machine backups to APFS volumes. This part of Big Sur is still evolving quite rapidly, but it’s clear that the structure of those backups is very different from those made to HFS+. By definition, these new backups won’t be compatible with your existing backups, stored on HFS+ volumes which can’t be moved to APFS as they rely on directory hard links.
If you use Time Machine and intend taking advantage of backing up to APFS, you’ll be starting a new backup set which isn’t backwards-compatible either, in that you won’t be able to access those backups from Catalina or earlier. This is an important consideration for those who want to be able to revert to an earlier version of macOS if they encounter problems with Big Sur: upgrading looks like a one-way trip for most users.
To support the new SSV and backing up to APFS, there appear to have been changes in APFS, and possibly elsewhere, which make dual-booting with an older version of macOS, even Catalina, a precarious situation. There have been several reports of problems when trying to run Big Sur and older macOS on the same Mac, even when one of them is installed on an external disk. This may improve with the 11.0 release, but it’s probably best not to rely on turning any Mac into a dual-boot system. If you need to run older versions of macOS on the same Mac, prefer to use a Virtual Machine.
This doesn’t apply to Apple Silicon systems, of course, which can’t run older versions of macOS, unless someone comes along with an emulation solution.
macOS version numbering
Apple has introduced an ingenious feature to try to ease the problem of software expecting to be running on macOS 10.16 rather than 11.0: anything built using previous versions of Xcode is told that it’s running on 10.16. Despite this, there will still be problems with some apps misinterpreting macOS version numbers, particularly if they’ve been hastily ported to a new development system which does report that it’s 11.0.
I’ve explained how this impacts scripts and scripting in this article.
The most obvious changes in Big Sur are in its interface. Although apps which play nice and use Apple’s interface libraries such as AppKit should cope with that well, any that use custom elements or ignore what’s supported in the macOS SDK as much as possible may suffer problems. Most of those should be cosmetic, but some may impact on function. I haven’t seen any examples yet, but once many users are opening older apps, I suspect that some will run into trouble.
Mach absolute time (Apple Silicon only)
Buried rather deeper in the small print is an important change in the most fundamental and high-resolution clock in the Mac: in Intel Macs, this uniformly ticks at an interval of one nanosecond, but that won’t be the case with Apple Silicon Macs. Although software should never have assumed the tick interval was constant, and there is a straightforward way to compensate for differences, I suspect that some software will be caught out by this, which equally affects old software which has been converted by Rosetta 2. This article explains.
Vector instructions (Apple Silicon only)
The built-in Rosetta 2 instruction translation feature on Apple Silicon Macs doesn’t work for specialist vector features including Intel SSE, AVX, AVX2, or AVX512 units. If you use high-end software which could use those, check with the vendor before committing to using an Apple Silicon Mac. At worst, your expensive software may not run at all on its ARM processors.
Mix and match architecture (Apple Silicon only)
Rosetta 2 appears simply amazing, but it also has some wrinkles which can catch you out if you try mixing and matching Intel and Apple Silicon components, something that many of us will be doing in the first months after the release of Apple Silicon Macs.
All the code run by an app should be built for the same architecture. If you’re running an app which requires Intel plugins, then either use the Intel-only version of that app, or set it (in the Finder) to open its Intel code translated using Rosetta. That not only ensures that all those plugins remain usable, but minimises any risk of delays which could occur translating them as they are required. Wherever you can, try to use single-architecture tool chains.
As I have explained, tuning tool chains for performance is going to be more complex until most software is available in Universal form.
Next week, I will try to set these concerns within clear recommendations for those considering upgrading.