APFS (Apple File System)

Apple announced APFS at WWDC 2016 as a ground-up replacement for HFS+, the Mac file system that dated to 1998 and had been stretched well past its original design. APFS shipped with iOS 10.3 in March 2017 and macOS 10.13 High Sierra in September 2017. By 2026, APFS runs on every supported Apple device: Macs, iPhones, iPads, Apple Watches, Apple TVs, and Apple Vision Pro. The transition from HFS+ was automatic for SSD-equipped Macs during the High Sierra upgrade, and HDDs / Fusion Drives were converted in later macOS releases.¹

APFS was designed with three constraints in mind: SSDs were now standard (so the file system needs to be flash-friendly), encryption needed to be a first-class feature (not bolted on like HFS+’s FileVault 1), and the file system needed to scale to billions of files. Every architectural choice traces back to one of these constraints. The core innovation is that APFS does not modify data in place: any change writes to fresh blocks first, then atomically updates the pointers. This is called copy-on-write, and it’s the foundation of every other APFS feature.

Copy-on-write metadata

When a file changes on FAT32 or NTFS, the file system overwrites the old metadata in place. If a crash happens during the write, the metadata can end up half-old, half-new, and corrupt. NTFS uses a journal to roll back partial writes; FAT32 has no protection at all.²

APFS does it differently. When metadata changes:

1. The new metadata is written to a fresh block somewhere else on disk.
2. A new checkpoint is written that references the new block.
3. The old metadata block is freed for reuse.

If a crash happens between steps 2 and 3, the old metadata is still intact, and the file system reverts to the previous consistent state on next mount. No journal replay needed; the previous checkpoint is the consistent state. Apple calls this redirect-on-write; it’s the same idea as ZFS and Btrfs use, and it’s why APFS has crash protection without the write amplification of journaling.

Object IDs and the Object Map

HFS+ stored direct disk pointers in metadata: a file’s catalog entry contained physical block addresses. APFS instead uses virtual object IDs: a file’s metadata refers to objects by 64-bit identifiers, and a separate B-tree called the Object Map translates IDs to physical block addresses.³

The advantage is flexibility: when copy-on-write moves a metadata block, only the Object Map needs to be updated; the references to that object from other places stay the same. The disadvantage for recovery: if the Object Map is damaged, the file system knows that files exist (their metadata records are intact) but cannot find their data on disk. Object Map damage is one of the most challenging APFS recovery scenarios.

Checkpoints and the Container Superblock (NXSB)

The Container Superblock (called NXSB in Apple’s docs) sits at block 0 of every APFS container and points to the location of the Checkpoint Descriptor Area. The checkpoint area is a circular buffer that holds the most recent consistent states of the file system. When APFS commits a metadata change, it writes a new checkpoint that becomes the new “official” state of the volume.⁴

If the NXSB is corrupted, macOS cannot find the volumes inside the container at all. Disk Utility reports the disk as unmountable. APFS keeps a copy of the NXSB elsewhere as a recovery resource, but unlike NTFS’s $MFTMirr or FAT32’s two FAT copies, the redundancy is less obvious to repair tools, and consumer-grade tools often fail at NXSB recovery where lab tools succeed.

Metadata checksums (no data checksums)

APFS calculates non-cryptographic checksums (using the Fletcher-64 algorithm) for every metadata structure. When the OS reads metadata, it verifies the checksum; mismatches indicate corruption. This is a major improvement over HFS+, which had no metadata integrity checks at all.⁵

Note what’s missing: APFS does not checksum file data, only metadata. Apple’s reasoning is that the storage device’s ECC handles bit errors at the physical level. The trade-off: silent data corruption (a bit flip in a file’s data clusters that ECC missed) is undetectable by APFS. ZFS and Btrfs both checksum file data; APFS doesn’t, except on Sealed System Volumes where the entire system is cryptographically hashed.

This is the architectural feature most distinctive to APFS, and the one that surprises people coming from FAT32, NTFS, or ext4. An APFS partition is not a single volume; it’s a container that holds one or more volumes that share the same free space pool. The volumes don’t have fixed sizes; they grow and shrink dynamically based on what the user is doing.⁶

