On macOS 11 and later, the startup disk holds a read-only System volume and a writable Data volume that nonetheless appear as one directory tree. What joins them, and how is the System volume protected from modification?

## The problem being solved A traditional Unix root filesystem mixes two very different kinds of content: the operating system, which should be identical on every machine and should never change except during an update, and everything else — users, applications, configuration, logs — which is unique to the machine and changes constantly. If they share one writable volume, you cannot state what the running OS is, verify that it has not been tampered with, or roll it back cleanly. Apple split them. macOS 10.15 Catalina moved the OS onto its own read-only **System volume** and everything else onto a **Data volume**; macOS 11 Big Sur added the cryptographic seal that turns "read-only" into "provably unmodified". ## The volume group The two volumes are not independent. They form an APFS **volume group** inside the same container: they share the container's free space, they are unlocked and mounted together, and tooling treats them as one startup disk. The Data volume's real mount point is `/System/Volumes/Data`, and `df` will happily show you both — with the same available figure, since they share a container. ## Firmlinks A volume group would be awkward if the split were visible in every path, so APFS provides **firmlinks**: bidirectional links between a directory on the System volume and its counterpart on the Data volume. Walking into `/Users` transparently lands you on the Data volume; the tree looks exactly like the single filesystem everyone's muscle memory expects. Three properties matter for an interview: 1. **They are declared, not created.** The set lives in `/usr/share/firmlinks` as a table of path pairs, established by the OS. Users and administrators cannot add firmlinks of their own. 2. **They are bidirectional**, unlike a symlink's one-way redirection, which is why the merge is seamless in both directions rather than a set of redirects programs can trip over. 3. **They are scoped to a volume group.** This is not a general-purpose linking feature you can point at any volume. A symlink would have been visible to every program and easy to defeat; a mount would have shown up in the mount table and been remountable. Firmlinks make the split a property of the filesystem layout itself. ## The Signed System Volume Read-only alone would only stop accidents. The **Signed System Volume** makes the system's contents *verifiable*: the System volume's data and metadata are hashed into a tree, the root of that tree is a seal signed by Apple, and boot verifies the seal before handing control to the system. If a single block differed from what was signed, verification fails. The last piece is the one candidates miss: what gets mounted at `/` is not the sealed volume but a **read-only APFS snapshot** of it. Because a snapshot is immutable by construction, the running system is pinned to exactly the state that was verified — there is no window in which the live volume could be remounted writable underneath a running system. ## What this means in practice **Root cannot write to `/`.** `sudo` does not help, because the restriction is not a permission check — the mounted filesystem is read-only. Software that historically dropped files into system directories had to move to `/Library`, `/usr/local` or a user-space prefix; this is a large part of why third-party tooling on macOS installs outside the system tree. **Updates become atomic and reversible.** An update builds a new system volume state and blesses a new snapshot to boot from. If it fails, the previous snapshot is still there and still valid. **Deliberate modification is possible but heavyweight.** Changing the system means booting to Recovery, disabling the protection, mounting the system volume writable, making the change, blessing a new snapshot and rebooting — and the volume is no longer sealed. The friction is intentional: it converts an easy, silent change into an auditable, reboot-bound one. **Migration and backup tooling had to learn the split.** "Copy the startup disk" now means understanding volume groups, and cloning tools rely on Apple's replication mechanisms rather than a plain file copy of `/`. ## Contrast worth drawing If an interviewer is probing your general OS knowledge, the comparison to reach for is any immutable-OS design: a verified, read-only system image plus a separate writable state area, with updates delivered as whole new images rather than in-place edits. Apple's version happens to use APFS snapshots and firmlinks to keep the result looking like an ordinary Unix root.