If there’s one thing that Apple takes great corporate pride in, it’s the high rate of adoption of new versions of its operating systems. Considering that they’re all free updates, this may seem paradoxical, because the number of users upgrading doesn’t affect anyone’s bottom line. However, it does save cost in support, and ensures that everyone is facing the same security risks.

In this context, Catalina was an oddity. From the outset, Apple’s abandonment of 32-bit support was inevitably going to leave many users unable to upgrade, unless 10.15 had included some form of compatibility mode. Another change which was bound to cause problems was the enforcement of hardening and notarization. Only last week I looked at buying the superb graphing and analysis software Igor Pro, which I last used many years ago. Because it supports extensions containing executable code, it remains essentially incompatible with Catalina. I’ve also been contacted by a developer of another major software system which has similar problems with app extensions, who’s still struggling to meet hardening and notarization requirements.

Catalina also has serious bugs affecting vital features, such as the Mail app and Time Machine. I continue to get frantic messages and comments from many who can’t get Time Machine to make any backups at all, and the latest update doesn’t appear to have brought any relief. For many, upgrading to 10.15 is still too much of a gamble. When they realise how immature the replacement apps for iTunes are, even more users get cold feet.

Apple seems unable to recognise or understand this, though. Instead of putting more engineering effort into addressing these problems, its response in Security Update 2020-003 is to “deprecate” the feature which let 10.13 and 10.14 users turn off badge reminders of the 10.15 upgrade. By Apple’s favourite euphemism deprecate it here means disable, remove, excise, or block, rather than just frown upon.

At this stage, nagging those still running older versions of macOS is missing their point: sorry, Apple, but for good reasons we’re not prepared to lose our 32-bit apps, or those which don’t fit your simplistic security model, and Catalina’s failure to match the features and reliability of previous versions of macOS.

Then in a month’s time, Apple looks set to pose us all with the next set of hurdles to upgrading, as it starts releasing betas of 10.16. Two things we know about the next major release of its flagship operating system are that third-party kernel extensions will be blocked, and we’re going to find it hard or impossible to turn off software updates.

In case you hadn’t noticed, Catalina has been nagging us about the removal of kernel extensions for some time now. It’s one of the reasons why I try to avoid restarting my Mac for as long as possible, because it keeps telling me the same old messages. Kernel extensions are being replaced with System Extensions, moving from KEXTs to SEXTs, but those and other substitutes have been poorly introduced by Apple. Many users won’t be able to upgrade to 10.16 because of their reliance on KEXTs which don’t yet have acceptable substitutes. Just as with Catalina, this leaves even more users behind, being irritated by this repeated nagging.

Software updates and upgrades should be a user’s choice, not something forced upon them. Now that we’re getting more detailed release notes, as well as long lists of the vulnerabilities which are addressed, those should be sufficient to lure every user who can update or upgrade to press ahead immediately. Instead, many who have no other reason for holding back, feel they must do so until they can be confident that the new version doesn’t break anything important.

In that, the 10.15.5 update was a prime example: a new bug in part of the APFS file system which supports the creation of bootable copies of the startup Volume Group. This stopped widely used utilities like Carbon Copy Cloner and SuperDuper! from working, although their developers have since found and implemented workarounds. The reason that this bug wasn’t detected until the release of 10.15.5 is that the system call which fails has persistently returned the code for success, so deceiving developers into believing that nothing was wrong.

Given Apple’s exemplary support for diversity among its employees, and its strong defence of the user’s right to privacy, it seems strange that it feels it necessary to goad users into compliance and conformity when it comes to their choice of macOS version and when/whether to update or upgrade. At a time when we all need to show understanding of others’ needs and points of view, it’s time for Apple to tolerate users’ problems and choices better. Most of all, to make 10.16 a thorough improvement so that we choose to use it.