Disk Utility is one of the few utilities in the first public beta release of Mac OS X to have survived right the way through to High Sierra. It performs a suite of essential and sensitive tasks, working with our storage to format it, divide it into volumes, check and maintain them.

It originated from the Classic Mac OS 9 utilities, Disk First Aid and Drive Setup.

Those years have not been trouble-free. Many versions of Disk Utility seem to have suffered from some bug or other, occasionally bad enough to make us throw our hands up in horror.

The different types of storage supported have changed considerably over the years. The core has been the disk image (.dmg file), with its many variants, and the Mac Extended file system, HFS+, on hard disks, Fusion Drives, and now SSDs. To those have been added different CD and DVD formats, removed when Macs ceased having internal optical drives, and FAT32 and ExFAT formats for USB memory sticks (thumb drives). Disk Utility has also been the front end for Apple’s software RAID implementation for OS X. High Sierra’s Disk Utility version 17.0 is the first to include support for Apple’s new file system, APFS.

Disk Utility has a command line equivalent, in the notoriously complex diskutil, with hdiutil, variants of fsck, and other supporting tools. More recently, the Disk Utility app has come to rely on a background service, storagekitd, to do much of the hard work for it.

Open Disk Utility in Sierra or later (possibly El Capitan and earlier too), and watch in Activity Monitor for the appearance of storagekitd. This is the StorageKit daemon which runs as root and performs most of the work for Disk Utility. One reason that Apple has adopted this level of complexity is that many of the actions which Disk Utility has to perform require root privileges. Disk Utility runs in userland: in Activity Monitor, its user is you. To give it secure access to actions requiring root privileges, storagekitd is a helper, running as root.

Sierra’s version of Disk Utility, even in 10.12.6, its last release, is prone to throw an error the first time that you try some actions, such as formatting a USB memory stick. When you repeat the same action, Disk Utility suddenly discovers that it can perform it without error after all.

The lesson is that, if Disk Utility ever says no, ask it again, and it will often have changed its mind.

With another complete file system to cope with, it’s perhaps not surprising that Disk Utility in High Sierra has a few warts too. Its most embarrassing problem was a bug – actually in StorageKit, not the Disk Utility app itself – which stored passwords in plain text in the password hint for an APFS encrypted volume. This was fixed in the High Sierra Supplemental Update, which should be applied to every High Sierra installation before using APFS encrypted volumes.

That glaring error aside, Disk Utility version 17.0 does some quite strange things at times. My MacBook Air has a Transcend Flash drive inserted into its Secure Digital slot, which Disk Utility refuses to convert to APFS, reporting a StorageKit error 118. That apparently means that it became an unbootable system, which doesn’t seem to make much sense.

Sometimes you can coax Disk Utility 17.0 into doing tasks like that by selecting the drive in the list at the left, unmounting it using that command in the File menu, then trying the task again. Version 16.3 seems quite happy to manage its own unmounting when necessary; it appears that version 17.0 may need a helping hand.

One very helpful feature in Disk Utility from its earliest versions has been its mini-log for complex actions. These provide useful running commentary on what it is doing, and what the outcome is. Before the introduction of Sierra’s unified log, they saved us opening Console to understand what went wrong (or right); now they provide some of the few plain text insights into macOS.

Disk Utility 17.0 does appear to do some tasks in quite strange ways now, particularly with respect to APFS. Here is the transcript of its previous version, 16.3 in Sierra, formatting a USB memory stick in HFS+:
Unmounting disk
Creating the partition map
Waiting for partitions to activate
Formatting disk5s2 as Mac OS Extended (Journaled) with name stick1
Initialized /dev/rdisk5s2 as a 7 GB case-insensitive HFS Plus volume with a 8192k journal
Mounting disk
Operation successful.

The first three lines describe the storage device being formatted with a standard GUID partition map, then within that a single HFS+ journalled volume is created. That is all performed with the disk unmounted, so at the end it is mounted again, and ready to use.

Here’s Disk Utility 17.0 performing the same task, only this time the chosen format is not HFS+, but the standard case-insensitive variant of APFS:
Unmounting disk
Erasing
Initialized /dev/rdisk3s2 as a 7 GB case-insensitive HFS Plus volume with a 8192k journal
Mounting disk
Creating a new empty APFS Container
Unmounting Volumes
Switching disk3s2 to APFS
Creating APFS Container
Created new APFS Container disk4
Preparing to add APFS Volume to APFS Container disk4
Creating APFS Volume
Created new APFS Volume disk4s1
Mounting APFS Volume
Setting volume permissions
Operation successful.

As before, the disk is unmounted, then initialised (formatted) as a single HFS+ journalled volume, exactly the same as when that stick was formatted before. That disk is then mounted, and an APFS Container is created (representing the physical storage medium). The HFS+ volume is then unmounted, and ‘switched’ to APFS. A second APFS Container is created, and a new APFS volume is added to it.

This seems an extraordinarily indirect route to creating a single APFS Container, with a single APFS volume within it. I wonder whether, as the tools supporting APFS mature, Disk Utility will be offering something more direct.