Understand signing identities

Code signing answers one question for macOS: who produced these bytes, and have they changed since? The answer comes from a signing identity — a certificate plus its private key — and different identities mean different things.

Apple Development identities are for your own Macs. They let you build, run, and debug. Ship a build signed with one and other Macs will refuse it.

Developer ID Application is the identity for direct distribution outside the Mac App Store. Gatekeeper recognizes it, and it’s the identity notarization expects. Getting one requires the paid Apple Developer Program membership.

Mac App Store submissions use Apple’s store certificates and submission flow — a separate path where Apple re-signs your app for delivery.

There is also the ad-hoc signature: signing with - instead of an identity. Apple silicon requires every binary to carry at least an ad-hoc signature to run at all. But an ad-hoc signature carries no identity. It proves nothing to anyone else’s Mac, and Gatekeeper treats the app as unsigned.

See which identities your Mac can sign with:

security find-identity -v -p codesigning

You want a line containing Developer ID Application: Flavio Copes (ABCDE12345).

Then read the identity from a built artifact, which is the fact that matters:

codesign -dv --verbose=4 Notes.app

Check the Authority chain — it should start with your Developer ID certificate — and the TeamIdentifier.

The private key behind your certificate is the crown jewel. Anyone holding it can ship malware in your name. Never commit an exported certificate or its password, and share it only through a proper secrets manager.

The everyday mistake: Xcode automatic signing quietly used the development certificate, you zipped the result, and a tester reports the app “is damaged or can’t be opened”. Run codesign -dv on your artifact before shipping and you catch it in one second.