If you ship iOS apps, you have probably noticed that App Store Connect now shows a Review Type field with two values: App Store and Notarization. The wording suggests that they are equivalent. They are not. They look at the same binary through two different lenses, and the lens depends on where the app is going to live.
This matters because the EU's Digital Markets Act opened a second distribution path on iOS in March 2024, and Japan added its own version in late 2025. Developers who only ship through the App Store can ignore Notarization. Everyone else needs to know which guidelines apply to their build and which gates are still their own responsibility.
Short answer
App Store Review applies the full App Review Guidelines, all five sections, to every app distributed on the App Store. Notarization applies the Notarization Review Guidelines, a subset of those same guidelines, to apps distributed through alternative app marketplaces in the EU and Japan, or directly from a developer's website in the EU. The Notarization layer checks accuracy, functionality, safety, security, and privacy. It does not enforce business model, design quality, or most content rules. The marketplace operator and the developer are expected to handle those.
What you should know
- Notarization is a baseline review, not a free pass. Apple still runs a combination of automated checks and human review on every binary submitted for Notarization, per its Digital Markets Act documentation.
- The Review Type field in App Store Connect decides the bar. On the App Review Information panel of a version, you choose App Store or Notarization. Apple's Submit for Notarization help page walks through the exact selection.
- The same binary can serve both channels. A single build can be eligible for the App Store and for one or more alternative marketplaces, but each submission flows under the right guideline set.
- Content moderation, payment rules, and design quality are not part of the Notarization bar. Apple's App Review Guidelines flag which items apply to both paths and which apply only to App Store Review.
- Notarization is required for alternative distribution. If you go around the App Store in the EU or Japan, the binary still has to be notarized before users can install it.
- Marketplaces carry obligations too. Marketplace operators must run their own content rules, anti-fraud measures, and dispute handling, as described in Apple's About alternative app distribution note.
What does Notarization actually check?
Notarization on iOS is a reduced review pathway that Apple introduced when it had to allow alternative app distribution under EU law. The name is borrowed from the macOS Notary Service, which has signed and scanned macOS apps for malware since 2019, but the iOS version operates at a different bar and includes human review. When a developer submits a build under the Notarization Review Type, Apple runs automated checks and a basic human pass against the Notarization Review Guidelines. If accepted, App Store Connect generates a signed alternative distribution package that can be published through an authorized marketplace or, in the EU, hosted on a registered web distribution domain. Without that notarized package, iOS refuses to install the app even from a marketplace.
The Notarization Review Guidelines are organized around five concerns. Apple's DMA support page lays them out:
- Accuracy: the developer, capabilities, and costs shown in the installation sheet match reality.
- Functionality: the binary is reviewable, free of serious bugs or crashes, and compatible with the current iOS version.
- Safety: the app does not promote physical harm.
- Security: the app cannot ship malware, cannot read outside its sandbox, cannot download executable code, and cannot quietly lower device security.
- Privacy: the app cannot collect or transmit private data without user knowledge or outside the stated purpose.
The review is a mix of automated static and dynamic checks, plus a basic human pass. The output is binary in practice: the build is notarized, or it is rejected with a reason that maps back to one of those five concerns.
Where does App Store Review go further?
App Store Review applies the full App Review Guidelines, which add sections that Notarization does not enforce. Section 2 (Performance), Section 3 (Business), Section 4 (Design), and parts of Section 1 (Safety) and Section 5 (Legal) contain many items that only apply when the app is going to the App Store itself.
A few concrete examples of items that App Store Review enforces and Notarization does not:
- Whether your in-app purchase implementation uses Apple's payment system for digital goods.
- Whether your subscription paywall disclosures match Apple's auto-renewable subscription template.
- Whether your app duplicates an existing App Store app or feels too thin to be a stand-alone product.
- Whether your screenshots and metadata describe what the app actually does on launch.
- Whether the app falls under a category that requires a specific business model, like dating or medical apps.
Apple's guidelines page marks every item that applies to both with a small key icon. The ones without that icon are App Store Review only. That is the cleanest way to tell, item by item, where the two paths diverge.
How does the submission process differ in App Store Connect?
The submission flow lives on the version detail page in App Store Connect. The relevant control is the Review Type radio inside the App Review Information section. Apple's Submit for Notarization help page describes the exact steps. The short version:
- Open the version, scroll to App Review Information, click Edit under Review Type, and pick Notarization or App Store.
- Provide the standard fields: name, bundle ID, screenshots, version, privacy policy URL, data types, age rating, categories.
- Click Add for Review, then Submit to App Review.
- The status moves from Ready for Review to Waiting for Review to In Review. On acceptance, an alternative distribution package is generated for Notarization submissions, while App Store submissions release through the standard App Store pathway.
The prerequisites also differ. To submit for Notarization, you need to have already enrolled in alternative distribution on at least one marketplace or registered a web distribution domain, and you need the Account Holder, Admin, or App Manager role.
A side-by-side comparison
| Dimension | App Store Review | Notarization |
|---|---|---|
| Guidelines applied | Full App Review Guidelines | Notarization Review Guidelines (subset) |
| Distribution channels | App Store | Alternative marketplaces (EU, Japan) and websites (EU) |
| Review mix | Automated checks plus human review | Automated checks plus basic human review |
| Business model rules | Enforced (IAP, subscriptions, payment methods) | Not enforced by Apple at this layer |
| Content moderation rules | Enforced | Marketplace responsibility |
| Design and quality bar | Comprehensive | Serious functional issues only |
| Output on acceptance | App Store release | Signed alternative distribution package |
| Required developer agreement | Standard | Alternative Terms Addendum (EU) or Japan equivalent |
What happens after a notarized app ships?
Notarization is not a one-time stamp. Apple states in its DMA support documentation that if a notarized app is later found to contain known malware, the install can be blocked at launch and new installs can be revoked. There is also an installation sheet shown to users before install, with the developer name, app description, screenshots, and system age rating taken from the notarized metadata.
For developers, this has two practical effects. First, you cannot ship one binary to a marketplace and quietly replace its behavior later: revocation is a live mechanism. Second, marketplaces themselves carry obligations that are independent of your app. They must moderate content, run anti-fraud measures, and handle payment disputes for the apps they distribute. This is why a notarized app on a marketplace can still be removed by the marketplace operator even when Apple is satisfied with the binary.
For builders coming from no-code or AI-assisted toolchains, where security review often stops at "the build uploaded without errors," this layered model is the part that most often surprises them. Notarization rejecting a build is a clean, technical failure. A marketplace pulling the app for policy reasons is a separate, parallel process.
What should you check in your own build before either path?
For compiled iOS builds, a useful pre-submission pass covers the items that show up in both review paths, since those are the ones most likely to block you:
- Permissions and Purpose Strings: every API that needs a NSXxxUsageDescription has one, and the strings are honest about why.
- SDKs on the Privacy Manifest list: any SDK on Apple's published list ships a PrivacyInfo.xcprivacy and a matching signature.
- Storage hygiene: no plaintext secrets in the bundle, no leftover debug endpoints, no API keys hardcoded into the binary.
- Network configuration: App Transport Security exceptions are minimal and justified, certificate pinning behaves correctly on real networks.
- Crash and launch checks: the binary runs on the lowest iOS version your Info.plist advertises, on at least one real device per supported family.
For builders who want an external automated read of a compiled IPA before either Notarization or App Store Review, PTKD.com is one of the platforms focused specifically on pre-submission scanning aligned with OWASP MASVS for no-code and vibe-coded apps. It is observational tooling, not a substitute for either of Apple's review layers, but it surfaces the categories of issue that both Notarization and App Store Review tend to catch.
What to watch out for
A few traps come up repeatedly in this area:
- Treating Notarization as "App Review lite." It is narrower, but the rejections that do happen are usually decisive: malware, sandbox violations, or accuracy failures in the installation sheet. There is no marketing team to argue with about a borderline design call.
- Assuming a notarized app is automatically allowed on every marketplace. Marketplaces apply their own policies on top. A build that passes Notarization may still be refused by a specific marketplace for content reasons.
- Forgetting that web distribution is EU-only. Notarization plus a registered domain enables direct downloads in the EU, but not in Japan and not in the rest of the world.
- Using outdated terminology. The canonical names are App Store Connect for the submission portal and OWASP MASTG for the mobile testing standard. Older labels still circulate in forum posts but no longer match the official documents.
- Believing Apple has stepped back from review under DMA. Apple still runs the Notarization layer for every alternative distribution binary, and Apple still operates the full App Review pathway for App Store builds. The reach is smaller, the layer is intact.
Key takeaways
- App Store Review applies the full App Review Guidelines to App Store builds. Notarization applies the Notarization Review Guidelines, a subset, to alternative distribution in the EU and Japan.
- The same binary can flow through both, but the Review Type selected in App Store Connect determines which set of guidelines Apple actually applies for that submission.
- Notarization covers accuracy, functionality, safety, security, and privacy. Business model, design, and content rules sit with App Store Review or with the marketplace.
- After acceptance, Apple can still revoke a notarized app if it later finds known malware, and marketplaces can still remove an app on policy grounds independently of Apple.
- Some teams outsource a pre-submission read of the compiled binary to platforms like PTKD.com so the issues both review paths look for are caught locally before either submission.




