A Mac app is usually more than the .app file in Applications. Its settings, databases, documents, accounts, and caches can be spread across several folders.

I check the app’s own backup or migration documentation first. When the app does not document its storage, these are the places I inspect before changing anything.

Quit the app and make a backup before moving, replacing, or deleting its files. Quit any menu bar item or helper belonging to the app too. A file that looks disposable may be the only copy of a database, licence record, or unsynced work.

Start with files you chose

Documents that I create and save are not necessarily inside the app’s private data folder. They may be in:

  • Documents, Desktop, Downloads, or another folder I selected
  • iCloud Drive or another sync service
  • a folder managed by the app
  • removable or network storage

The app’s File → Open Recent menu and its settings can help identify these locations. I also check whether the app has an Export, Backup, Open Data Folder, or Reveal in Finder command. An app-provided export is usually a better backup than guessing which internal files belong together.

Files in iCloud need separate attention. Apple says an app can store and sync its information through iCloud when that app is enabled under System Settings → your name → iCloud. A synced copy is not the same as a versioned backup: a deletion or bad edit may sync too.

Open your hidden Library folder

Most local support files are under the Library folder in my home folder:

~/Library

The tilde means the current user’s home folder. Apple hides this Library folder in Finder.

To open it, switch to Finder, hold Option, and choose Go → Library. I can also choose Go → Go to Folder, enter ~/Library, and press Return. Apple documents both methods in Go directly to a specific folder on Mac.

There are also /Library and /System/Library folders. Those have different jobs. I do not move or delete files there while looking for one user’s app settings.

Check the standard Library locations

An app can use more than one of these folders, and the folder name may be the app name, developer name, or bundle identifier such as com.example.AppName.

Application Support

~/Library/Application Support/

This is the first place I check for durable local data managed by a non-sandboxed app: databases, indexes, templates, plug-ins, downloaded components, and other files the app needs to operate.

Apple’s file-system guidance assigns app-created support and configuration files to Application Support. The contents are app-specific, so I do not assume a folder is safe to remove just because its name is unfamiliar.

Preferences

~/Library/Preferences/

Preferences commonly appear as property-list files with a .plist extension. The filename often uses the app’s bundle identifier.

A preferences file may contain window choices and settings, but it is rarely the app’s complete data. macOS also manages preferences while apps run, so I quit the app before copying a known preference file. I do not edit a plist merely to see what happens.

Containers

~/Library/Containers/

Sandboxed apps use app containers. Apple says macOS creates a container in ~/Library/Containers when a sandboxed app first launches. Inside it, the app gets container-specific versions of familiar locations such as Library, Application Support, Preferences, and Caches.

App Sandbox is required for apps submitted to the Mac App Store. A directly downloaded app can also use App Sandbox, while another direct-download app may use the traditional Library locations. That is why the download source alone does not tell me exactly where an app stores everything.

Apple explains the container model in Accessing files from the macOS App Sandbox and Protecting user data with App Sandbox.

Group Containers

~/Library/Group Containers/

An app group lets related apps, extensions, and helper processes share data. A main app can therefore use both its own container and one or more group containers.

On macOS 15 and later, Apple also protects app group containers with System Integrity Protection. Finder may ask for authorization when another app tries to access a protected container. I treat that prompt as a protection boundary, not as a reason to grant broad access without checking the folder owner. Apple describes the current protection in Protecting local app data using containers on macOS.

Caches and saved state

~/Library/Caches/
~/Library/Saved Application State/

Caches should hold data the app can recreate or download. Saved Application State helps macOS restore windows and interface state.

Neither location is where I start when backing up important app data. A badly behaved app can put more in a cache than it should, but the folder name is not proof that its contents are disposable.

Passwords and licences may be elsewhere

Apps can store passwords, tokens, certificates, and other secrets in Keychain rather than in their visible support folder. A licence may be tied to Keychain, an account, a receipt, the Mac App Store, the specific Mac, or a vendor’s server.

I do not copy random Keychain files or credential databases as part of an app-data experiment. For a new Mac, Setup Assistant or Migration Assistant and iCloud Keychain are safer starting points. The app may still require me to sign in or activate the licence again.

One app can have several storage locations

This is the practical checklist I use:

  • Find documents and folders I selected in the app.
  • Check the app’s export, backup, sync, and migration documentation.
  • Check ~/Library/Application Support and ~/Library/Preferences.
  • Check ~/Library/Containers and ~/Library/Group Containers.
  • Record the app version and whether it came from the App Store or the developer.
  • Keep caches, credentials, licences, and cloud data as separate questions.

Apple’s File System Programming Guide explains why apps use different standard locations and why sandboxed paths behave differently.

Finding the folders is only the inventory step. I use that inventory to back up and restore the app’s settings and local data without pretending that one copied folder is a complete backup.