Container vs volume

An APFS container is what you create when you partition a disk and choose APFS as the format. A container has a fixed size (the partition size). Inside the container, one or more APFS volumes live and share the container’s free space:

• Each volume has its own format options: case-sensitive or case-insensitive, encrypted or unencrypted. The four variants you see in Disk Utility (APFS, APFS Encrypted, APFS Case-sensitive, APFS Case-sensitive Encrypted) are volume-level choices.
• Free space is shared: if Volume A holds 400 GB and Volume B holds 200 GB on a 1 TB container, both volumes effectively have 400 GB of available space because they share the same free pool. There’s no fixed allocation.
• Volumes can be created or deleted instantly: no resizing required, no risk of running out of space on one partition while another has plenty. Adding a new volume takes effectively zero time and zero space until something is written to it.
• Reserve and quota sizes are optional per-volume limits: you can guarantee a volume will always have at least N GB available (reserve), or cap it at no more than N GB (quota).

macOS’s standard volume layout

Modern macOS (Big Sur and later) uses at least five APFS volumes inside a single container on the boot disk:⁷

• Macintosh HD (System volume). Read-only and cryptographically signed (the Signed System Volume or SSV). Holds macOS itself. By default, no process can write to it, even Apple system processes.
• Macintosh HD – Data. Read-write. Holds your user files, applications you installed, and everything else that changes. The user-visible ~/ home directory lives here.
• Preboot. Unencrypted. Contains the data needed to boot each system volume in the container, including FileVault unlock components.
• VM. Unencrypted. Used by macOS for storing encrypted swap files. Sized dynamically based on memory pressure.
• Recovery. Unencrypted. Contains recoveryOS, accessible by holding Cmd+R during boot. Must be available without unlocking a system volume.

The System and Data volumes together are called a volume group; macOS treats them as a unit through firmlinks (a feature that makes them appear as a single filesystem to user-space apps).

iOS volume layout

iPhones and iPads have a simpler layout: at minimum two volumes inside the container, the System volume (signed and read-only) and the Data volume (encrypted with the user’s passcode). The same architectural pattern as macOS, just fewer optional volumes.

Most APFS features build on the copy-on-write foundation. Snapshots and clones are essentially free because copy-on-write already preserves old blocks. Encryption is integrated because every metadata write is a fresh block anyway. Crash protection is automatic because partial writes are never visible.

Snapshots

An APFS snapshot is a read-only point-in-time copy of a volume’s metadata. Because copy-on-write already keeps old blocks until they’re explicitly freed, a snapshot just pins the old metadata B-tree at a given moment; the old blocks stay alive as long as the snapshot exists. Creating a snapshot takes essentially zero time and zero space.⁸

What snapshots are used for in practice:

• Time Machine local snapshots. Time Machine creates an APFS snapshot every hour on your local Mac drive, even when your backup disk isn’t connected. This is why Time Machine can let you “go back in time” to recover deleted files even without the external backup drive plugged in.
• System update protection. macOS creates an APFS snapshot of the system volume before every update. If the update fails or causes problems, you can revert to the pre-update snapshot from recoveryOS.
• Manual recovery snapshots. The tmutil localsnapshot command creates a snapshot on demand. Useful before risky operations or experimental software installs.

File and directory cloning

APFS can clone a file or directory by reference. Both the original and the clone point to the same underlying blocks; no data is duplicated. When either copy is modified, copy-on-write writes the changed blocks fresh, leaving the unchanged blocks shared. The Finder uses cloning when you Option-drag to copy within an APFS volume; the cp -c command exposes it on the command line.⁹

The recovery implication: a clone is not an independent backup. If the underlying storage corrupts in a shared region, both the original and the clone are affected. Cloning is for fast workflow operations, not for redundancy.

Native encryption (FileVault)

APFS was designed with encryption from the start, unlike HFS+ where it was bolted on. Every APFS volume on a T2 or Apple Silicon Mac is encrypted with a hardware-bound Volume Encryption Key (VEK), regardless of whether FileVault is “turned on” in System Settings. The VEK never leaves the Secure Enclave; it’s used by the SoC’s AES Engine to encrypt and decrypt data on the fly.¹⁰

