In the last few days, Apple’s support for old versions of its operating systems has become controversial, as some have realised that it’s no longer providing security updates to iOS 14. The official statement on that support is apparently glossed over briefly in this support note, where Apple refers to an option allowing the user “to choose between updating to the latest version of iOS or iPadOS 15 as soon as it’s released, or continuing on iOS or iPadOS 14 while still getting important security updates for a period of time.” Just how long then is that “period of time”?

For macOS, Apple’s longstanding practice is:

• to provide full software bug fixes and security updates until the release of the next major version;
• to provide security updates only until the release of the (next+2) major version;
• to provide no further bug fixes or security updates thereafter.

So at present:

• macOS 12.x Monterey is fully supported, and due its next routine update next week;
• macOS 11.x Big Sur and 10.15.x Catalina receive security updates only;
• macOS 10.14.x Mojave and earlier are unsupported.

Although this is generally accepted as Apple’s practice, I’ve been unable to find any official Apple document which states that, so there’s no formal commitment, even something as vague as that for iOS 14.

So why doesn’t a vast and enormously rich company like Apple want to commit itself more formally? Isn’t this just a way of saving costs, and forcing users to upgrade to the current version?

What follows isn’t any defence of Apple’s position, but I hope goes some way to understanding why it won’t make a formal commitment unless it really has to. It’s important to remember, in this context, that Apple already has formal commitments to supporting its hardware products, for periods based on seven years, although those vary according to the jurisdiction and other local laws.

Supporting hardware, whether it’s computers or cars, is fairly well-defined, in that a manufacturer is obliged to repair or replace a defective item for a period normally specified by law, and to be able to repair it using spare parts for a further period before it’s declared obsolete. This rewards manufacturers for quality, in that better products last longer before they might need repair, so it’s fundamentally the manufacturer’s decision how they mitigate the cost of hardware support.

Supporting software is comparatively ill-defined, and its cost is potentially unlimited. As we’ve seen from recent problems in open source software, serious vulnerabilities can remain undetected for some time, even years, and can prove extremely hard to address without breaking function. It’s easy to say that Apple has plenty of money, but throwing large sums of money at bugs and security issues doesn’t magically make them go away.

Apple can’t open a fresh crate of graduates, and give each of them a dozen bugs to fix in macOS 10.15. The most critical areas – firmware, the kernel, extensions – demand engineers with skillsets which are developed over years. This is particularly true at present, as work on Big Sur and later has to cater for both Intel and ARM architectures.

There’s also the problem of diminishing returns. Investment in improving Monterey and developing its successors is aimed at growing numbers of users, while those using Mojave and earlier are only going to reduce in time. What proportion of your engineers would you want to devote to products which are steadily vanishing?

We tend to have a naïve understanding of the complexity of bugs and vulnerabilities in macOS. Few are just a matter of making minor changes to a few lines of code which operate in complete isolation. Each new major version of macOS brings internal structural changes, and a fix which can be applied to macOS 12 could require extensive re-engineering of inter-dependent parts of a previous version.

For all these reasons, Apple wants to retain flexibility in maintenance of macOS. Making a public commitment to fixing bugs or vulnerabilities in previous releases of macOS is not only writing a blank cheque, but it could readily divert engineers from improving the current release, or the next. The only way that such a commitment could work would be to make it so vague that it was no more explicit than the implicit arrangement we have at present.

Any public commitment would necessarily be enforceable, and that brings a whole new bunch of problems. Bugs are currently triaged by Apple’s engineers, and the most serious, such as Mach (kernel) zone memory leaks, are normally fixed as quickly as possible, ideally in a patch release within days or a couple of weeks. There are others, such as my favourite Finder column width bug, which have remained unfixed for years, and I believe a few more obscure bugs which go right back to the early days of OS X.

Making such a system enforceable under threat of civil claim would bring huge problems. Who would then perform triage? How would time allowed and penalties alter triage? Could we see bugs assessed as being straightforward to fix being given higher priority so that deadlines could be met? Who (other than lawyers, perhaps) would want Apple’s software engineering driven by US courts?

There are enough problems with the current tacit arrangement, most notably with Apple’s faltering or absent communication. Whenever a macOS update contains security fixes, we’re provided with a detailed list of them. macOS 12.1 fixed two serious memory leaks, but not (at least) a third, yet Apple didn’t feel it worth mentioning any of those in its release notes for that update.

Response to Feedback bug reports is also an area in which Apple needs to take action. There’s huge variation: some bug reports attract rapid and close involvement of engineers, but others appear to be ignored altogether. It’s truly disheartening to spend hours putting together a report which is met by stony silence, particularly when the bug you’re reporting should have been picked up by internal quality assurance testing.

While some might see a public commitment as most important, I’d far sooner see Apple communicating better about bugs.