In this article
Open the two locations in Finder
Press Shift–Command–G in Finder and enter one path at a time:
~/Library/Containers~/Library/Group Containers
The tilde means your current user’s home folder. It matters: /Library without the tilde is a different location. Apple documents this navigation in Go directly to a specific folder.
For an initial investigation, record the path you are looking at. Do not move anything yet. Your question is “which app or shared group uses this?” before it is “how much space can I reclaim?”
Finder may present a friendly name instead of the underlying identifier. Use the path and the installed app’s metadata together rather than relying on a label that happens to look familiar.
What the two folders mean
| Location | Relationship to look for | What the name does not establish |
|---|---|---|
~/Library/Containers | A sandbox container associated with an app | That every file the app uses is inside it |
~/Library/Group Containers | A shared container identified by an app group | That only one installed app depends on it |
| A folder left after uninstalling | A possible surviving data store | That the data is backed up, unused, or safe to remove |
Apple’s App Sandbox documentation explains that macOS creates an app’s container at first launch. Sandboxed apps can also access some files outside it through supported mechanisms, including user-selected documents. A container is therefore a useful boundary, not a complete inventory of an app’s footprint.
App groups let related apps and extensions share storage. An app can belong to several groups. Group names may use the group. prefix or a developer-team-based identifier; do not expect every group folder to resemble the main app’s name.
A checked example: Notes and Reminders
We inspected the installed application metadata on macOS 15.7.5 on September 28, 2026. This was a read-only check of two Apple app bundles and the existence of specific directory paths. We did not open notes, reminders, databases, or attachments.
| App and version | Bundle identifier | App groups declared in its signature |
|---|---|---|
| Notes 4.12.7 | com.apple.Notes | group.com.apple.notes; group.com.apple.notes.import |
| Reminders 7.0 | com.apple.reminders | group.com.apple.reminders |
Both corresponding app-container paths existed on this Mac. The main Notes and Reminders group-container paths also existed. The path for group.com.apple.notes.import did not exist at the time of the check.
That last observation is the useful distinction. A declaration in an app signature and a directory observed on disk are different pieces of evidence. You cannot count declared groups and assume that many folders must already exist.
This small sample does not identify every process that can use those groups, establish what any directory contains, or recommend deleting either app’s data. Different versions and user histories may produce different results.
Match a folder to an installed app
Start with an app you already recognize. In Finder, locate its actual .app bundle, rather than a downloaded installer or an alias. For readers comfortable with Terminal, these commands display metadata from the installed Notes example:
- Read the identifier:
/usr/libexec/PlistBuddy -c 'Print :CFBundleIdentifier' /System/Applications/Notes.app/Contents/Info.plist - Read signed declarations:
/usr/bin/codesign -d --entitlements :- /System/Applications/Notes.app
The first command supplies the bundle identifier. In the second output, look for com.apple.security.application-groups. These commands inspect the bundle; they do not modify it or grant access to its files.
Use the result to form a specific comparison: “this app declares this group, and this folder has that identifier.” Do not turn it into a stronger claim such as “this is the only owner.” Another app, extension, or supporting process may participate in the same group.
If you cannot find a match, preserve the folder and consult the developer’s support documentation. An unfamiliar identifier is an unresolved association, not evidence of malware.
For the related distinction between code declarations and user decisions, see entitlements versus current macOS permissions.
Check shared dependencies before removal
Use this short worksheet before acting on a suspected leftover:
- Record the exact path. Separate the app container from every group container you are considering.
- Name the app you removed. Keep its version or installer information if you have it.
- List related software still installed. Include the developer’s other apps and any extensions you still use.
- Locate the data you need to retain. A settings reset and the loss of a local-only document are very different outcomes.
- Check the developer’s uninstall instructions and your backup. If either leaves shared storage unclear, pause that removal.
This is a review checklist, not a deletion test. A folder’s size, old modification date, or survival after uninstalling does not answer every question on it. Likewise, a cloud account is not evidence that every local item has synced successfully.
If the path is actually in Application Support, use the separate Application Support review guide. If your starting point is a package installer, package receipts provide another kind of installation evidence.
When a file-inspection app helps
VaultDog can show app metadata, associated files, and paths you can reveal in Finder. Its released scanner checks common container locations, including Group Containers. That can help you collect leads when several similarly named files are involved.
Treat those associations as starting points for the worksheet. They do not prove exclusive ownership or guarantee that removal is safe. For one clearly identified folder, Finder and the app’s own documentation may already be enough.
The next useful action is to keep a record of the association you established: the app identifier, the group identifier, and the exact path. When shared use remains uncertain, leaving the data in place preserves your options.
