How to tell if a Mac app is notarized by Apple

You download an app, double click it, and macOS either opens it, warns you, or refuses outright. Behind those three outcomes sits a system called notarization, and knowing how to read it turns a vague sense of trust into something you can actually check. This is a short, practical guide to confirming whether an app has been notarized by Apple, what that does and does not guarantee, and how to inspect it yourself.

What notarization is, and what it is not

Notarization is a check Apple runs on software distributed outside the Mac App Store. Before a developer ships an app, they upload it to Apple’s service, which scans the code for known malware and for signs of tampering, then issues a ticket if the app comes back clean. That ticket is stapled to the app so your Mac can confirm it later, even offline.

It is worth being precise about what this means. Notarization is an automated malware and integrity scan, not a human review of whether the app is good, useful, or well made. Apple is not vouching that the developer is trustworthy or that the app does what it claims. What notarization does tell you is narrower and still valuable: this app was submitted by a developer with a real Apple-issued identity, it passed an automated malware scan, and the copy you hold has not been altered since that scan.

Sitting underneath notarization is code signing. The developer signs the app with a Developer ID certificate that Apple issued to them, which ties the app to a known account. Notarization builds on that signature. Together they answer two questions your Mac cares about: who published this, and has anyone changed it since. The part that catches people out is that these are separate from sandboxing and privacy. A notarized app can still ask for broad permissions. Notarization is about origin and integrity, not about how little the app touches once it runs.

The quick way to check, without the terminal

The fastest signal is what happens when you first open the app. On a modern Mac, double clicking a properly notarized app from a developer shows a one-time dialog naming the developer and asking if you are sure you want to open it. You click Open and it launches. That calm, named prompt is the good case.

The bad case looks different. If macOS says the app cannot be opened because it is from an unidentified developer, or because it could not be checked for malicious software, the app is either unsigned, unnotarized, or has been changed since it was signed. That warning is Gatekeeper, the part of macOS that enforces all of this at launch. It is not a bug to be worked around casually. It is the system telling you the app failed the checks above.

You can also inspect the app in Finder before opening it. Right click the app, choose Get Info, and read the details. More usefully, you can right click and choose Open to see the exact wording of any warning, which spells out whether the issue is signing or notarization. The language of the prompt is the clue: a named developer and a simple confirmation means it passed, while any mention of an unidentified developer or a failed malware check means it did not.

Confirming it yourself in the terminal

If you want certainty rather than inference, macOS ships the tools to prove it. Open Terminal and point two commands at the app.

The first checks the signature and notarization in the same breath. Run spctl -a -vvv -t install /path/to/App.app against the app. A notarized app returns a line that reads accepted and names the source as Notarized Developer ID. Anything else, including a rejection, tells you the app would be blocked or questioned by Gatekeeper.

The second command reads the signature directly. Run codesign -dv --verbose=4 /path/to/App.app and look at the output. It shows the Team Identifier and the Authority chain, which should trace up to Apple through a Developer ID certificate. If the app is signed by a real developer identity, the authority lines make that plain. If it is unsigned or ad hoc signed, that shows too.

You can drag the app onto the Terminal window to fill in its path rather than typing it. Neither command changes anything; they only read and report. Between the two, you can confirm both halves of the promise: a valid Developer ID signature, and a notarization ticket that Apple issued.

Why this is worth the two minutes

Checking notarization is not paranoia. It is the cheapest way to filter out a large category of bad software before it ever runs, and it takes less time than reading the app’s own marketing page. An app that passes is one that came from an identified developer and arrived unaltered. That is a real floor, even if it is not the whole picture.

The honest next step is to pair the notarization check with a look at what the app then asks for once it runs, because a good origin and a modest permission footprint together tell you far more than either alone. Ledge, for example, is signed with a Developer ID and notarized by Apple, so it opens with the calm named prompt rather than a warning, and it backs that up by asking for almost nothing when you actually use it. That combination, a verifiable origin plus a light touch on your system, is the standard worth holding downloads to.

None of this requires you to be a developer. The prompt at first launch tells you most of the story, and the two terminal commands settle any doubt. Make the check a habit, and the difference between an app that quietly passed Apple’s scan and one that could not be verified stops being a mystery you click past and becomes a fact you can see.