In macOS Mojave and earlier, all Macs booted from a single integrated volume, containing system and user files arranged in directories based on those common to many Unix systems. That started to change in Catalina, when that volume was divided into two, System and Data, and continued in Big Sur, when macOS started booting from a specially sealed and signed snapshot, the Signed System Volume or SSV. Changes since Big Sur have been smaller and more subtle, with the introduction of the paired recovery system and cryptexes. This article guides you around the volumes and directories that compose the boot volume group in macOS 15 Sequoia.

Internal SSD partitions

All Macs are now intended to be started up from their internal SSDs through a secure boot process that tries to guarantee the integrity of all loaded code from the boot ROM and firmware through to the kernel and macOS. This is simpler in an Intel Mac, whose internal SSD is divided into two partitions, one for EFI, the other for the boot volume group.

Device names given here are examples, and those seen are likely to differ.

The boot volume group is composed of:

• The System volume, used to build the SSV, which is unmounted during normal running.
• The Signed System Volume, a signed and sealed snapshot of the System volume, containing the immutable System.
• The Data volume, by default named Macintosh HD – Data, mounted within the System directory tree, and writable by the user.
• The small Preboot volume, used to store cryptexes.
• The paired Recovery volume, containing a disk image of the Recovery system.
• The VM volume as the backing store for virtual memory.
• Possibly an Update volume that appears to have been used when upgrading to versions of Big Sur. This won’t be present on more recent Macs, and appears to have been disused since macOS 11.

The SSV is created from the System volume during macOS installation and update, and features a tree of cryptographic hashes verifying its integrity, and its signature to verify that its contents match those expected for that version of macOS.

To accommodate the more advanced secure boot of Apple silicon Macs, their internal SSDs are divided into three partitions, with an extra six volumes beyond the boot volume group.

Device names given here are examples, and those seen are likely to differ.

Apple silicon Macs have two Recovery systems: their primary Recovery is run from a disk image in the paired Recovery volume in the active boot volume group, as with Intel models. A previous version of that disk image is stored in the Apple_APFS_Recovery partition/container, where it’s available as the Fallback Recovery system, only in Apple silicon Macs. The contents of the Apple_APFS_ISC partition are small, and largely support secure boot with extended anti-replay technology (xART) for the secure enclave, and other internal features.

Another more curious difference between architectures is that the default name of the Data volume differs: in Intel Macs, it’s normally Macintosh HD – Data, while Apple silicon Macs use just Data.

Inside the boot volume group

macOS now consists of three components:

• the SSV, providing the root file system, and consisting of the main immutable components
• the Data volume, mounted within the root and linked to it by firmlinks, consisting of user-writable directories
• cryptexes, signed and sealed disk images mounted from the Preboot volume during the boot process, containing components that can be updated without creating a new SSV, notably including Safari and its supporting frameworks, shared caches for dynamic loading and, in Apple silicon Macs, those to support Rosetta 2.

These can be traced using the volume IDs and inode numbers of directories and files within the unified file system presented to the user, and summarised in the diagram below.

Volume IDs and inode numbers given here are only examples, and you’re likely to see different ones.

This shows the location of major directories across the three components, with those located in the SSV shown in pink, those of the Data volume in blue, and contributions from cryptexes in green. The effect of firmlinks and ‘grafting’ of cryptexes into the file system is now complex. One important example is how what appears to be the single top-level Applications directory is assembled from:

• bundled apps in the SSV, located in /System/Applications,
• user-installed apps in /Applications in the Data volume,
• Safari.app mounted from the Preboot volume in the App cryptex.

Although the SSV is identical in both Intel and Apple silicon Macs, the two architectures are now differentiated by their cryptexes. Those for Intel Macs contain only dyld shared caches with x86 support; those for Apple silicon Macs provide both ARM and x86 support, as well as AOT shared caches, for Rosetta 2.

Firmlinks

System firmlinks are still the same as listed previously in /usr/share/firmlinks and haven’t changed since Catalina:
/Applications <-> Applications
/Library <-> Library
/System/Library/Caches <-> System/Library/Caches
/System/Library/Assets <-> System/Library/Assets
/System/Library/PreinstalledAssets <-> System/Library/PreinstalledAssets
/System/Library/AssetsV2 <-> System/Library/AssetsV2
/System/Library/PreinstalledAssetsV2 <-> System/Library/PreinstalledAssetsV2
/System/Library/CoreServices/CoreTypes.bundle/Contents/Library <-> System/Library/CoreServices/CoreTypes.bundle/Contents/Library
/System/Library/Speech <-> System/Library/Speech
/Users <-> Users
/Volumes <-> Volumes
/cores <-> cores
/opt <-> opt
/private <-> private
/usr/local <-> usr/local
/usr/libexec/cups <-> usr/libexec/cups
/usr/share/snmp <-> usr/share/snmp
/AppleInternal <-> AppleInternal (on Apple engineering systems only)
in each case shown as the system volume path and the Data volume path which are firmlinked together.

Directory layout

Given the volume ID and inode numbers of directories and files, together with that list of firmlinks, it’s possible to construct a full directory tree for the conjoined SSV, Data volume and cryptexes. A simplified version of that is in the diagram below.

This uses the same colour convention, with pink for the SSV, blue for the Data volume, green for cryptexes, adding red for the mountpoint of the Data volume, and yellow for firmlinked items. This demonstrates graphically how the contents of the main Applications folder are gathered from three sources.

Previous boot volume architectures from High Sierra to Monterey are explained here.

