App notarization is Apple’s automated security check for Mac software distributed outside the Mac App Store: the developer uploads a signed app, installer or disk image to Apple’s notary service, which scans it for known malicious content and code-signing problems and, if it passes, issues a notarization ticket that Gatekeeper recognizes. In macOS security & privacy, it is the step that links independent software distribution to Apple’s malware defenses without requiring App Store review.
Since macOS Catalina, Gatekeeper expects software signed with a Developer ID certificate to also be notarized before it opens normally. Notarization is not a human review of functionality or quality, and it does not guarantee that an app is safe; it confirms that Apple’s automated checks found no known problems at the time of submission.
How the notarization process works
Notarization is a pipeline of signing, submission, scanning and stapling. Each step must succeed for Gatekeeper to accept the software without a warning on a user’s Mac.
| Step | What happens | Typical tool |
|---|---|---|
| Code signing | App signed with a Developer ID certificate and secure timestamp | codesign or Xcode |
| Hardened Runtime | Runtime protections enabled with declared exceptions | Xcode signing settings |
| Submission | Archive, package or disk image uploaded to the notary service | xcrun notarytool submit |
| Automated scan | Malware and signing checks run on Apple servers | Notary service |
| Ticket issued | Result recorded and linked to the code signature | Notary service |
| Stapling | Ticket attached to the file for offline checks | xcrun stapler staple |
Most submissions complete within minutes, although times vary with load and file size. When a submission fails, the notary log lists every problem, such as unsigned nested binaries, a missing secure timestamp or the debugging entitlement get-task-allow left enabled.
How Gatekeeper uses notarization tickets
When a user first opens downloaded software, macOS checks the quarantine attribute set by the browser or messaging app and passes the file to Gatekeeper. Gatekeeper verifies the signature and looks for a ticket, either stapled to the file or retrieved online from Apple.
| Software status | Gatekeeper behavior | User experience |
|---|---|---|
| Signed and notarized | Allowed after a first-launch confirmation | Dialog names the developer and download source |
| Signed, not notarized | Blocked by default | User must approve in System Settings |
| Unsigned | Blocked by default | Strong warning and manual approval |
| Ticket revoked | Blocked | macOS reports the software as damaged or malicious |
| App Store app | Allowed through store review path | No notarization step needed |
Stapling matters for offline installation. Without a stapled ticket, a Mac that cannot reach Apple’s servers cannot confirm notarization. With macOS Sequoia, Apple also removed the Control-click shortcut for opening unnotarized software, so users must approve it explicitly under Privacy & Security in System Settings.
Notarization compared with related macOS protections
Notarization is one layer of a defense-in-depth design. It acts before first launch, while other features restrict what running code can do or detect malware later.
| Protection | When it acts | Main purpose |
|---|---|---|
| App notarization | Before distribution and first launch | Confirms an automated malware and signing check |
| Gatekeeper | At first launch of downloaded software | Enforces signing and notarization policy |
| Hardened Runtime | While the app runs | Blocks code injection and unsafe memory use |
| XProtect | At launch and during background scans | Signature-based malware detection and removal |
| SIP | Continuously | Protects system files from modification |
| TCC | When the app requests sensitive access | User consent for camera, files and other data |
The difference from App Store review is fundamental. Store review includes human checks against content and business guidelines, while notarization is automated and security-focused and leaves distribution, pricing and features to the developer.
Revocation and the limits of notarization
Because a ticket is tied to a specific code signature, Apple can revoke tickets or Developer ID certificates when it later identifies malware. Revocation lets macOS block software that passed notarization earlier, which is important because scans only detect what is known at submission time.
Attackers have occasionally obtained notarization for harmful software, so notarization should be treated as a baseline signal, not a verdict. The checks do not evaluate whether an app collects excessive data, behaves deceptively or downloads additional code after installation.
Notarization also has operational limits for developers. It depends on Apple’s online service, so an outage or account problem can delay a release. A notarized build covers only that exact signature; any change to the binary, including a minor patch, requires a new submission and a new ticket. Software that updates itself must notarize every update it delivers.
The same concept now appears beyond the Mac. In the European Union, apps distributed on iPhone through alternative marketplaces undergo a comparable notarization review, which is broader than the Mac check and combines automated and human steps focused on platform integrity.
Practical guidance for developers
Teams that ship Mac software outside the store usually automate notarization in their build pipeline. Credentials for the notary service are stored as an app-specific password or an App Store Connect API key in the keychain profile used by notarytool.
| Failure | Cause | Fix |
|---|---|---|
| Nested code not signed | Helper tools or frameworks skipped | Sign every executable from the inside out |
| No secure timestamp | Signing without the timestamp option | Re-sign with a secure timestamp |
| Hardened Runtime missing | Runtime option not enabled | Enable it and declare needed exceptions |
| Debug entitlement present | Development build submitted | Submit a release build |
| Ticket not found offline | Ticket not stapled | Staple the app, package or disk image |
- Use notarytool, because the older altool workflow for notarization is no longer accepted.
- Verify the result with
spctl --assess --verboseandxcrun stapler validatebefore release. - Notarize the outermost distributed container, such as the disk image, and staple each item users may open directly.
The short version
Many Mac apps are downloaded from the developer’s own website, not from the App Store. Notarization is Apple’s quick security check for those apps. The developer sends the app to Apple, and computers scan it for known malware.
If it passes, the app gets a digital approval stamp. Your Mac looks for that stamp the first time you open the app. A missing stamp leads to a warning, so you should think twice before allowing the app.
Where it makes a difference
A small company sells a photo-management app for the Mac directly from its website as a disk image. Its build server signs the app and its helper tool with a Developer ID certificate, enables the Hardened Runtime, submits the disk image with notarytool and staples the ticket once the scan succeeds, all in about ten minutes.
Customers who download the disk image see only the standard first-launch dialog naming the developer. Before notarization was automated, support received regular messages from users confused by blocked-app warnings. After the change, those requests nearly disappeared, and the app installs cleanly even on Macs without internet access thanks to the stapled ticket.