Pick the Mac App Store if you want Apple to handle distribution and review, and Developer ID if you want to ship from your own website and update feed. Store apps need no separate notarization. Developer ID apps must be notarized to run on current macOS without extra warnings.
The two paths
Apple's Xcode distribution documentation lists the options in the Distribute App flow. For a Mac app, the relevant ones are the TestFlight and App Store route, and Direct Distribution, which Apple describes as the default settings to distribute a macOS app directly and says to use to notarize a Developer ID app. Release Testing and Enterprise options are not available for Mac apps.
Comparison
| Question | Mac App Store | Developer ID direct |
|---|---|---|
| Signing certificates | Mac App Distribution and Mac Installer Distribution | Developer ID Application and Developer ID Installer |
| Notarization | Not required, since submission includes equivalent checks | Required for software built after June 1, 2019 on macOS 10.15 and later |
| Who reviews the app | Apple's store process | Automated notary service, which Apple says is not App Review |
| Where users get it | The store | Your site or channel |
| Updates | Through the store | Your own updater, which you must secure |
The notarization row comes straight from Apple. Its documentation says you are not required to notarize software distributed through the Mac App Store because the submission process already includes equivalent security checks. For Developer ID, it says all software built after June 1, 2019, and distributed with Developer ID must be notarized.
What each path asks of you
Store path. You rely on Apple's process. You work within store rules, such as sandboxing and review, and Apple handles delivery and updates. Your signing job is to produce a correctly signed submission.
Direct path. You carry more of the release engineering. You sign with Developer ID, enable the Hardened Runtime, include a secure timestamp, notarize, staple, host the download, and secure an update channel. Each of those has its own post in this series, including /resources/blog/what-does-stapling-a-notarization-ticket-do and /resources/blog/how-does-sparkle-sign-macos-app-updates-eddsa-explained.
Questions that decide it
- Do you need capabilities the store does not allow, such as certain system level features? That points to direct.
- Do you want discovery and payment handled for you? That points to the store.
- Do you have the staff to run a signed update channel and respond to a key incident? If not, the store removes some of that burden.
- Do you need to ship the same day with no review wait? Direct gives you control over timing.
- Do you sell to organizations that deploy through their own tools? They often prefer a signed, notarized installer package.
You can do both
Many teams ship a store build and a direct build. Keep separate signing paths, separate artifacts and clear names. A store signed build must never be offered on your website, and a Developer ID build cannot be submitted to the store. Apple's notarization page warns not to use a Mac Distribution certificate for notarization, which is a reminder that the two certificate families are separate.
Where Safeguard fits
Whichever path you pick, the dependencies in the build are your responsibility. Safeguard offers dependency scanning and SBOM generation, with a free scan at gold.safeguard.sh/scan.
Quick check
Does a Mac App Store app need notarization?
Apple says you are not required to notarize software distributed through the Mac App Store, because the submission process includes equivalent security checks.
Is notarization the same as App Review?
No. Apple states that notarization is not App Review. It is an automated scan for malicious content and code signing issues.
Sources
- Apple Developer: Notarizing macOS software before distribution
- Apple Developer: Distributing your app for beta testing and releases
- Apple Developer: Certificates
Last reviewed: 19 October 2026.
