In recent years, I’ve grown concerned – as many of you have – at the increasing number of obvious bugs in release versions of macOS. In the last week or so, I’ve come across some real howlers: the Rich Text Spotlight importer which can’t import the content of RTF documents, Bluetooth status which is never up to date when you first check it, and most recently Big Sur installers and updaters which don’t work on external SSDs connected to M1 Macs.

Each time, I ask whether Apple tests its software before release, as the evidence that I’m seeing suggests that many changes are only tested by users after that version of macOS has been released.

Of course, this is a small minority of the new and changed code that Apple’s engineers create. When I check through updates to macOS for incremented build and version numbers, there are usually hundreds if not thousands, the great majority of which run as intended. It’s those that don’t, often key tools like Disk Utility, which are marred by obvious bugs.

Software development has a traditional cycle, in which engineers code and test repeatedly until they’re confident that changed features are correct and robust, and that everything else still works as intended. Documentation is then updated, and the product or component is released. All this has to take place to tight deadlines: the six or more scheduled updates, such as macOS 11.2, within each annual major macOS release cycle don’t occur when everything happens to reach maturity, but are driven by the calendar. Between those is scope for what used to be called Supplemental Updates, now patches such as 11.2.1, which have to be added to address the unexpected.

Last summer, Dave (as I’ll call them) had some changes to make in the Rich Text Spotlight importer for Catalina 10.15.6. These were sufficient to take its build number from 319 to 319.60.100, but left its version number unchanged. The pressure was on, with the release date set at 15 July. Although Dave tested the changes he’d made, he didn’t have time to test whether the mdimporter still indexed the content of RTF files. What he didn’t realise at the time was that he’d altered the logic in the code, so that RTF files didn’t get their content indexed any more.

On 15 July 2020, millions of Mac users updated to 10.15.6, and Dave’s Spotlight importer stopped working for their RTF files. More changes were made in preparation for the release of Big Sur, bringing its build number to 326. Still it wasn’t tested against RTF files, and the bug has remained to this day, in the Rich Text importer that doesn’t work with Rich Text files.

Apple relies on bugs reported through its Feedback systems. As this Spotlight bug isn’t easy to recognise, users and third-party developers are only now realising the effects of Dave’s simple coding error. Without thorough testing, Apple is almost completely reliant on Feedback to detect and diagnose bugs.

This system is both flawed and woefully inefficient, as any expert in quality management will tell you. It’s like letting cars roll off the production line with no windows, and waiting for customers to bring them back to have them installed. By far the best choice is to build correctly the first time, or, as second best, to detect and rectify defects before shipping. So long as shipping updates remains relatively cheap, and your customers are happy to report all the defects which you didn’t fix, it appears to work, at least in the short term.

I’ve now reached the stage where I simply don’t have time to report all these bugs, nor should I have to. Indeed, I’ve realised that in doing so, I only help perpetuate Apple’s flawed engineering practices.

Developing software is both labour- and time-intensive. Code is usually relatively quick to write, but far slower to test and debug, and to document. Apple cuts corners, and saves money, by reducing testing and debugging, and (almost invariably) by not documenting. We let Apple get away with this by devoting our time to testing and documenting for Apple. There’s no point in complaining about poor quality of macOS and other Apple software if you then help Apple continue its bad practices.

There are some bugs which aren’t obvious, for which user bug reports remain essential. If you discover an arcane panic which only occurs on the first Tuesday in the month on a specific model of Mac, it remains important that should be reported. There’s a limit to what we can expect Apple to test, and wherever we discover bugs or other problems which aren’t so obvious, Feedback is an excellent way to report them.

But Apple uses its current system to its own advantage. It’s in control throughout: your Feedback reports may pass without any acknowledgement, can be ignored completely, or you can be told that something which is manifestly broken “behaves as expected”. Apple even erects barriers to make the whole process more trouble by requiring a large sysdiagnose report, although it may have no possible relevance: if you’ve ever tried to send a Feedback report without one, you’ll understand what I mean.

Above all, there’s the threat. If we don’t complete Feedback, then Apple won’t know of the bug, and it won’t get fixed. That’s a subtle form of blackmail, and hardly the attitude of a world-leading company towards its customers. If Apple really does care about the quality of its products, it should be falling over itself to improve them, and to ensure that macOS is released with an absolute minimum of flaws. Instead it prepares its perpetual excuses that it wasn’t aware of a problem because we didn’t report it, when every other industry does its utmost to ensure that customers don’t have problems with their products.

Where bugs are so obvious that they should never had been released, I’ll continue providing details in an article here, which I’ll link to a new page of macOS Howlers. If you’re an Apple engineer, please don’t take this personally. I don’t think the current system is good for you either, but at present Apple only seems to respond to public criticism. If there’s anything that I can do to help you or your team resolve these issues, please contact me, and I’ll do what I can.