Why use APFS?

Although your Mac’s boot volume group, including the Data volume that’s almost always used for your Home folder, has to be in APFS format, you can still use Macintosh Extended or HFS+ format for other drives and their contents. This article provides advice to help you choose between the two Mac native file systems.

No choice

Other than the boot volume group, including the Data volume, APFS is only likely to be required to store Time Machine backups in recent versions of macOS. Although I think it’s still possible to continue backing up to an existing HFS+ backup store, you should stick to APFS for all new Time Machine backups.

One possible let-out, used for network backups, is to host a sparse bundle on another file system, and for that to use APFS internally. That’s how NAS can host Time Machine backups on Linux file systems such as Ext4 or Btrfs. However, I wouldn’t recommend putting that sparse bundle on HFS+, where they have known problems.

All new local Time Machine backups for recent macOS should be to Case-sensitive APFS, either encrypted or unencrypted.

APFS special file types

There are two types of file that are special to APFS and don’t exist in HFS+. Although they also exist in some other modern file systems, they can’t generally be converted between those and APFS.

Sparse files

Most modern file systems store files that contain significant amounts of blank or absent data in a special sparse file format. In APFS, this is implemented by only allocating file extents to those blocks that do contain data. In many cases, this can save significant disk space. Initially, sparse files were unusual in APFS, but over time they have become increasingly common, and can now be found in some types of disk image, virtual machine storage (VMs), and in databases. Note that disk image types whose name includes the word sparse, sparse bundles and sparse disk images, don’t use sparse file format at all, but are the victims of an unfortunate name collision.

Neither macOS nor APFS can simply convert regular files to sparse format; for a file to be written in sparse format, the code writing it must explicitly skip the empty space. As a result, sparse files are prone to explode to full size when they’re copied or moved unless that’s between two local volumes both using APFS. Examples of where you should expect them to explode include:

copy or move to HFS+, as that has no sparse file format
copy between Macs using AirDrop or file sharing
back up to network storage, although local Time Machine backups to APFS should preserve them
copy or move to any other local file system other than APFS, even if that file system has its own support for sparse files.

In each of those cases, sparse files explode in size as they’re copied from the source volume. If you have a 100 GB sparse file that only takes 20 GB of local disk space, when it’s copied to a local HFS+ volume, the full 100 GB has to be transferred.

One potential workaround is to compress the sparse file before transferring it. All good compression algorithms will work efficiently on the blank space in the file, so when compressed its size could be as small as the original sparse file. However, when it’s decompressed, even on another APFS volume, it will explode to full size. For disk images, that can be corrected by mounting them, as APFS will then trim their contents, and the disk image should be saved back into sparse format.

Clone files

These are two distinct files that share common data, normally the result of duplicating the original within the same APFS volume. Those two cloned files then only require the storage of the whole file, plus those data blocks that differ between them. This only works within the same volume, and the moment that either of the clones is moved or copied to any other volume, it assumes full size, as it can no longer share data with the other clone. Clones can’t span two volumes.

However, most other file systems don’t support file cloning in this way. When you duplicate a file in an HFS+ volume, there’s no shared data between them, and the two require twice the amount of space as one.

Benefits

In terms of disk space used, the benefits of sparse and clone files aren’t as obvious as you might expect. Because of their potential to swell to full size, sparse files can’t be copied to a volume that isn’t large enough to cope with that, but once they have been copied they only require their current size on disk.

As far as you’re concerned, greatest benefits come in speed of handling, and effects on SSD ‘wear’. Creating clone files is almost instant, even if they’re huge, and because of their efficiency in the use of storage extents they minimise erase-write cycles on SSDs.

Snapshots

I have recently explained how snapshots work, and how you can use them alongside proper backups to restore lost or damaged files. Snapshots are used in most modern file systems, but don’t exist in HFS+. If you want local snapshots of any volume connected to your Mac, you’ll most likely have to use APFS unless you know how to use something more exotic. Note that, unless you’re Time Machine, you can’t copy snapshots to another volume or drive, but you can mount them and copy their contents to another volume.

Encryption

Unlike HFS+, APFS was designed with encryption built in. This significantly improves its performance with encrypted volumes, and makes them more secure. If you need to store files in an encrypted volume, you should prefer APFS for that volume.

Volumes share free space

In HFS+, volumes have fixed size, as they’re disk partitions. Although you may be able to change partitioning that’s already in use without losing data from any of the volumes involved, that’s never guaranteed.

In APFS, volumes share free space with others within the same container. While you can set limits on individual volume size, this makes management of free space much easier, allowing volumes to occupy the space they require, instead of that being predetermined.

Directory hard links

These aren’t available in APFS, but are supported in HFS+, where they’re used extensively in old-format Time Machine backups. They work like regular hard links, but act on directories rather than individual files. They can’t be copied in any way to an APFS volume, but can be used to reconstitute a volume. This ensures a new Mac that only uses APFS can still access old Time Machine backups from a previous Mac: macOS retains full support for HFS+ and its directory hard links, so you can mount those old backups and access them through the Finder.

Hard disk fragmentation

APFS was designed for use on SSDs and the Flash drives used in Apple’s devices. It has design features that will never work well on hard disks, as they fragment not only file data, but the file system itself. While it’s possible to boot an Apple silicon Mac from a hard drive, you wouldn’t want to run your Mac from one. With an active file system such as that on your Mac’s Data volume, files and the file system get steadily more fragmented until the drive eventually grinds to a halt.

Hard disks using APFS normally remain usable for a year or more when they store files that don’t get changed very often, like media libraries, and in many cases backups, including Time Machine’s. Experience with the latter suggests that most cope well, but in extended use they too eventually become too fragmented to continue. There currently isn’t any effective solution to that fragmentation, other than wiping the volume and starting from scratch. Because Time Machine’s backups are stored as snapshots, they can’t even be copied to another drive to help.

Reliability and maintenance

APFS has been designed to be far more robust and reliable than HFS+. A longstanding problem with HFS+ before journalling was introduced was its propensity to accumulate minor errors that eventually lead to catastrophic failure. One common reason for this was sudden restarting or other interruptions to file system operations. Journalling was added to reduce the chances of those leading to file system damage or inconsistency, and for that reason, you should never use HFS+ without journalling.

One key feature in APFS that makes errors highly improbable is its use of copy-on-write for all file system metadata. This ensures that changes made to the file system are almost guaranteed to remain consistent, even when suddenly interrupted. Unfortunately, one of the side-effects of copy-on-write is fragmentation of file system metadata, thus its main limitation on hard drives.

Conclusion

If your Mac is running a more recent version of macOS, from Mojave onwards, all its SSDs should by default use APFS. Deciding which to use for hard disks is more difficult, and you need to weigh up their advantages and disadvantages carefully. Unless the volumes on that disk are going to see frequent changes, when fragmentation could result in poor performance, in most cases APFS should now be the default.

References

HFS+
Inside the file system: 1 Disks and partitions
Inside the file system: 2 HFS+ volumes
Inside the file system: 4 Summary and references

APFS
APFS: Files and clones
APFS: Directories and names
APFS: Containers and volumes
APFS: Snapshots
APFS: Encryption and sealing
APFS: Special file types
APFS: Command tools
APFS: Beyond, to vfs and volfs
APFS: Log entries
APFS: Extended attributes revisited
APFS: How sparse files work