Catalina’s read-only system volume

APFS is still a young filesystem, and Apple is still adding new features (and new OS features that rely on underlying APFS features) at a steady clip. Mojave mostly brought minor updates to the filesystem but mostly focused on completing the transition, enabling APFS for Macs with Fusion Drives and improving performance on spinning hard drives. Now that the transition is all done, Catalina focuses on larger additions.

Longtime readers of these reviews will probably remember System Integrity Protection (SIP), a feature added in macOS 10.11 El Capitan that disables write access for the /System, /bin, /usr/ and /sbin system folders by default. Catalina takes this a step further, creating a separate read-only APFS volume exclusively for system files—including not just the SIP-protected folders, but all system files and most of the preinstalled apps. A new Catalina install with a single user account has around 10GB of data on its system volume and another 4 or 5GB in the user data volume.

If you’re the kind of person who prefers or needs to disable SIP to work with system files and folders, you can still do that, but Catalina throws up another barrier. While SIP’s protections could be disabled permanently from your Mac’s recovery partition, disabling read-only access to the Catalina system partition is reset every time you reboot. SIP and the read-only system volume are related features, but they’re not the same—to access system files, you need to disable SIP from the recovery partition, and then you can mount the system volume as read/write from within Catalina.

This volume split is permanent and mandatory, and much like the APFS conversion itself it happens transparently in the background when you update from High Sierra or Mojave to Catalina. As outlined in a WWDC presentation about this year’s APFS updates, your current system volume is marked as a data volume, and system files are deleted, leaving your data intact. From there, a new system volume is created in your APFS container, and the majority of the Catalina system files are written there instead. That new volume is marked as read-only as soon as the installation is complete.

Volume groups, firmlinks, and why most people won’t notice any of this stuff

To the typical Catalina user who doesn’t notice or care about filesystems or partition maps, they won’t notice a difference. Finder (and even the default “show only volumes” view in Disk Utility) still show a single unified disk with everything on it. It’s only once you go to “show all devices” that you can see the APFS container with the system and data volumes split apart.

Because of the way APFS works, you don’t give up any disk space by separating the system and data volumes. Splitting the volumes in a similar way using HFS+ would likely require at least some small amount of free space on your hard drive, since the system volume would need to claim a bit more space than strictly necessary to leave room for system updates and other temporary files. But because all volumes within an APFS container can lay claim to all the free space within that container, the Catalina system and data volumes can comfortably coexist without wasting drive space, just as they have always done when they lived in the same volume.

And many of Apple’s changes to APFS in Catalina are done in service of hiding this volume split. Your Catalina system and data volumes aren’t quite the same as two typical APFS volumes—they’re part of something new called a Volume Group, which helps the operating system treat the two volumes in some of the same ways that Mojave and previous versions of macOS treat the unified system and data volume. Not only do the two volumes appear as one in the Finder, but they share things like FileVault encryption keys—the two volumes are encrypted (or decrypted) simultaneously and the same key unlocks them both.

APFS in Catalina supports something called “firmlinks,” as a way to maintain macOS’ existing directory structure despite everything now being spread across two volumes. Think of an alias in macOS or a shortcut in Windows—these are forms of symbolic links (or symlinks), small files that can be stored anywhere and which point you toward another file on another volume, partition, or disk. But where symlinks only go one way, firmlinks are bidirectional. Folders can appear in multiple places, but from the Finder’s perspective and the user’s perspective, neither directory is the “real” one and neither is the “shortcut.”

You can easily see this in action on any Mac running Catalina if you navigate to the /System/Volumes folder, where you’ll spot what appears to be the same “Macintosh HD” icon that you normally see on your desktop. But this is actually a representation of your data volume, and there are a few ways to tell:

The System folder in this volume is mostly empty, since those files are primarily stored in the read-only system volume

Under “Name and Extension” in a Get Info window, the volume’s name is literally “Data”

This folder’s path in Terminal is /System/Volumes/Data.

This is where firmlinks come in. Look at the contents of either /Applications or /System/Volumes/Data/Applications, and you’ll see that the only applications actually stored in that folder are the ones you’ve installed yourself, plus Safari (presumably to make the browser easier to update on its own without a major system update). But the Finder still shows the user their installed applications plus all of the regular macOS system apps in the same folder.

According to Apple, firmlinks only exist for directories, not individual files, and they only work within established volume groups like the one Catalina creates when you install it on your system. At least for now, all firmlinks that exist on a Catalina Mac are created by the system at install time and can’t be created manually by end users. For people who want to make shortcuts, one-way symlinks that can point to things on other volumes continues to be Apple’s recommended solution.

The new volume structure will create some extra work for the developers of third-party backup apps like Carbon Copy Cloner—that app has already made changes to support Catalina, though the downside is that Catalina Macs aren’t going to be able to back up to HFS+ volumes anymore. But the read-only system volume is a logical extension of the protections that SIP was already providing to most important system folders. It’s a thing that advanced users can turn off, albeit temporarily, and it will be completely invisible and irrelevant to the vast majority of Mac owners, just like separate system and data partitions are already invisible and irrelevant to iPhone and iPad owners.

FileProvider API

