PUNCHCARD Get Punchcard $9

Where Mac apps keep your data, and how to find it

· 6 min read

Nearly everything a Mac app knows about you lives in your home folder’s hidden Library: ~/Library/Application Support for databases and documents, ~/Library/Preferences for settings, ~/Library/Caches for temporary files, and ~/Library/Containers for apps that run in the App Sandbox. Open Finder, choose Go, Go to Folder, type ~/Library and you are there. Here is what each folder holds, how to find the pieces that belong to one app, and how to read what you find.

Opening the Library folder

Apple hides ~/Library by default. Three ways in:

  1. In Finder, choose Go, then Go to Folder (or press Shift-Command-G), type ~/Library and press Return.
  2. In Finder, hold the Option key while opening the Go menu. Library appears in the list.
  3. In Terminal, open ~/Library.

To make it permanently visible, open your home folder in Finder, press Command-J to show view options, and tick Show Library Folder.

There is also a system-wide /Library at the root of the disk, used by installers and background services for all users, and /System/Library, which belongs to macOS. App data about you is almost always in ~/Library, the one in your home folder.

The folders that matter

Inside ~/Library, these are the ones where apps put data about you. Apps are identified either by name or by bundle identifier, which looks like com.developer.appname.

Application Support. The main one. Databases, saved documents, user content, licenses. Look for a folder named after the app or its bundle identifier. Punchcard, for example, keeps its entire record in one file here: ~/Library/Application Support/Punchcard/punchcard.sqlite. That single file is every day it has recorded.

Preferences. Settings, as .plist files named by bundle identifier (com.developer.appname.plist). Usually window positions, toggles and recent items. Occasionally something more, such as an account name or a license key.

Caches. Temporary files an app can rebuild: thumbnails, downloaded images, partial data. Safe to delete, and often surprisingly large. Named by bundle identifier.

Containers. For sandboxed apps, which includes everything from the App Store. Each app gets a folder named by bundle identifier, and inside it a Data folder that mirrors a miniature home directory: Data/Library/Application Support, Data/Library/Preferences, Data/Documents. If you cannot find an app’s data in the top-level Application Support, look here.

Group Containers. Shared storage for apps from the same developer (an app and its extension, or a suite). Named by a team identifier and a group name.

Saved Application State. Window layouts and unsaved document state, so an app reopens where you left it. Named by bundle identifier with .savedState. Can contain snapshots of window contents.

Logs. Diagnostic logs an app writes. Sometimes named by app, sometimes by developer. Worth reading once; logs are where apps are most candid about what they are doing.

HTTPStorages and Cookies. Cookies and web storage for apps that embed web content or make web requests, named by bundle identifier.

LaunchAgents. Not data, but important: the list of background programs that start when you log in, as .plist files. An app with an entry here is running even when you have not opened it.

Keychains. Not browsable as files. Passwords, tokens and license keys an app stored securely. Search Spotlight for Keychain Access to look inside.

How to find everything one app has written

  1. Get the app’s bundle identifier. In Terminal: osascript -e 'id of app "Example"' prints it. Or open the app’s .app bundle (right-click, Show Package Contents), open Contents/Info.plist, and look for CFBundleIdentifier.
  2. In Finder, open ~/Library and search for the identifier. Press Command-F, make sure the search scope is the Library folder rather than This Mac, and type the identifier. Also search for the app’s plain name, since Application Support folders often use it.
  3. In Terminal, for a thorough sweep: find ~/Library -iname "*example*" 2>/dev/null with the app name, then again with the identifier. This lists every file and folder whose name matches.
  4. Check Containers and Group Containers by hand, since their contents use the identifier only at the top level.
  5. Check LaunchAgents in ~/Library and in /Library for the identifier, to see whether the app runs in the background.
  6. Search Keychain Access for the app or developer name.

Write the list down. It is the map you need both to understand what the app keeps and to remove it completely later (see how-to-delete-everything-an-app-knows-about-you.html).

How to read what you find

Most of what apps store is in a few formats, all readable with built-in tools.

  • .plist files. Double-click to open in the system’s property list viewer if you have developer tools, or in Terminal run plutil -p ~/Library/Preferences/com.developer.appname.plist to print it as readable text. Alternatively defaults read com.developer.appname.
  • .sqlite or .db files. SQLite databases. Terminal has sqlite3 built in: sqlite3 ~/Library/Application\ Support/Example/data.sqlite ".tables" lists the tables, and SELECT * FROM tablename LIMIT 20; shows rows. Copy the file first and open the copy, so you never touch the live database while the app is running.
  • .json, .log, .txt. Plain text. Open in any editor or cat them in Terminal.
  • Anything you cannot open. An opaque format in an app’s folder is not suspicious by itself, but an app that stores your activity in a format only it can read is one you cannot audit. Prefer apps that store in open formats or offer an export.

Opening Punchcard’s database with sqlite3 shows what the app has: app names, timestamps and durations, plus the receipts it has printed. No window titles, no document names, no URLs, because the app never had them. It also offers a CSV export from Settings, for the same records in a spreadsheet-friendly form, and a “Burn the roll” command that deletes the file. There is more on the export in export-your-time-data-to-csv-and-keep-it-forever.html.

What is not in ~/Library

Some app data lives elsewhere, and it is worth knowing where to look when the Library search comes up short.

  • Documents you saved. Wherever you saved them: Documents, Desktop, iCloud Drive. Apps do not usually copy these into Library.
  • iCloud data. ~/Library/Mobile Documents holds iCloud Drive, including per-app folders for apps that sync through it. It is also on Apple’s servers.
  • Data on the developer’s servers. Anything an app syncs or uploads is not on your Mac in a form you can find. The Library shows you the local copy only. If an app has an account, assume there is a remote copy that the Library search cannot reveal.
  • Package receipts. Apps installed with an installer package leave a record at /var/db/receipts and in pkgutil --pkgs, which lists what was installed where.

The difference between an app that keeps everything in ~/Library and one that also keeps a copy on a server is the difference between data you can find and delete yourself and data you have to ask for. It is one of the more useful things to know about an app before you depend on it.

Questions

Is it safe to delete things in ~/Library?

Caches, yes, any time. Preferences, usually, at the cost of resetting the app’s settings. Application Support and Containers contain the app’s actual data, so deleting those removes whatever the app stored (notes, records, licenses). Quit the app first, and keep a backup until you are sure.

Why can I not find an App Store app’s data in Application Support?

Because sandboxed apps are confined to ~/Library/Containers//Data, which has its own Application Support inside. Look there.

An app’s folder is several gigabytes. What is in it?

Often caches that the app placed under Application Support instead of Caches. Sort the folder by size in Finder to find the culprit. If the large item is a database, the app is keeping a long history, which may or may not be what you want.

Can another app read these folders?

Application Support, Preferences and Caches in your home folder are readable by any non-sandboxed app you run, without a permission. Containers are protected from other sandboxed apps. This is one reason to be thoughtful about what you store in plain files and why sensitive tokens belong in the Keychain.