What turning FileVault on actually does:

• Wraps the VEK with a Key Encryption Key (KEK).
• Wraps the KEK with the user’s password (and a hardware UID on T2/Apple Silicon).
• Requires the password at boot to unwrap the KEK, then the VEK, before macOS can decrypt the volume.

The recovery implication is severe: without the password (or recovery key), the data is mathematically inaccessible. Removing the SSD from a T2 or Apple Silicon Mac and connecting it to another computer reveals only encrypted ciphertext; the keys are physically bound to the original Secure Enclave. Apple’s whole-system architecture treats this as a security feature, not a bug.

Sealed System Volume (SSV)

Added in macOS 11 Big Sur (2020), the Sealed System Volume cryptographically hashes every byte of the system volume in a Merkle tree. The root hash, called a seal, is signed by Apple. At boot, the bootloader verifies the seal before mounting the system volume; mismatches halt the boot process.¹¹

The SSV is why you can’t modify /System files even as root, and why third-party kernel extensions are now strongly discouraged. For recovery purposes, it means the system volume is essentially uncorruptable in the conventional sense; if the seal verification fails, you reinstall macOS rather than try to fix the volume in place.

Space sharing and dynamic sizing

Already covered in the container section above, but worth restating in the features context: APFS volumes don’t have fixed sizes by default. The free space pool is shared across all volumes in the container, and each volume reports the container’s total free space as available (minus what other volumes have already used).

Crash protection without journaling

APFS achieves crash safety through copy-on-write checkpoints rather than journaling. Each metadata transaction completes atomically: either the new checkpoint is fully written and becomes the new state, or the old checkpoint is still the state. There’s no in-between, partial-write state that could be left after a crash. This is fundamentally different from NTFS or ext4, which both rely on journals to undo partial writes.

Compression and other inherited features

• Transparent file compression. APFS supports per-file compression using LZ algorithms (Deflate, LZVN, LZFSE). Inherited from HFS+ and used heavily for system files.
• Hard links to files. Same concept as on other Unix file systems. Note: APFS does not support hard links to directories, which is one reason Time Machine had to be redesigned for APFS.
• Up to 9 quintillion files. 64-bit inode numbers (2⁶³); there is no practical limit in 2026.
• Nanosecond-precision timestamps. Unlike HFS+’s 1-second resolution.
• Atomic safe-save. Apps can request that a write be atomic: either fully applied or not applied at all. Used by document-editing apps to prevent partial writes.

The three modern file systems for Mac, the previous Mac default, and the Windows default. Each represents a different design era and a different set of trade-offs.¹²

Property	APFS	HFS+ (Mac OS Extended)	NTFS
Year introduced	2017	1998	1993
Designed for	SSD / flash	HDD	HDD (modernized for SSD)
Crash protection	Copy-on-write checkpoints	Journaling	Journaling ($LogFile)
Snapshots	Native	No	VSS (limited)
Cloning	Native (instant)	No	No
Native encryption	Yes (FileVault)	Bolted on (FileVault 1/2)	Yes (EFS + BitLocker)
Metadata checksums	Yes	No	No
Container model	Yes (shared free space)	No	No
Max file size	8 EB	8 EB	8 PB practical
Max number of files	9 quintillion (263)	4.3 billion	4.3 billion
HDD performance	Poor (fragmentation)	Good	Good
Time Machine	Supported (macOS 11+)	Supported (all versions)	No
Cross-platform	Mac only	Mac (read-only on Win/Linux)	Read-only on Mac
Best for	Modern Mac SSD	Mac HDD, Time Machine	Windows internal

When to use each

Use APFS for: any modern Mac with an SSD (this happens automatically); SSD-based external drives used only with Macs; Time Machine backups on macOS Big Sur or later. APFS is the right choice for almost every Mac scenario in 2026.

Use HFS+ (Mac OS Extended) for: HDD-based external drives used with Macs (APFS performs poorly on spinning disks because copy-on-write causes fragmentation); Time Machine drives that need to be readable by older Macs (pre-Big Sur); Macs running macOS 10.12 Sierra or earlier.

