Skip to content
Home » How to Check an App’s Code Signature on a Mac with codesign

How to Check an App’s Code Signature on a Mac with codesign

When you download an app outside the App Store, codesign is the built-in way to check who actually signed it and whether the copy on disk has been tampered with. It reads the signature that every modern Mac app carries — no install, no sudo, and reading is completely non-destructive. Everything below was run on macOS 26.5.2 against the built-in Calculator so the output is reproducible on any Mac.

Read a signature

-d means “display the signature” and each extra v adds detail, so -dvvv is the usual way to dump everything about how an app is signed:

$ codesign -dvvv /System/Applications/Calculator.app
Executable=/System/Applications/Calculator.app/Contents/MacOS/Calculator
Identifier=com.apple.calculator
Format=app bundle with Mach-O universal (x86_64 arm64e)
CodeDirectory v=20400 size=14029 flags=0x0(none) hashes=428+7 ...
Hash type=sha256 size=32
Authority=Software Signing
Authority=Apple Code Signing Certification Authority
Authority=Apple Root CA

The lines that matter most are Identifier, the bundle ID the developer chose (com.apple.calculator here), and the Authority chain, which is who vouches for the signature. Apple’s own apps end in a chain rooted at Apple Root CA with Software Signing at the top. Format confirms it is a universal binary built for both Intel and Apple silicon. The output goes to standard error, so if you want to pipe it, redirect with 2>&1 first.

Verify the copy is intact

Reading the signature tells you what it claims; --verify checks that the files on disk still match it and nothing has been altered since signing:

$ codesign --verify --verbose /System/Applications/Calculator.app
/System/Applications/Calculator.app: valid on disk
/System/Applications/Calculator.app: satisfies its Designated Requirement

Those two lines, and an exit status of 0, mean the bundle is unmodified and still meets its own signing requirement. If a file inside the app had been changed — a patched binary, a swapped resource — this is where it fails, with a message like a sealed resource is missing or invalid and a non-zero exit. That makes codesign --verify a quick integrity check for anything you are unsure about.

Who signed it, and is it notarized

A third-party app distributed outside the App Store is signed with a Developer ID rather than Apple’s own certificate, so its chain looks different. The identifiers below are placeholders, but the shape is what you will see:

Identifier=com.example.someapp
Authority=Developer ID Application: Example Developer LLC (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
TeamIdentifier=ABCDE12345

The first Authority line names the developer and their ten-character Team ID, which also appears on its own as TeamIdentifier — that Team ID is the stable identity to check an app against, since display names can be similar. Signing proves who built it; it does not prove Apple has scanned it. For that, ask Gatekeeper directly with spctl:

$ spctl -a -vv /System/Applications/Calculator.app
/System/Applications/Calculator.app: accepted
source=Apple System
origin=Software Signing

A notarized third-party app returns accepted with source=Notarized Developer ID instead — that is the line confirming the app was submitted to Apple and passed its malware check. An app that is neither signed acceptably nor notarized comes back rejected, which is exactly what Gatekeeper acts on when it refuses to open something.

Why codesign sometimes uses CPU

If you have noticed a codesign process briefly pegging a core, it is usually the first launch of a large app you just downloaded or updated. macOS verifies the whole signature — every hashed page of every binary in the bundle — before it runs the first time, and a big app has a lot of pages to hash. It is one-time work per version: once the app has launched cleanly, later launches do not repeat the full check. A spike that never settles, on the other hand, points at something else worth looking into, not at codesign itself.

Command quick reference

GoalCommand
Read the full signaturecodesign -dvvv /path/to/App.app
Just the signer and Team IDcodesign -dvv /path/to/App.app
Verify nothing was alteredcodesign --verify --verbose /path/to/App.app
Show entitlementscodesign -d --entitlements - /path/to/App.app
Ask Gatekeeper if it is acceptedspctl -a -vv /path/to/App.app

That is the everyday use: -dvvv to see who signed an app and read its Team ID, --verify to confirm the copy is untouched, and spctl to check notarization. None of it changes anything on disk, so it is safe to run on anything you are curious or unsure about before you trust it.

Tags:

Leave a Reply

Your email address will not be published. Required fields are marked *