What Is APFS and How Does It Differ from HFS+?

The short answer. APFS is Apple’s replacement for HFS+, introduced with macOS 10.13 High Sierra in 2017 and now the only filesystem macOS will boot from. It was designed for flash storage rather than spinning disks, and its four defining features — copy-on-write, snapshots, clones and shared containers — are what produce the behaviours that confuse people: free space that appears on several volumes at once, “purgeable” gigabytes that do not exist, and duplicates that take no space.

This guide explains what APFS actually does, what changed from HFS+, and where the compatibility line is.

Why HFS+ had to go

HFS+ dates from 1998. It was designed for a Mac with a spinning disk, a few gigabytes of storage and no notion of encryption, and it was extended for two decades to keep up with hardware it was never meant for.

The problems accumulated. HFS+ is a journaling filesystem, which means it writes a log of intended changes and replays it after a crash; that works, and it is why HFS+ volumes usually survive a power cut, but the journal itself is a bottleneck on flash. It has a hard limit of 4 billion files per volume and a 2TB file size limit that felt enormous in 1998. It has no native snapshots, no clones, no per-file keys, and its free-space accounting assumes one volume per partition.

More importantly, it has no real defence against metadata corruption. A damaged catalog file on HFS+ could make an entire volume unreadable, which is why “repair the disk” was a routine operation and why data recovery software had a market. APFS replaced the catalog with a tree structure that is written copy-on-write, so a crash leaves either the old state or the new one and never a half-written mixture.

The four features that produce every surprise

Copy-on-write

When APFS changes a block, it writes the new block somewhere else and then updates the pointer. The old block stays where it was until nothing references it. That is what makes the filesystem crash-safe without a journal: at any moment, the tree on disk is consistent, because a change is either complete or not yet linked in.

It is also what makes snapshots and clones possible, since an old state is preserved simply by not overwriting it.

Snapshots

A snapshot is a frozen view of the volume at a moment in time, taking almost no space because it references existing blocks rather than copying them. Space is consumed only when something changes afterwards, at which point the old block is kept for the snapshot and the new one is written for the live volume.

macOS uses snapshots for several things you have probably met without knowing it:

• Time Machine local snapshots. Hourly backups kept on the internal disk when the backup destination is not available. They are why a Mac with a full disk can still report tens of gigabytes as “purgeable”.
• System updates. macOS takes a snapshot before installing, which is how a failed update can roll back.
• The sealed system volume. The system itself is a signed snapshot, verified at boot.

Clones

A clone is a file that shares its blocks with another file until one of them changes. Copying a file on the same APFS volume is instant and takes no additional space, because the copy is a second reference to the same blocks; the first write to either file causes the changed blocks to be duplicated.

This is why duplicating a 40GB virtual machine in Finder is instantaneous, and why a duplicate-file finder can report two files as identical while freeing almost nothing when you delete one — they are clones, and the space is shared. DaisyDisk and GrandPerspective both report what the filesystem reports, so a cloned duplicate will look like two large files until you delete one and the other does not shrink as expected.

Containers and volumes

This is the mental model that causes the most confusion, and it is worth getting straight.

In APFS, a container is a partition. Inside it are one or more volumes, which are what you see in Disk Utility and in Finder. All the volumes in a container share one pool of free space, and each volume can be resized without repartitioning, because there is no fixed boundary to move.

A modern Mac’s internal disk typically has five or six volumes in one container:

Because they share a pool, every one of them reports the container’s free space. A volume “using” 400GB on a 500GB container will show 100GB available, and so will the empty one beside it. That is not double counting — the space is genuinely available to any volume that needs it, and the number is the same because it is the same space.

The practical consequence: “my disk shows two volumes and both are nearly full” is not a problem to fix, it is how the filesystem works.

What APFS changed about free space

Two behaviours follow from snapshots and shared containers, and both look like bugs until you know the mechanism.

Purgeable space. macOS counts local snapshots, iCloud files not downloaded and some caches as “purgeable” — space it can reclaim on demand. System Settings → General → Storage shows it in the bar when you hover. A disk reporting 4GB free and 60GB purgeable is not full; it is holding a reserve that will be released when something needs it. If you need the space immediately, tmutil listlocalsnapshots / and tmutil deletelocalsnapshots / removes the Time Machine ones.

Free space that does not grow as expected. Deleting a large file on APFS frees its blocks immediately, but if those blocks are referenced by a snapshot, they are not returned to the pool until the snapshot is deleted. This is the usual explanation for “I deleted 50GB and got 5GB back” — the file is gone, and a snapshot taken before the deletion still holds the blocks.

Encryption, and why it is per volume

