In this article
Keep the app's location with that identifier. A name such as “Example” can refer to an installed copy, an older copy in Downloads or a second copy on another volume. Reading the metadata inside the specific bundle answers which identifier that copy declares.
Use Finder before a lookup by name
Locate the app you are investigating, rather than choosing a similarly named search result. Open its package contents and inspect Info.plist without saving changes. In a readable XML plist, find CFBundleIdentifier and copy its string value.
Apple documents this native workflow in Get the bundle ID for a Mac app. If a text editor shows unreadable characters, do not try to repair the file: a property list may use a binary representation.
A bundle ID commonly looks like com.company.product. It is separate from the app's visible name, version and file path. Apple's bundle structure reference describes those distinct metadata fields.
This is a lookup task. Editing an installed app's metadata is unnecessary and can invalidate its signature. Close the file without changes.
Read the value directly in Terminal
The built-in plutil command can extract the key from the plist at a specific path:
plutil -extract CFBundleIdentifier raw -o - "/System/Applications/TextEdit.app/Contents/Info.plist"
On our Mac running macOS 15.7.5, checked on October 4, 2026, that read-only command returned:
com.apple.TextEdit
For another app, replace the quoted path with that copy's Contents/Info.plist path. Keep the quotes around spaces. You do not need to open the app itself or grant it additional access to read metadata that your account can already access.
Here, -extract selects the key, raw prints its value, and -o - sends output to the terminal. It does not overwrite the source file. The command works with the XML and binary plist fixtures tested below.
If you get an error, read it before changing anything. A nonexistent path, a missing key, an unreadable file and an invalid plist are different results. None is a reason to guess the identifier from the app's name.
Jamf's bundle-ID guide also describes a Spotlight metadata lookup using mdls. If that method returns no useful value, inspect the bundle's own plist by path; a missing metadata result alone does not prove the app has no bundle ID.
A rename-and-copy experiment
We created a small metadata-only test bundle containing an Info.plist. It declared the identifier example.vaultdog.identity-probe. It had no executable and was never launched.
We read the identifier, renamed its outer folder, copied it to another folder, and converted the copied plist from XML to binary. The results were:
| Test case | Declared bundle ID |
|---|---|
Original folder: Example.app | example.vaultdog.identity-probe |
Renamed folder: Renamed Copy.app | Same value |
Separate folder: Second Copy.app | Same value |
| Second copy with a binary plist | Same value |
The experiment shows why an outer filename cannot tell you the full identity of a local copy. Changing that filename did not rewrite the metadata inside it. Copying the metadata preserved its value, and changing the serialization format preserved it too.
The test does not establish how two runnable copies would be registered, which copy macOS would launch by name, or whether they would share preferences. Those are separate behaviors. It also does not authenticate either copy: this was deliberately a simple fixture, not a signed app.
Separate the identifiers before using them
When you investigate a background component or an unfamiliar settings file, keep these fields distinct:
| Field | What to record |
|---|---|
| App path | The exact copy you inspected |
| Bundle ID | Its declared CFBundleIdentifier |
| Version or build | Which release that copy reports |
| Signing identity | Separate evidence about its signature and publisher |
| Helper's identifier | The identifier of that helper's own bundle, if present |
An app can contain a helper with its own bundle identifier. Apple's Xcode bundle-ID guidance explicitly distinguishes the IDs of a macOS app and its embedded helper. Inspect the helper's own metadata when the question is about that component.
A familiar-looking identifier is not a malware verdict or a substitute for checking an app's code signature. Keep the declared string and signing evidence as separate observations.
Use the ID as a clue to associated files
A bundle ID is useful when an app's display name is vague or when a support request refers to a reverse-domain string. It can also help connect an installed app with related preferences or containers.
It is not a complete file manifest. Some paths use an app name, a vendor name or a shared identifier. Our guide to Containers and Group Containers explains why shared storage needs separate interpretation.
VaultDog lets you search its discovered installed-app list by bundle identifier. That can help connect a string found in a file path with an app in the inventory. Check the app's location and the evidence for each association before deciding what the file belongs to.
For a useful support note, record the identifier, exact app path, version and date of the check. If you are considering cleanup, continue with the file's purpose and the vendor's guidance; the Application Support deletion checklist covers that separate decision. Matching a bundle ID alone does not make a file disposable.
