It’ll be so tempting to join Apple’s public beta-testing programme and try out macOS 11 Big Sur, won’t it? Not only will it give you a better idea of what’s coming later this year, but maybe it will help you prepare for it now. And when you’re chatting with other Mac users, it’ll put you well ahead of the pack.
In a word: don’t. Well, at least not unless you have thought this out more carefully.
I learned my lesson many years ago when a friend, the great Mac developer Patrick Buckland, was working on some disk security and encryption software for his publishers Cassady and Greene. Patrick developed the wonderful and highly-addictive game Crystal Quest, and I had taken for granted getting access to early releases.
At that time, I had but a single Mac II, on which I developed commercial software for the design and manufacture of sails assembled from panels cut from sheets using ultra-large format laser cutters. I installed this exciting beta release, and it not only encrypted my single internal 40 MB hard disk, but locked me out of my Mac completely. For a couple of hours, I was beside myself, until I managed to contact Patrick again. Thankfully there was a simple workaround, as it was still a beta, which involved a large paperclip and the keyboard. In a few seconds, my Mac II was back to normal, and I was able to get on with my work.
Last year, many of those who bravely/foolishly tested Catalina had their iCloud accounts thrown into disarray for months. A few had their Macs bricked to the point where they needed to be returned to an Apple Service Provider, and some of those required replacement logic boards.
This week, Apple released Big Sur beta 2 to developers; it has promised an initial public beta-release later this month, perhaps with the third developer beta. I haven’t heard the same tales of horror for Big Sur as we had last year, but there are still strange things that happen, such as System volumes which more than double in size, and apps that crash and burn horribly.
Although I hate to rain on anyone’s parade, or spoil your excitement at the new, my golden rules for beta-testing system software this year are:
- Only ever install beta versions of macOS or any software which works at a system level on a separate Mac, which you don’t need for anything else, and could do without for a week or two if something serious goes wrong.
- Avoid installing on a Mac which could readily get bricked, such as those with T2 chips, unless you’re prepared for them to go away for a new logic board and all that causes. And make sure that they’re covered by AppleCare, or disposable.
- By all means dual-boot your testing system, but don’t expect its release version of macOS to work properly, and don’t rely on that version of macOS to make Time Machine backups, which may well break because of the beta macOS and its support for backups on APFS volumes.
- If you’re going to try dual-booting from a single disk, you’ll almost certainly going to need to install the beta into its own APFS container. I explain this below.
- Installing the beta in a Virtual Machine can be much safer if it’s possible, but may not work at all, may behave differently, and will be dog slow. You still don’t really want to try this on a production machine, though.
- Remember that a beta is for trying out and testing. Never expect to get anything useful done with it.
- Some betas are lemons. If you start sucking one and it’s clearly going to make trouble, avoid using it until the next beta is available. That will spare you a lot of pain and grief, and anxiety over what will hopefully be fixed next time around.
- When you do encounter problems, please report them to Apple using Feedback Assistant. After all, that’s why you’re testing the beta.
Although Big Sur doesn’t change the basic volume layout introduced in Catalina, with System and Data volumes set in a Volume Group, the Big Sur System volume is a very different beast from Catalina’s. As I’ve explained, this is now a Signed System Volume. Getting a bootable Big Sur system to co-exist in the same APFS container as a Catalina bootable system is therefore difficult if not impossible. If you want to boot from both Big Sur beta and another version of macOS on the same disk, the safest way to achieve that is to divide the disk into two or more APFS containers, and install each bootable system in its own container, as I have previously recommended.
The snag with using separate containers is that they can’t share free space, unlike volumes. This means committing the different systems to set container sizes, which requires careful planning to allocate sufficient space to each. And, if you’re pushed for free space, I’m afraid that Big Sur betas can be much larger than Catalina, particularly if you want to install a beta-release of Xcode. If you’re tight for space, you could easily find updates tricky or impossible.
One important myth to bust is that it’s safer to join a beta-test programme later, as most of the bugs will be fixed by then. Developers like Apple can introduce serious bugs even in very late betas (sometimes in the final release), and it’s quite common for some quite radical features to be rolled out during the course of beta-testing. Just because it says that it’s beta 4 doesn’t mean that its risk is any less than the very first beta. If you want to reduce risk, follow the steps above, or wait until it’s released.
One thing that betas are excellent for is refreshing your practical skills at system first aid. If it’s a while since you last reset an SMC, or used remote Recovery mode, this may be a chance to remind yourself just what to do. If you support Macs for a living, look on it as being continuing professional development, a first aid refresher with real casualties. If you can’t face the blood and guts, then betas are not for you.
To paraphrase the Latin, caveat tester.