HFS+ had no native encryption; FileVault 2 wrapped the whole volume in a software layer. APFS builds encryption in: each volume can have its own key, and files can have their own keys on top of that, which is what allows the system to read a file before the user has logged in — the pre-boot volumes are encrypted with keys the Secure Enclave holds.

For a user, this means FileVault on an APFS volume is a matter of whether the volume key requires a password, not whether encryption is happening. On Apple Silicon and T2 Macs the hardware encrypts regardless; on older Intel Macs the encryption is per volume and FileVault is the switch. There is a longer explanation in how to encrypt your Mac with FileVault.

Case sensitivity and Unicode

Two details that only matter when they break something.

Case. macOS formats APFS as case-insensitive by default — Report.pdf and report.pdf are the same file. A case-sensitive variant exists and can be chosen at format time, and once chosen it cannot be changed without erasing. Case-sensitive APFS breaks a surprising number of applications, including some Adobe installers and a few games, which assume the default. Do not choose it unless you have a specific reason, such as a build system that requires it.

Unicode normalisation. HFS+ normalised filenames to a decomposed form, so a filename typed as café was stored as cafe plus a combining accent. APFS preserves what you give it while still treating the two forms as the same name for lookup. That fixes a long-standing class of bug — a file that could not be found by the name it appeared to have — and it means a filename copied from HFS+ and one typed fresh may differ byte-for-byte while comparing equal. Software that compares filenames by bytes rather than by the filesystem’s own comparison can still be confused by this, which is why some sync tools produce duplicate-looking entries on a Mac.

What APFS still cannot do

Three limitations worth knowing before you format something.

It is not readable by Windows. Windows has no APFS driver and cannot be made to have one without third-party software. Boot Camp cannot read the macOS volume. If a drive has to move between a Mac and a PC, format it exFAT.

It is not readable by most cameras, consoles and older devices. A camera that expects FAT32 or exFAT will not mount an APFS card, and some TVs and media players will not read an APFS USB drive.

It does not checksum file contents. The metadata is protected; your documents are not. Silent corruption in a file — a flipped bit on the flash, a bad write — is not detected by the filesystem. That is what verified backups are for, and it is why a backup tool that verifies its own writes is worth more than one that does not.

How to see what you have

Three commands cover it.

diskutil info / | grep -E "File System|APFS"
diskutil apfs list
mount | grep apfs

The first tells you what the startup volume is formatted as. The second prints the container and its volumes with their roles and sizes, which is the clearest picture of the shared-pool arrangement. The third lists every mounted APFS volume, including external ones.

For external drives, Disk Utility’s Get Info on a selected volume shows the format in plain words, which is enough for deciding whether a drive will work with a given device.

What APFS changed about Time Machine

Time Machine was rebuilt on APFS, and the change is worth understanding because it altered what a backup is.

On an APFS destination — supported from macOS 11 and now the default for new backups — Time Machine writes each backup as a snapshot of the source, and the destination keeps those snapshots as its history. Because the filesystem can share unchanged blocks between snapshots, a new backup only stores what actually changed, and the operation is much faster than the old directory-linking approach.

On HFS+ destinations, Time Machine still works and still uses the older method: a hierarchy of folders with hard links for unchanged files. It is slower and it is more fragile, because a corrupted link chain damages the whole history rather than one snapshot.

Two practical consequences. A backup disk that is APFS can be used for other volumes in the same container without partitioning, which is why a single external SSD can hold a Time Machine backup and an archive of files. And an APFS backup can be browsed by mounting a snapshot, which is how Time Machine shows you a point in time without needing a special browser.

Where APFS is faster, and where it is not

The improvements are concentrated in metadata operations, and the costs are concentrated in workloads that a spinning disk handles badly.

Faster on flash:

• Creating and deleting large numbers of small files, because the tree structure scales where HFS+ ’s catalog did not.
• Copying files within a volume, because of clones — a copy is a pointer until something changes.
• Directory listings on folders with tens of thousands of entries.
• Taking a snapshot, which is effectively free.
• Anything involving encryption, because it is in hardware on modern Macs rather than a software layer.

Slower or neutral:

• Sequential writes on a hard disk. Copy-on-write scatters writes across the volume, and a spinning disk pays for every seek. This is the main reason APFS on a large external hard drive is not obviously better than HFS+ for a backup.
• Workloads that rewrite the same file repeatedly, where the old block is retained for a snapshot and the new one is written elsewhere.

The honest summary: on an SSD, APFS is better in every way that matters and you should not think about it. On a spinning disk, it works correctly and the advantage is smaller than the marketing suggests.

Recovering data from an APFS volume

APFS made some kinds of recovery easier and others harder, and the difference matters if you have lost something.

Easier: snapshots. A file deleted an hour ago may still exist in a local snapshot, and mounting that snapshot read-only lets you copy the file back out. tmutil listlocalsnapshots / shows what is available; mount_apfs -s com.apple.TimeMachine.2026-11-01-120000.local /dev/disk3s1 /Volumes/snap mounts one. This is the first thing to try and it costs nothing.

