If you are about to submit an iOS build through the alternative marketplace path in the EU or Japan, or you are simply trying to understand what the new Notarization Review covers, the practical question is whether Apple's scan will catch a Stripe secret key, an OpenAI token, or a Supabase service role key sitting inside the JavaScript bundle. The answer matters because the scan happens after you upload, and a clean Notarization result can read as a green light when it is not.
Short answer
No. iOS Notarization does not check your binary for hardcoded API keys, signing secrets, or other credentials. The published Notarization Review Guidelines list five concerns: accuracy of the listing, basic functionality, safety, security against malware and sandbox escape, and privacy disclosures. None of those items maps to credential hygiene. The same applies to standard App Store Review, where Section 1.6 of the App Review Guidelines addresses data security in general terms without naming hardcoded keys as a rejection criterion. OWASP tracks the underlying issue as MASWE-0005, API Keys Hardcoded in the App Package, and the only reliable check happens before you upload, not after.
What you should know
- Notarization is a narrow review. Apple's Digital Markets Act page lists exactly what the scan covers, and credential leakage is not on that list.
- A notarized build can still ship plaintext keys. A pass result confirms the binary is signed, free of known malware, and matches the privacy disclosures you filed, nothing more.
- App Store Review is not stricter on this specific point. The published guidelines reference data security at a high level (Section 1.6) and tracking-style behavior (Section 5.1), without listing hardcoded credentials as a flagged item.
- OWASP MASVS has a name for the pattern. MASWE-0005 covers hardcoded API keys, and the MASTG iOS tests 0212 through 0214 cover both source and binary file storage.
- Mobile binaries are public artifacts. Anything compiled into an APK, AAB, or IPA should be treated as visible to anyone with the file and a few minutes of patience.
What does iOS Notarization actually check?
The short answer is that Notarization checks five things, and credential storage is not one of them. Apple's DMA developer page describes the scan as a combination of automated checks and human review against the Notarization Review Guidelines. Those guidelines, organized around the same five-section structure as the wider App Review Guidelines, are a strict subset focused on protecting the device and protecting users from outright fraud.
The five concerns, in Apple's own wording: accuracy (the developer identity, capabilities, and costs shown to the user are real), functionality (the binary runs, does not crash, and is compatible with the current iOS version), safety (the app does not promote physical harm), security (the app cannot ship malware, escape its sandbox, download executable code, or quietly weaken device security), and privacy (the app cannot collect or transmit private data outside the disclosed purpose).
None of those five categories includes inspecting the contents of the binary for plaintext credentials. Apple says, plainly, that Notarization on iOS is more limited than the full App Review process. The intent is to filter out obvious malware and serious misrepresentation, not to audit the code quality of every uploaded build.
What about the standard App Store Review path?
Standard App Review is broader than Notarization but still does not publish a rule that targets hardcoded API keys. The App Review Guidelines reference data security in Section 1.6: apps should implement appropriate security measures to handle user information and prevent unauthorized use, disclosure, or access. Section 5.1.1(vi) warns that developers who surreptitiously discover passwords or other private data will be removed from the program. Both items can be invoked against egregious behavior, neither is a documented scan rule.
In practice, reviewers can and do flag obvious abuse. A build that sends unencrypted user credentials to a remote endpoint, or a build that calls a private Apple API to read keychain entries, gets escalated. A Stripe secret key sitting in a JavaScript bundle does not, because nothing in the documented review surface looks for that pattern. The review is behavioral and policy-based, not a static analysis of secret literals.
Independent vendor reports back this up directionally. The 2024 NowSecure Mobile Risk Tracker noted that a substantial share of fintech and healthcare apps surveyed presented at least one high-risk storage or credential issue, even after passing review. Treat that as directional: visible to careful scanners, not officially documented by Apple.
Why would Apple skip this check?
The honest answer is that secret detection at review time is harder than it sounds, and Apple has chosen to put the responsibility on the developer. A reviewer cannot tell from a string of characters whether sk_live_4eC39HqLyjWDarjtT1zdp7dc is a real Stripe secret or a deliberately fake constant in a unit test fixture. Automated scanners reduce that ambiguity but produce false positives that would balloon support load and slow review.
The other reason is scope. The Notarization Review Guidelines were written to define the minimum bar for distribution outside the App Store in regulated jurisdictions. Apple deliberately kept the bar narrow so that alternative marketplaces and web distribution could operate without Apple gating every code-quality decision. Credential hygiene falls into the developer responsibility bucket, alongside accessibility quality, internationalization, and most other code health concerns.
In practice, this means the responsibility lives with the developer, the team, and whatever pre-submission tooling they choose. Apple is comfortable signing a build that exposes a Mapbox secret token, because the resulting damage is to the developer's billing account, not to the user's device security.
What does the scan miss in real apps?
The pattern that slips through most often is a JavaScript bundle generated by a React Native or Expo build, with literals inlined at build time. The Expo environment variables guide is direct on this: any value with the EXPO_PUBLIC_ prefix is inlined into the client bundle and visible in plain text in the compiled application. The same is true for hardcoded literals in .ts or .tsx files. Notarization sees a properly signed binary, the privacy manifest matches the declared SDKs, and the build passes.
A scan run on the same IPA finds the value in a few seconds. Tools like trufflehog and gitleaks pattern-match well-known prefixes (sk- for OpenAI, sk_live_ for Stripe, eyJhbGc for service-role JWTs, AIza for Google API keys, AKIA for AWS access keys) and surface them inside the bundled JavaScript files. OWASP's MASTG iOS Data Storage tests cover the broader pattern, with test 0214 specifically targeting hardcoded cryptographic keys in files.
The other common miss is a credential inside a Plist file or an Info.plist extension. Native iOS code can stash an API key inside a config bundle, and as long as the SDK behind it is declared in the privacy manifest, Notarization has no reason to dig into the string contents.
How does this compare to other store-side checks?
The broader picture helps calibrate expectations. The table below summarizes what each common pre-submission gate covers for hardcoded credentials.
| Check | Catches hardcoded API keys? | What it actually does |
|---|---|---|
| iOS Notarization | No | Signs, scans for malware, checks privacy disclosures |
| Standard App Store Review | Rarely | Behavioral review against App Review Guidelines |
| Google Play pre-launch report | No | Crawls UI, captures crashes and basic accessibility issues |
| Google Play app integrity | No | Detects tampering and emulator use at runtime |
| OWASP MASTG-aligned scan | Yes | Static and dynamic checks against MASVS, including MASWE-0005 |
| Pre-commit secret scanner (gitleaks, trufflehog) | Yes, on source | Pattern matches before code reaches the build |
The pattern is clear: store-side scans focus on integrity and policy, not on code quality. Catching a hardcoded secret is a job for tooling the developer runs themselves, ideally at two points: a pre-commit hook on the source, and a pre-submission scan on the built artifact.
For builders who want an external, automated read of their build before submission, PTKD.com (https://ptkd.com) is one of the platforms focused specifically on pre-submission scanning aligned with OWASP MASVS for no-code and vibe-coded apps. The point is not that any single scanner is definitive, but that the gap between Apple's scan and a real OWASP MASVS check has to be filled by something on the developer side.
What changes if my app ships through an alternative marketplace?
The distribution channel does not change Apple's secret-scanning posture, because Apple is not running a secret scan in either path. What changes is who else looks at the build. The About alternative app distribution note specifies that marketplace operators carry their own obligations around content rules, anti-fraud measures, and dispute handling. Some marketplaces have started layering their own pre-listing security scans, and a few include MASVS-aligned checks as part of submission.
That layered model means an app distributed through, say, the AltStore PAL in the EU may face an extra scan that the App Store version did not, depending on the marketplace operator's policy. The Notarization step itself does not change, but the developer surface does.
For a small or solo team, this is mostly noise: the Notarization scan is the same, the App Review Guidelines do not apply on the alternative channel, and the marketplace's policy is rarely as deep as a real OWASP MASVS scan. The practical answer is to assume the marketplace will not catch your secret leak, scan the build before you upload, and rotate any credentials that turn up.
What to watch out for
A few patterns trip teams up because they read as if Apple is checking when it is not.
The first is the comfort of a clean Notarization status. The status confirms the binary passed Apple's narrow review, not that the binary is free of leaked credentials. Treat it as a malware and identity check, not a security audit. Apple's DMA documentation makes this explicit when it describes Notarization as a baseline.
The second is the assumption that environment variables are private. Bundlers inline them at build time. The Expo docs warn about this for EXPO_PUBLIC_* variables, and React Native's react-native-config README is similarly clear that it does not obfuscate or encrypt secrets for packaging. A variable with _PUBLIC_ in the name is honest about its destination; a variable without that prefix can still land in the binary if a bundler decides to inline it.
The third is the assumption that App Review will catch a hardcoded key because reviewers look at the source. Reviewers do not have your source. They have the compiled binary and a basic test pass. The deeper the credential is buried in a minified bundle, the less likely a human reviewer is to see it, and the automated scans Apple runs are not built for credential detection.
The fourth is over-trusting obfuscation. JavaScript minification, ProGuard rules, and string-encryption tricks raise the cost of extraction by minutes, not hours. The OWASP Mobile Top 10 lists Insecure Data Storage as the second-most common category for a reason: obfuscation buys time, not safety.
Key takeaways
- Apple's iOS Notarization scan does not check for hardcoded API keys or secrets, and a notarized build can still ship credentials in plain text.
- Standard App Store Review references data security at a high level but does not publish a rule that flags hardcoded keys, so reliance on review as the secret-detection gate is misplaced.
- The OWASP MASTG (MASWE-0005, test 0214) is the right reference for what a real check looks like, and most useful tooling sits on the developer side, not on Apple's.
- Some teams outsource pre-submission scanning to platforms like PTKD.com (https://ptkd.com) for an external read aligned with OWASP MASVS; either way, the credential check has to happen before the build leaves your machine.
- Rotate any secret that turns up in a built artifact before doing anything else, because public exposure of a key is a clock running on billing fraud and account abuse.
