Notarization usually fails for one of a few reasons: the app was not signed with a Developer ID certificate, the Hardened Runtime is off, the signature lacks a secure timestamp, the debug entitlement is still present, or the app links an old SDK. Read the notary log, because it names the exact problem.
Start with the log
Apple says the notary service reports problems in log files, and advises you to fix them and notarize again. It also says to check the log even when notarization succeeds, because it can contain warnings you can fix before the next submission. Make fetching the log a standard step in your release script, not something you do only on failure.
The common causes
| Cause | What to check | Fix |
|---|---|---|
| Unsigned or modified after signing | Test the signature with the code signing tool in verbose, deep and strict modes | Sign again after the last change to the bundle |
| Wrong certificate | Certificate type is not Developer ID | Re-sign with Developer ID Application |
| Hardened Runtime off | Capability not enabled | Enable it, then add only needed exceptions |
| No secure timestamp | Custom export skipped it | Add the timestamp option when signing |
| Debug entitlement present | Entitlement for debugging is in the signature | Build the release configuration, remove it |
| Old SDK | Binary linked against an SDK before macOS 10.9 | Rebuild with a current SDK |
| Malformed entitlements | Binary property list or odd characters | Use a plain XML, ASCII entitlements file |
Each row comes from Apple's resolving-issues page.
Three that bite custom pipelines
Secure timestamp. Apple says Xcode does not add a secure timestamp during a normal build. It adds one during archive and export. If you use a custom export process, you need to add the timestamp option yourself. Generating a timestamp needs internet access, so a locked-down build agent can fail here.
Debug entitlement. New macOS projects in Xcode enable an entitlement that helps debugging when System Integrity Protection is on. Apple warns this is a security risk in a shipping app because it can allow code injection at runtime. Xcode strips it in the standard export, but a custom workflow can leave it in.
Entitlements file format. The file must be ASCII with no byte order mark. Apple says a binary property list is rejected, and that since macOS 10.15.4 processes with malformed embedded entitlements no longer run.
A repeatable fix loop
- Fetch the notary log for the failed submission.
- Match each issue to a row above.
- Fix the signing script, not the single build, so the next release does not repeat it.
- Verify the signature locally before you resubmit.
- Resubmit, fetch the log again, and read any warnings.
Where Safeguard fits
Notarization checks signing and malicious content. It is not a review of your third-party dependencies. Safeguard scans dependencies and builds SBOMs for that, and a free scan is available at gold.safeguard.sh/scan.
Quick check
Does a successful notarization mean there were no problems?
Not necessarily. Apple advises reading the log even on success, since it may list warnings worth fixing.
Why did my export notarize from Xcode but fail from my script?
Xcode adds the secure timestamp and strips the debug entitlement in its standard export. A custom script has to do both itself.
Sources
- Apple Developer: Resolving common notarization issues
- Apple Developer: Customizing the notarization workflow
Last reviewed: 19 October 2026.
