Open an application bundle

A .app is a directory with a defined bundle structure. Finder normally presents it as one application, but the shell sees a plain folder you can walk through. Knowing the layout lets you answer questions like “which binary actually runs?” and “does this app ship its own helpers?”.

Walk the structure

Inspect a copy or a trusted app:

find "/Applications/TextEdit.app/Contents" -maxdepth 2 -print

The layout is predictable. Contents/MacOS holds the main executable. Contents/Resources holds assets and localizations. Contents/Frameworks holds bundled libraries, and Contents/PlugIns or embedded .app bundles hold helper processes. When Activity Monitor shows a helper with a strange name, this is where it lives.

Read Info.plist

plutil -p "/Applications/TextEdit.app/Contents/Info.plist"

Info.plist describes identifiers, executable names, document roles, and capabilities. The fields worth reading first: CFBundleIdentifier (the bundle ID, com.apple.TextEdit here, which names the app’s preferences and containers), CFBundleExecutable (which file in MacOS starts), and CFBundleShortVersionString (the version to record in any bug report).

The bundle ID is the key that links a running process back to its on-disk state, so note it down whenever you investigate an app.

Check the signature without touching anything

codesign -dv --verbose=2 /Applications/TextEdit.app

This prints the signing Identifier and TeamIdentifier, telling you who shipped the binary. It reads; it changes nothing.

The mistake to avoid

Changing files inside a signed app can invalidate its signature, so inspect first and repair through a trusted reinstall. Even “harmless” edits like swapping an icon or deleting a localization break the seal, and macOS may then refuse to launch the app at all. If a bundle’s contents look wrong or modified, the fix is a fresh copy from the developer, not surgery on the broken one.