Last Week on My Mac: On-board diagnostics

Late last summer, as I was driving up the road into our village, my car had a hissy-fit with its electric parking brake, refusing to release it automatically. Within a few seconds, the ABS failed, followed rapidly by traction control. I worked out how to take back control manually, and drove off to the accompaniment of three warning lights.

That proved intermittent, so guessing that the moment it got near a garage the faults would disappear, I waited until they persisted. Then the warning system drew an ace: it told me that there was an engine fault which needed the attention of a garage. With four warning lights on, and rapidly heading for a complete set, I booked it in for investigation, but not before I’d examined the feasibility of reading its on-board diagnostic system (OBD-II) myself.

In case you’re already familiar with the perils and pains of OBD-II, I’ll spare you the detail, but I would have ended up spending several hundred pounds only to learn that there were faults with those four systems, requiring a garage’s attention. Even when a factory-trained mechanic had examined my car, all they could tell was that two of the four braking sensors had failed, and needed to be replaced at a cost of around £500. Until that had been completed, no one knew whether there might be other faults. Thankfully, once I had parted with the money, it was clear that the car was fine again, and I still keep looking at the dashboard wondering why there aren’t any warning lights on.

My lesson is that motor vehicle diagnostics are even less diagnostic than the information we get from macOS, if that’s possible. With its misleading alerts, inscrutable crash reports, puzzling panic logs, and the Unified Log with its chronic verbal diarrhoea, we’re all too often overwhelmed with information but bereft of any understanding of what’s gone wrong. Just like my car’s OBD-II system, error and fault reporting in macOS is designed primarily for engineers, and leaves users baffled.

Given the amount of money and engineering effort which Apple has invested in the Mac’s human interface, even down to the unboxing experience, and the costs incurred by Apple Support, you’d have thought that Apple would be keen to build in proper diagnostics which users could understand. Instead of an alert advising me wholly inappropriately to back a volume up because Disk Utility can’t perform an operation correctly, and providing me with an error code which is devoid of any meaning, couldn’t macOS treat me like a user and explain?


Recent versions of macOS have an appalling record of telling the user the wrong reason for something not working as they’d expect, then leaving them wondering what the hell they can do to download an undamaged version of a macOS installer from Apple.


Perhaps the biggest cop-out of them all is referring the user to “the software manufacturer for assistance”, when that’s Apple and it has a large view which it could have used to explain what went wrong.


But the most common sop to the user is to give them no useful information at all, and just throw them a desultory error code.


Handling errors properly is user-centred. In most cases, simply telling the user that something hasn’t worked as they expected is like the start of a detective novel. Their immediate questions are why, and what can I do to get it to work? Not one of those four error alerts explains why, in terms the user can understand, nor do they give a clue as to where to go next, apart from contacting “the software manufacturer for assistance”.


App crash reports and panic logs are even worse, a service the user provides to Apple, apparently, with nothing in return.

If my Mac is capable of recognising the faces of friends in their photos, then it’s surely able to provide me with a little assistance in diagnosing the cause of an error, and suggesting what I can usefully do next. If Disk Utility can’t unmount a container, can it please explain why that could be, and at least link to an article like this one?

Software engineers are hopeless optimists when they design and code only for success. There’s much more to handling errors than displaying a couple of phrases of in-house jargon and fobbing the user off with a magic number. It’s high time that designing error-handling to help the user became a central tenet of macOS.