When Apple introduced the Files app in iOS 11, it added a new API called FileProvider that allowed third-party storage services like Dropbox, Google Drive, and OneDrive to show up in the Files app with most of the same privileges and features as iCloud. Catalina brings that same API to the Mac, giving cloud storage providers a more consistent, unified way to show up in the Finder alongside iCloud and the user’s local files. Also as with iCloud, third-party cloud services will be able to sync files on demand, showing them in the Finder but only actually downloading them (and taking up disk space) when they’re actually needed.

The difference between iOS and macOS in this regard, of course, is that these services already exist and have been syncing their files just fine for years now, and most of them offer some version of the files-on-demand feature (Dropbox calls it Smart Sync, OneDrive calls it Files On-Demand). Whether third parties switch to using the FileProvider API probably has more to do with Apple’s security restrictions than with the features of the API. And it’s not clear whether developers would be able to add features like dedicated menu bar icons or Finder context menu entries.

For example, Dropbox currently needs to request a dizzying level of permissions to do everything that it wants to do in macOS, and installing it with Smart Sync enabled requires multiple trips to System Preferences to override macOS’ default security settings. If users complain about that sort of thing enough, or if Apple just makes it easier to develop and maintain a FileProvider app than one that syncs using some other mechanism, then maybe we’ll begin to see developers adopt it.

New (and sometimes annoying) system security measures

Catalina includes a few new security restrictions for both users and developers, though they mostly represent a tightening of screws that were already present and not a dramatic escalation.

Like Mojave, Catalina introduces a few new access controls—capabilities or directories that apps need to clear with the system before they can access them. Apps must now ask you before they can use speech recognition features, monitor or record keyboard input, or record your screen. And apps need to ask for access to specific user folders or volumes—Documents, Desktop, and Downloads are all protected, as are folders from cloud storage providers and removable and networked drives. You’ll notice new permission requests from any app that can send notifications—there’s a toggle in the Notifications preference pane that lets you turn notifications on or off on an app-by-app basis, too.

App notarization is more onerous, both for users and for developers. This feature was introduced as an optional extra step in Mojave. Going all the way back to Mountain Lion, Mac developers offering apps outside of the Mac App Store could use their Apple-issued developer certificate to tell macOS that their app was from a registered Apple developer. In exchange, the app would run with minimal interference from Gatekeeper, the then-new feature that promised to keep Mac users safe from malware. Apps that didn’t use Developer ID could run, but you’d either need to turn Gatekeeper off or right-click the app and open it again to allow an exception.

The notarization process is a bit more involved. It requires developers who want to distribute outside the Mac App Store to submit apps to Apple for review by its Notary Service—this isn’t the same as the actual content review process used to allow apps into the Mac App Store but a shorter and more automated process that should only take a few minutes. The Notary Service checks to see whether the app contains malware; whether it uses the enhanced System Integrity Protection runtime from Mojave that protects running apps from being tampered with; and whether the apps and all their components are properly signed in the first place.

Notarization, like Developer ID, isn’t strictly necessary—non-notarized apps will still run on macOS, one crucial point on which macOS continues to differ from iOS and iPadOS. But to run (at least the first time) without triggering Gatekeeper and scary security warnings, all apps running on Catalina must be notarized. And starting in January of 2020, apps will need to meet new Catalina-specific notarization requirements (these were originally supposed to go into effect when the operating system was released, but Apple relaxed them just a bit to give devs more time). This Electric Light Company post on notarization covers the requirements and the difference between Mojave and Catalina in more detail.

The accumulation of these security features can make Catalina pretty annoying to use sometimes, especially if it’s a clean install of the operating system. Downloading, installing, and running an app becomes a multi-step process:

Assuming you’re using Safari to download the file, you’ll need to grant the domain access to your Downloads folder, permission that every new domain you download from asks for individually.

When running the app for the first time, let Gatekeeper know that, yes, you would like to run the application you just downloaded from the Internet. Apps that haven't been notarized trigger extra prompts and may require a trip into System Preferences to allow the code to run.

If the app supports notifications, it will request permission to show you notifications (via a notification).

As apps need access to hardware like your webcam or microphone, or to various folders on your Mac, they will pop additional access request boxes up as needed.

Now imagine this series of steps, but multiplied across however many apps you use. Especially earlier in the Catalina beta when Apple was enforcing the stricter notarization requirement (but before most developers had bothered with it), setting up a new Catalina Mac prompted an avalanche of notifications just to get everything working properly. And that’s before you get into older apps that don’t know how to request access to things and get broken when the system won’t let them access what they need.

But notification fatigue is real. To someone who is paying attention to what all of these alerts and confirmation dialogs say and acting accordingly, it’s a good thing for your computer to be asking you explicitly about so many things. It reduces the likelihood that a rogue site or app will do something you don’t want it to. But for this many notifications across this many apps, I’ve got to imagine that more than a few people will either blindly click through these messages to get what they want, or they might refuse permission (on purpose or by accident), requiring a trip into the Security & Privacy preference pane to manually grant the app whatever permissions it was asking for. This is something that Apple actually mocked Microsoft for, back in the days when Windows Vista’s User Account Control was seen as annoying overkill rather than a normal fact of life.

The good news is that, once you’re up and running and you’ve gotten all of your apps to run at least once and given them all the permissions they need, Catalina works just about like all other Mac versions have. And the short reprieve for the stricter notarization requirements will hopefully give most major app developers some time to get their apps notarized to prevent some of these problems (seriously, this section of the review was considerably more irritated when the newer notarization was required to keep Gatekeeper quiet).