Like so many things in computers, the amount of free space on a disk is something which used to be simple and taken for granted. In traditional file systems like HFS+, all the system had to do was total up the number of unallocated (free for use) storage blocks, and multiply that by the block size. You could then go on filling up that free space until there was almost none left at all. So why isn’t APFS capable of doing that?

The answer lies in the complexity of what gets stored in APFS.

Take snapshots as an example. The snapshot itself is relatively small, and is simply a copy of the file system metadata at the time that snapshot was made. But with that snapshot comes a variable and changing amount of file data. To be able to revert to that snapshot, from the moment it’s taken, all storage which would be marked as becoming free, for example when you delete a file, is retained in a special pool. That will be needed later should you decide to revert to that snapshot, and without it, the snapshot serves no useful purpose. The more you make changes to the file system after that snapshot is made, the more of those changes accumulate, blocks which aren’t in active use any more, but which are tied to the snapshot.

While snapshots and their associated data are important, they’re also considered non-essential. When they’re made by Time Machine, it tries to keep them intact for 24 hours before automatically deleting them. But when the pressure is on free disk space, they can be deleted earlier to free up space.

Although Apple’s documentation isn’t particularly precise about it, APFS also tries to keep additional copies of file system metadata as much as it can, but that too is considered non-essential, and can be pared back when necessary.

The end results of this are three different figures:

• plain Free Space, which might be 343.69 GB, which is the amount of storage space available now;
• space available for important usage, which might be 403.03 GB, described by Apple as the amount of space available for storing important resources;
• space available for opportunistic usage, which might be 342.41 GB, described by Apple as the amount of space available for storing non-essential resources.

You can see those using several utilities, including the Volumes button in my free Mints.

But there’s more to consider.

First, free space available now doesn’t necessarily represent the amount of space committed to the items already stored on that disk. Two special types of file in APFS make this even more complex: sparse and clone files. A little editing or clumsy copying of a sparse file, and what currently only takes a few MB can explode to tens of GB. As clone files are edited and progressively share less common data with the original, they too will occupy more free space, although that growth normally occurs more gradually.

The other factor we tend to overlook is that installation often requires more free space than might seem necessary. That’s particularly true of the largest items we install, such as the system itself and Apple’s Xcode SDK. The latter, for instance, is delivered as a 12 GB download from the App Store or Apple’s Developer downloads, but is heavily compressed, and typically takes around 36 GB, or possibly as little as 19 GB, of actual storage, and that’s before it has cached documentation pages and other additional items it uses.

System updates and installations are also heavier on free space than you might expect, as they need to store the whole download, expand its contents significantly, install them on the System volume, while maintaining the existing snapshot of the old System volume, then make a new signed and sealed snapshot to form the updated boot system. As your System and Data volumes necessarily share free space within the same container, that’s important to remember when free space becomes limited.

There’s one more twist which can sometimes catch out the unwary: never try estimating free space by totalling the file sizes of a volume’s contents. Because storage blocks can’t be shared between files, the total space occupied by each item is actually that reported as its size “on disk”. For example, Parallels Desktop.app has a reported size of 648 MB, but actually takes 650.5 MB “on disk”. Look in the Get Info dialog for some other apps and you may be puzzled: Pages is reported as having a size of 651 MB, but only requires 434.5 MB on disk, and that disparity is even greater with Xcode, which may be 35.6 GB in size, but only takes 18.86 GB on disk. Those oddities probably reflect storage saved by compression, and the effects of sparse and clone files.

One last thing: file sizes given in macOS don’t include any extended attributes, which are kept in the file system metadata. My free app Precize shows full details, although in the great majority of cases the size of extended attributes is very small relative to the size of data. It’s yet another factor you may need to account for if you ever try to run free space close to the limit.