Use NTFS for: any drive that will be used primarily on Windows. macOS can read NTFS drives but can’t write to them without third-party drivers like Paragon NTFS for Mac.

Use exFAT for: cross-platform external drives shared between macOS and Windows. Both operating systems read and write exFAT natively. See the exFAT entry for the trade-offs.

APFS’s metadata checksums catch most corruption immediately, which is good for early detection but bad in the sense that a single damaged checksum can make an entire structure unreadable. The container superblock and Object Map are particularly fragile because the file system depends on them for everything else.¹³

• Container Superblock (NXSB) corruption. The block at the start of the container that points to the Checkpoint Descriptor Area becomes damaged. Symptoms: macOS cannot mount any volume in the container; Disk Utility reports the disk as unrecognized or asks to initialize. APFS keeps a backup NXSB; recovery labs can restore from the backup, but consumer-grade tools often fail at this.
• Object Map damage. The B-tree mapping object IDs to physical block addresses becomes corrupt. The file system knows files exist (their metadata records reference object IDs) but cannot find their data. Disk Utility reports “fsroot tree is invalid” or similar messages.
• Checkpoint area corruption. The circular buffer of recent consistent states becomes damaged or out of sync. APFS may revert to an older checkpoint that’s still valid, but recent changes between the bad checkpoint and the previous good one are lost.
• Spaceman desync. The Space Manager that tracks free vs allocated blocks across the container becomes inconsistent. Symptoms: free space reported incorrectly (often as zero), file writes fail despite available physical space, or apparent allocation conflicts between snapshots and the live volume.
• Bad sectors hitting metadata pages. Physical bad sectors on the underlying SSD damage critical B-tree pages. Because APFS metadata is dense (many tree nodes per page), even single uncorrectable bit errors can render entire B-trees unreadable. SSD wear-related metadata corruption is a growing issue on aging Macs.
• Failed FileVault re-encryption. Turning FileVault on or off triggers a background re-encryption of the volume. Power loss or Mac sleep during this process can leave the volume in a partial state where some blocks are encrypted with the old key and some with the new. Recovery requires both keys plus knowledge of which blocks use which.
• Snapshot accumulation issues. Excessive snapshots (often from Time Machine running for years without space management) consume Space Manager entries and can trigger allocation conflicts. Deleting snapshots while the drive is degraded can corrupt the Space Manager further.
• Sealed System Volume (SSV) seal failure. The Merkle tree root hash doesn’t match the Apple-signed value, usually because of metadata bit-rot or tampering. Boot halts and prompts for macOS reinstall. Data on the Data volume is unaffected; only the system volume needs to be rebuilt.
• Accidental volume deletion. Deleting a volume from Disk Utility marks its space as free in the Space Manager. The data clusters survive intact until something else writes to them; recovery software can find the volume’s metadata and reconstruct files. Speed matters: every additional write to the container reduces recovery odds.

Warning signs your APFS volume is failing

APFS surfaces warnings clearly through Console messages and Disk Utility, but most users never check those until something goes wrong. Watch for these in combination:

• Disk Utility First Aid reporting “fsroot tree is invalid” or “the volume could not be verified completely.” Indicates Object Map or checkpoint damage. The volume may still mount but is structurally suspect.
• “Volume could not be unmounted” errors when First Aid runs. Often a sign of background processes accessing the volume, but persistent errors can indicate Space Manager inconsistency.
• macOS booting but applications crashing on startup. Sealed System Volume integrity issues or partial FileVault problems.
• Free space reported incorrectly. Space Manager desync. Common after force-shutdowns or during failed reformat operations.
• Slow Mac performance, especially when accessing files. APFS on a failing SSD is much slower than HFS+ on the same disk because every read involves checksum verification and B-tree walking.
• Snapshots that “won’t delete” through tmutil. Indicates Space Manager corruption interfering with snapshot cleanup.
• SMART warnings on the underlying SSD. APFS corruption is often the symptom of disk-level bad sectors or NAND wear; the file system is downstream of the hardware.
• Time Machine backups failing with “the backup disk could not be created” or similar errors. Sometimes Time Machine’s snapshot mechanism can’t run because of underlying volume issues.