Harder: undelete. Copy-on-write does not leave deleted blocks lying around in a predictable place the way HFS+ did, and on an encrypted volume the blocks are ciphertext until the volume key is available. Recovery tools that worked well on HFS+ have had to be rewritten, and their success rate on APFS is lower. Disk Drill and similar tools support APFS to varying degrees; check the vendor’s current documentation rather than assuming a feature list from three years ago still applies.

Impossible: anything on a volume whose key is gone. If FileVault is on and neither the password nor the recovery key is available, the data is not recoverable by any tool, which is the point of the encryption rather than a limitation of the recovery software.

The practical advice is the same as it has always been, and APFS makes it more true rather than less: the backup is the recovery plan. Snapshots are a convenience, not a strategy.

Fusion Drives, and the machines that kept HFS+

When APFS shipped in 2017 it was not available on every Mac. Fusion Drives — the hybrid arrangement in some iMacs and Mac minis that combined a small SSD with a large hard disk — were excluded, and so were some hard-disk-only configurations. Support arrived later, and a Fusion Drive running a current macOS is APFS with a twist: the two physical devices are presented as one volume, and the filesystem decides which blocks live on the fast half.

The reason for the delay is that APFS’s write pattern assumes flash. On a Fusion Drive, copy-on-write produces writes scattered across the volume, and the driver has to decide for each one whether it belongs on the SSD tier or the hard disk tier. That is a harder problem than it is on a pure SSD, which is why it took a version to ship and why those machines feel slower under APFS than their specs suggest.

If you have an older Mac with a spinning disk, the honest advice is unrelated to the filesystem: replace the disk with an SSD if the machine allows it, and the difference will be larger than any tuning. APFS on a hard disk is correct and safe, and it is not what makes an old machine slow.

What First Aid actually checks

Disk Utility’s First Aid is the only filesystem repair tool macOS ships, and it is worth knowing what it does and does not do.

It verifies the filesystem’s own structures: the container’s space manager, the volume’s tree of metadata, the snapshot list, and the checksums that protect all of it. If a structure is inconsistent, it repairs it from redundant copies where it can.

It does not check your files. There is no scan of file contents, no verification that a document opens, and no detection of bit rot inside a file. A volume that passes First Aid is a volume whose filesystem is sound, which is a different claim from “your data is intact”.

It also cannot repair a broken seal on the system volume. The sealed snapshot is verified cryptographically at boot; if it fails, the answer is to reinstall macOS, not to run First Aid.

Run it per volume rather than per container when you are diagnosing a specific problem, and run it on the container when a volume will not mount. The distinction matters because the container holds the space manager and the volume holds the tree, and a fault in one produces different symptoms.

Should you convert an external drive?

If it is already APFS: leave it, unless it needs to work with a non-Mac device.

If it is HFS+: converting means erasing. There is no in-place conversion in either direction. Copy the data off, reformat as APFS, copy it back — and if the drive is used for Time Machine on a current macOS, APFS is now supported and is the better choice because it allows snapshots on the backup itself.

If it is exFAT: leave it if it moves between platforms, and consider APFS if it does not. exFAT has no journal, no snapshots and a weaker allocation strategy; it is a compatibility format rather than a good one.

If it is a spinning external disk used only for backups: APFS works and HFS+ also works. The advantage of APFS on a hard disk is smaller than on an SSD, because copy-on-write produces more scattered writes and a spinning disk pays for them in seek time. For a large backup drive, this is a reason to keep it simple rather than a reason to avoid APFS.

FAQ

Is APFS why my Mac needs less defragmentation? Partly. APFS allocates to avoid fragmentation on flash and does not need the kind of maintenance HFS+ did, and SSDs do not benefit from defragmentation in the way hard disks do. There is no defragmentation tool for APFS and no reason to want one.

Why does Disk Utility show “Macintosh HD” twice? Because there are two volumes: the sealed system volume and the data volume, which macOS presents as one volume in Finder. This split is what allows the system to be read-only and verified while your files remain writable.

Can I create more volumes in the container? Yes, and it is cheap: Disk Utility → select the container → + → add a volume. It draws from the same free space, so you are not committing storage in advance. This is the APFS answer to partitioning, and it is why you no longer need to guess a size.

Does APFS support hard links to directories? No, and HFS+ did not either in practice. It supports hard links to files, and clones cover the use case that directory hard links were sometimes reached for.

What happens to my HFS+ external drive if I upgrade macOS? Nothing. The installer converts the startup volume and leaves external drives alone. An HFS+ drive continues to mount and work normally, and will for as long as macOS supports reading HFS+.