If you’ve ever snooped inside the hidden Library folder in your Home folder, I’m sure you’ve come across two strange folders there, Containers and Group Containers, and maybe even a third, Daemon Containers. This article explains what they are, why they’re there, and how they’re changing.

What?

Look inside any of the folders within those Container folders and you’ll see a single property list, and a folder named Data, inside which is a miniature Home folder, complete with Desktop, Documents, Library and other folders, just like a copy of most of your Home folder.

Here’s one I made earlier using one of my SwiftUI demo apps named ContentTypes. The .com.apple.containermanagerd.metadata.plist file alongside Data sets out the configuration of the Container, and reveals what these Containers are for in its references to the app sandbox. It also refers to the app’s entitlements, including the essential com.apple.security.app-sandbox that determines the app runs in the sandbox.

Look more carefully at those folders inside Data and you’ll see that most of them are in fact aliases to their originals in your (real) Home folder. One that invariably isn’t is in the path [app name]/Data/Library/Preferences, which should contain aliases to at least two property lists, com.apple.security_common.plist and com.apple.security.plist. It may also contain that app’s preference settings in a property list named according to the app’s name. If it does, then you’re not going to find the app’s preferences in the regular Preferences in your Home folder Library.

Given all the aliases involved, what at first looks like a large hierarchy of folders turns out to be small.

These days, macOS gives it a custom folder icon, and locks everyone else out with No Access in its permissions.

The contents of Group Containers are a bit different. They’re named according to the developer ID and the full name of an app group, and contain just a Library folder. Daemon Containers are named by the UUID of the daemon concerned, and have the Data folder as in regular Containers.

Why?

All apps, with very few remaining exceptions, obtained from the App Store, and some others, are run in an app sandbox. The idea behind this is that by isolating the app from everything else, even if it turns out to be flawed or malicious, it can do no damage except to its own files and data. Of course such an app would also be unable to do anything of use: it couldn’t edit documents in your normal Documents folder, connect to the network or internet, and so on. Each sandboxed app therefore has entitlements that determine exactly what it is allowed to do outside its sandbox.

The first time you run a sandboxed app, that’s one with the sandbox entitlement com.apple.security.app-sandbox, macOS automatically creates it a Container, which is effectively the hierarchy of files and folders that the app has exclusive and unrestricted access to. If the app is to have any access beyond its Container, then it must have an appropriate entitlement or obtain permission to do so. An app’s Container migration manifest determines the files the app needs to be moved to its Container when it’s first created, and the developer can add that to the app bundle’s Resources folder in a file named container-migration.plist.

Sandboxed apps are normally given a Container of their own, that’s stored in the Containers folder. Those in Daemon Containers are for sandboxed helper services, while those in Group Containers can be shared across more than one sandboxed app.

Changes

Because a sandboxed app’s Container holds its files and data, it’s a prime target for unfriendly or even blatantly malicious apps that want to steal your private data. macOS Sonoma and Sequoia have therefore introduced protection to block that. In Sonoma, macOS associates an app’s code signature with its Container. If a different app tries to access the contents of that Container, then the user is asked whether to allow that access. This also applies to those for helper services in Daemon Containers.

Mickey Jin has explored this in depth. In Ventura and earlier, Apple had already started protecting containers owned by certain apps prone to exfiltration by malware, such as Notes and Safari. In Sonoma these are covered by a new privacy category described in alerts as access to “data from other apps”. Mickey has identified vulnerabilities in this, one of which has been addressed in 14.6, the other awaits 15.0.

Sequoia extends this protection, based on System Integrity Protection (SIP), to cover Group Containers, which can only be accessed by apps identified as being members of that group, thus have been given shared access.

Housekeeping

Although its Container is created automatically when a sandboxed app is first run, there’s no feature that removes that Container when that app is uninstalled or removed. While that might appear an attractive proposition, it could easily delete files and data that are still required, making manual removal the only safe option. As your Containers folder might have a thousand or more folders in it, and many of them may not be readily associated with specific apps, cleaning them out appears to be an unsolved problem at present.

Summary

• Folders in ~/Library/Containers are sandbox containers for apps, and shouldn’t be removed or tampered with unless you’re sure you know what you’re doing.
• Those for helper services are in ~/Library/Daemon Containers, and those shared across apps in the same group are in Group Folders.
• Preference settings for sandboxed apps are therefore likely to be found in [App Name]/Data/Library/Preferences rather than in ~/Library/Preferences.
• Containers and Daemon Containers are protected in Sonoma, and Group Containers in Sequoia.
• Although Containers are created automatically by macOS, removing them requires care to avoid data loss.
• If in doubt, leave Containers well alone.