My previous explanation of how recent versions of macOS merge their System and Data volumes into what appears to be a single volume, omitted a third component, including Safari. Look in the System/Applications folder where all the bundled apps are stored on the SSV, and there’s no Safari to be seen, yet it appears in the top-level Applications folder. This article explains how that now works using cryptexes, and how they differ between Intel and Apple silicon Macs.

Finding Safari

As the modern boot volume group evolved through Catalina to Big Sur, Safari and its supporting frameworks were stored in the Data volume. That stopped with the arrival of Ventura, and they’re now stored in the third components that complete the modern boot volume group. You can see when files are stored on a different volume using my free app Precize to reveal their full paths. Use that to examine three apps from the merged Applications folder, and you’ll understand what I mean:

• Chess.app has a path of /System/Applications/Chess.app demonstrating that it’s one of the apps bundled in the SSV, where almost all of the System folder is stored.
• Cirrus.app, like any other app you have installed, has a path of /Applications/Cirrus.app, making it clear that it’s stored on the writable Data volume.
• Safari.app has the weird path of /System/Volumes/Preboot/Cryptexes/App/System/Applications/Safari.app that demands further explanation.

Note that the Finder’s Get Info dialogs aren’t as truthful, and don’t tell the full story.

Their volfs paths are also worth noting. On my Intel Mac, they are:

• Chess.app is at /.vol/16777240/1152921500311883667; because all macOS 14.6.1 SSVs are identical, your Chess.app should have the same inode number too.
• Cirrus.app is at /.vol/16777240/461665725
• Safari.app is at /.vol/16777238/993517

The first two follow a familiar pattern you’ll see throughout the System and Data volumes: their volume ID 16777240 is common to both, and that assigned to the merged volumes, but their inode numbers are wildly different. Huge numbers like 1152921500311883667 come from the SSV, while smaller ones like 461665725 are from the Data volume. Then there’s a slightly lower volume ID of 16777238 and a small inode number of 993517 for Safari, demonstrating that it’s somewhere altogether different: that’s a cryptex, a cryptographically protected disk image with an interesting history.

Why a cryptex?

When the modern boot volume group was being designed and developed, it took into account Safari’s special needs by making it the only bundled app to be stored in the Data volume. This enables it to be updated without having to go through the whole process of building a new SSV, allowing Apple to deliver urgent security patches to Safari and its underlying WebKit and other frameworks. There could also have been political considerations in separating Apple’s bundled browser from the other apps included in macOS.

This changed in Ventura in the autumn/fall of 2022, when Apple applied technology it had originally developed for its customised iPhone, the Security Research Device, dubbed the cryptex, a name formed as a portmanteau for CRYPTographically sealed EXtension. This offers two advantages:

• Safari, its supporting frameworks, and other components of macOS that Apple prefers not to build into the SSV, can be delivered in cryptexes. As I’ll explain later, this also enables tailoring of macOS to platform.
• Some urgent security patches could be delivered in cryptexes, making them faster to release and simpler to install in a Rapid Security Response (RSR).

Since then, RSRs seem to have had their day, and appear to have fallen from favour. But, as a means of delivering Safari and other more changeable components of macOS, cryptexes have proved their worth.

How a cryptex works

Although a cryptex is at heart a read-only disk image that is mounted during the boot process, it has two properties of particular importance:

• Its contents are cryptographically verified, in much the same way that the contents of the SSV are, using hashes of its entire contents.
• Its internal file system is grafted into the root file system when it’s mounted, rather than being mounted as a separate volume.

Mounting a cryptex starts with validation of the payload and its manifest. It then undergoes a sequence of processes similar to the mounting of an APFS volume, with a checkpoint search to establish stable checkpoint indices, and a check to discover whether there’s anything to recover, which seems unlikely. The graft is then performed in a series of opaque steps, with root hash authentication and validation. The object ID is found, and the graft completed.

Once this has been completed for each of the standard cryptexes and any installed RSRs, the contents of those are effectively part of the system, as a hybrid of the SSV and cryptexes. In the case of the Safari app, this process effectively places it in the main Applications folder, even though the original app is actually located in the System/Applications folder of the App cryptex in /System/Volumes/Preboot/Cryptexes.

As with the current boot System and Data volumes, grafted cryptexes aren’t unmounted or ungrafted until shutdown.

There are currently three main cryptexes in use, App containing Safari, its frameworks and other supporting files, and OS, with a range of other system items including additional frameworks, and several large dyld shared caches. You’ll also see an Incoming cryptex in /System/Volumes/Preboot/Cryptexes. As they’re outside the SSV, new and replacement cryptexes are installed without rebuilding the SSV, and in some cases don’t even need a soft restart of macOS.

Architecture-specific cryptexes

In addition to providing Safari and its related components, cryptexes also provide useful economy in shared caches, and explain why macOS updates for Apple silicon Macs are invariably larger than those for Intel models.

While the contents of the SSV appear to be identical on both Intel and Apple silicon, thus have a single signature, the two architectures differ in their cryptexes. Those for Apple silicon Macs contain dyld shared caches for both architectures, and a set of aot shared caches, presumably to support Rosetta 2, and amounting to 5.24 GB in total size; those for Intel Macs only contain Intel dyld shared caches of 1.68 GB total size.

Given their sizes, that’s a valuable efficiency both for updates and in storage required, and is the major reason for updates for Apple silicon Macs always being larger than those for Intel. Thankfully, because those shared caches are supplied compressed, the difference in update sizes is much smaller than the 3.56 GB difference when they’re decompressed and installed.