Humans develop habits even before birth. Changing them is a challenge even for the mighty Apple, which is now trying to transform macOS update habits of millions of Mac users. While some of us are queueing at the servers, willing them to deliver the latest update ever quicker, many leave it days, weeks or even longer before trusting a new update. So how is Apple going about this?

With Big Sur’s novel Sealed System Volume (SSV), Apple re-engineered its software updates completely. Not that this was strictly necessary: it could have chosen to continue providing updates built on scripts and packages, with tools to generate the Merkel tree of hashes and seal the bootable snapshot. But those wouldn’t just have made user updating as easy as it has been in the past, they would also have encouraged abuse.

This is but one part of Apple’s sustained campaign to persuade macOS users to behave more like iOS users, by updating as soon as possible, so that almost all Big Sur users will be running just one version, the latest. In the past, Apple has provided every opportunity to delay updating, however flimsy our rationale might be. We say we’ll give it a fortnight and then, if the update hasn’t caused any major problems, we’ll probably install it later. Sometimes those weeks grow in number, and we fall a couple of updates behind.

With a bit more careful procrastination we can leave updates for months, by which time we might prefer a Combo updater. As we’ve seen, Big Sur denies us those options. With no delta or Combo updaters on offer, we must either use Software Update or we have to download a full installer and run the risk of it ignoring our existing Data volume. Of course Apple is thinking about providing standalone updaters again, but has never had any serious intention to do so. It wants us all to trust our Macs to Software Update, soon after it releases each update too.

If the stick is having to use a full macOS installer rather than Software Update, the carrot is even better-directed: just look at the security release notes. For 11.3, the list of 55 fixed vulnerabilities includes one gem reported by Cedric Owens, one of two for which “Apple is aware of a report that this issue may have been actively exploited.” For 11.3.1, our collective groan at yet another hefty update so soon was suppressed when both its fixes became essential with another declaration that “Apple is aware of a report that this issue may have been actively exploited.” In those fourteen words, Apple transformed what might have been a most unwelcome update into a pressing need.

This isn’t to imply that any of this is exaggerated or untrue, but all Apple has to do to transform an update from being unwanted and ignored by many is to add those fourteen words to its security release notes. Immediately, the independent Mac security community is encouraging us all to update as a matter of urgency – as I do too. Apple has mastered the mass psychology of software updates.

Neither are we encouraged to run older versions of macOS, as becomes obvious when you try to install a previous release of Big Sur on an external disk connected to an M1 Mac.

Since well before Christmas, I’ve spent an indecent amount of time trying to get external bootable disks to work reliably with my M1 Macs. Much of that could have been saved had I been able to read between the lines of Apple’s February revision of the Platform Security Guide, but even then it’s more about what’s unwritten there than what Apple chooses to explain.

One consistent phenomenon over those five months has been my abject failure to successfully install any older version of Big Sur on an external disk connected to an M1 Mac. With the wisdom of hindsight what I’ve been attempting has been doomed from the start: towards the end of installing macOS, a Mac has to start up in the new system, to complete and configure the new installation.

But, as I now know, to boot in a version of macOS which is older than that on the internal SSD, you have to enter RecoveryOS and change that disk’s security settings to Reduced Security, something you can only do when there’s a bootable volume group installed on that disk. Thus the M1’s boot security policy prevents it from successfully installing any older version of macOS on an external bootable disk. Is that mere accident?

With these carrots, sticks and misbehaving installers, Apple is manoeuvring us into updating early and often, just like most of us already do with our iPhones. Is that so bad with macOS?

Provided that Apple keeps its side of the deal, no. Its obligations are to ensure that it doesn’t release any bad updates which leave users piecing together the remains of their systems, that updates not only address security vulnerabilities but the sea of other bugs which trouble us daily, and that updates don’t steal hours in the day.

It’s the last of those which brings most conflict at present, particularly with M1 Macs. Not only is the deadweight in their every macOS update larger, at around 3 GB for an M1, but, unlike Big Sur updates for Intel Macs, around 900 MB of that has to be freshly downloaded from Apple’s servers each time. Even running a local Content Caching Server, every M1 Mac has to download that same 900 MB direct. If you’re hoping that’s just a bug that will be fixed, then you’re likely to be disappointed: there’s every indication that’s a feature, and one which coincidentally makes it far harder to reverse engineer one of these new secure updates.

However much we call on Apple to reinstate standalone installers, enable us to install older versions of macOS on M1 Macs, or make these updates smaller, I don’t see Apple changing at all. They’re not shortcomings or bugs, but features of our new update habit.