When your business or organisation, no matter how small, invests in Macs, it cannot afford to place complete reliance on Apple’s or any other external support service to solve its Mac problems. The more complex your setup, the more remote you are from an Apple store, and the more heavily your work depends on Macs, the more self-reliant you need to be.
In any case, until you can identify whether a problem stems from Mac hardware, macOS or third-party products, you cannot know which support desk to contact. We’re also all only too familiar with the support shuttle problem, in which Apple blames a third-party product, that third-party vendor blames macOS, and the user is left without a solution.
macOS Sierra provides several major diagnostic tools, the most important being hardware diagnostics startup mode (Apple Diagnostics or Apple Hardware Test, depending on the model), the macOS unified log,
sysdiagnose, and an array of command tools.
Hardware diagnostics routines delivered by the diagnostics startup mode are reasonably comprehensive, but it is not uncommon for them to fail to fully diagnose hardware problems which Apple’s more advanced in-house diagnostics can detect. This may be true, for example, of early graphics adaptor problems in iMacs, which often pass the regular diagnostics checks but fail when tested at a Genius Bar.
Some hardware tests, particularly those for storage systems, remain appallingly weak: SMART disk diagnostic indicators are still not supported on most external storage devices, notably drives connected by USB. A free third-party kernel extension is available to address this, and DriveDx and other utilities open access to a much wider range of SMART and other diagnostic indicators, but Apple’s longstanding failure to address these issues is shocking.
In the past, Apple has provided access to its full hardware diagnostics – as used by Apple Genius Bars and approved service agents – to users by various means. As far as I am aware at present, there is no such access, which is a significant hindrance to remote users and most support folk.
From its inception, Unix and its derivative operating systems have maintained logs, which have been key tools in the diagnosis of the majority of software and many hardware problems. macOS Sierra brought a major change in logging which departs from the established model, in the new macOS unified log.
For Apple’s engineers and most developers, the unified log is an extremely powerful tool because of its high performance and fine detail. At times, it can make tens of thousands of entries per minute, with no noticeable effect on performance. The engineer’s dream becomes the sysadmin’s nightmare, though: trying to wade through such high volumes of information-dense entries requires powerful tools.
Switching from El Capitan’s traditional logs to Sierra’s unified log has proved a major trauma for all those who look to the logs for diagnostic information. Apple has, characteristically, provided no guidance or help to facilitate the transition (apart from limited information for developers, given at WWDC 2016), and both its GUI tool Console and the
log command are woefully underpowered and inadequate for the purpose.
A good example is in what used to be the OS X security log, which provided sysadmins with valuable information about who accessed a Mac, and how they did so. Comparable information is extremely hard to locate in Sierra’s new unified log, and there is no off-the-shelf method of excerpting entries equivalent to those which used to be made in El Capitan’s security log.
For many users and support folk, Sierra’s unified log is effectively inaccessible, and no longer of any diagnostic use.
Apple now places great reliance on its command tool
sysdiagnose for generating an enormous dump of diagnostic information which gives insight into almost every active process and system on a Mac. I have looked at its use and output here, and concluded that without more advanced diagnostic tools and information to support it, it is even more overwhelming than Sierra’s unified log, and of almost no value to advanced users or support folk.
Beyond that, there remain many command tools which have important roles to play in both the diagnosis and solution of problems; in general these are good, but their coverage is patchy and some important commands lack
man pages, which is inexcusable.
lsregister, for example, is buried away in the CoreServices framework rather than in a standard command tool folder, and has no
man page, only usage information. As the only tool to maintain the Launch Services database, this is absurd.
macOS has become increasingly complex over the last few years, but diagnostic and control tools have become less accessible to advanced users and support folk. As a result, for those outside Apple, macOS has become harder to diagnose and support. For many users, particularly those in businesses and organisations which have invested in Macs, this is plainly unacceptable even before considering the parlous state of Apple’s documentation.