An iOS developer asked the question this article answers because they got a clean automated scan result back from App Store Connect and wanted to know whether "clean" meant their Stripe secret key had been checked. The honest answer requires separating two different operations that both call themselves scans.
Short answer
Apple's automated scan does run against every submitted binary, but it scans for prohibited APIs, deprecated frameworks, missing entitlements, and ATS misconfiguration. According to Apple's developer documentation on the App Review process, the automated layer feeds into a human reviewer; neither layer is documented as performing credential pattern matching against the Mach-O strings. A strings | grep sk_live_ on the same IPA finds the leak in under a second. That check has to happen on your side.
What you should know
- Apple does scan, but for different things. Private API usage, deprecated frameworks, missing entitlements, ATS exceptions, metadata mismatches. None of those are credential patterns.
- Credential scanning is a separate operation. It is regex against extracted strings, not static analysis of code.
- No published Apple rejection category covers hardcoded credentials. The closest guideline assigns responsibility to the developer, not to Apple.
- The same scan an attacker would run takes you about ten seconds with
unzip,strings, andgrep. - PTKD.com (https://ptkd.com) is one of the platforms that runs the broader credential scan against an uploaded IPA and maps findings to OWASP MASVS controls.
What does Apple's automated scan actually inspect?
Apple publishes the categories the review process covers (safety, performance, business, design, legal), but not the implementation of the automated layer. Developer reports across many years of WWDC sessions, Reddit r/iOSProgramming, and Apple Developer Forums let us reconstruct the operational scope:
- Private API usage. Apps that call non-public APIs (selector strings that match Apple's private symbol table) are flagged. This catches workarounds developers find but Apple has not blessed.
- Prohibited frameworks. Bundles that link against frameworks Apple has deprecated or banned (older versions of UIWebView for example) are rejected at the binary check.
- Missing entitlements. If the binary declares it uses a capability (HealthKit, location) that the app's entitlements file does not match, the scan catches the mismatch.
- App Transport Security misconfiguration. Apps with
NSAllowsArbitraryLoadsin Info.plist without a documented justification trigger a flag. - Metadata accuracy. Bundle identifier, version number, supported architectures match what App Store Connect expects.
Notice what is missing: no string-level pattern matching, no credential prefix detection, no scan of embedded JSON files for keys. The scan is policy-and-compliance focused, not security-focused.
What is the difference between a static analysis scan and a credential scan?
Static analysis is a deep operation. It parses the binary, reconstructs control flow, traces type information through method calls, and looks for known-bad code patterns. Tools that perform real static analysis (Apple's own internal tools, commercial offerings like MobSF, NowSecure, Veracode) do this for security-relevant findings: unsafe API usage, missing input validation, broken cryptography.
Credential scanning is much simpler and much faster. It extracts every printable string from the binary and matches each string against a list of known credential prefixes:
| Provider | Prefix | Description |
|---|---|---|
| Stripe | sk_live_, sk_test_, rk_live_, rk_test_ | Secret and restricted keys |
| AWS | AKIA, ASIA | IAM and STS keys |
| Supabase | sb_secret_, JWT with role:service_role | Service-role keys |
| OpenAI | sk-, sk-proj- | API keys |
| Anthropic | sk-ant- | API keys |
| SendGrid | SG. | API keys |
| Twilio | SK, AC (account SID) | API credentials |
AIza | API keys |
The scan is regex against text. It does not need to understand the code that uses the credential; it only needs to recognise the credential when it appears in the binary's string table. That is why a one-line strings | grep finds what Apple's deep static analysis does not.
Why does Apple not include credential scanning?
Three structural reasons.
First, false positives. A pattern like sk_live_ is unambiguous in a real Stripe key; in arbitrary string content it has overlap with debug strings, mock data, or unrelated tokens that happen to start with the same characters. Apple's review queue cannot afford a false positive rate that flags compliant apps.
Second, scope. Apple's review evaluates whether the submission complies with Apple's rules. A Stripe key in your binary is your problem, not Apple's. The guidelines assign that responsibility explicitly in section 5.1.1 of the App Review Guidelines.
Third, the alternative would invite an arms race. If Apple started flagging credential patterns, developers would obfuscate the credentials to bypass the pattern match. Obfuscated credentials are no more secure (a runtime dump still reveals them) but they would pass Apple's pattern check, which would give developers a false sense of safety. The current arrangement is more honest: Apple does not pretend to do this; developers know they have to.
How do I actually scan my own IPA?
Four commands on any Mac or Linux machine:
unzip MyApp.ipa
cd Payload/MyApp.app
strings MyApp | grep -E 'sk_(live|test)_|rk_(live|test)_|AKIA|ASIA|sb_secret_|sk-ant-|SG\.'
find . \( -name '*.plist' -o -name '*.json' \) -exec grep -lE 'sk_(live|test)_|AKIA' {} \;
The third line covers the main executable. The fourth covers Info.plist, embedded JSON configs, and AWS Mobile SDK awsconfiguration.json. Any match is a finding.
For a more thorough scan that includes embedded frameworks and produces a MASVS-mapped report, PTKD.com (https://ptkd.com) accepts an uploaded IPA and runs the same patterns plus several dozen others. The output identifies the file path where each credential was found, the credential type, and the architectural rewrite that removes the need to embed it.
What to watch out for
Three details that recur during pre-submission audits.
First, test-mode keys (sk_test_, pk_test_) are still credentials. A shipped binary with sk_test_ works against your Stripe test environment, which may contain real customer data copied from production. Treat both modes as findings.
Second, environment-specific keys can hide in build configurations rather than in source code. Xcode supports build settings that vary per scheme; some teams put the production secret in the Release scheme and the test secret in Debug. Both end up in the binary the moment the bundle ships.
Third, the AWS Mobile SDK's awsconfiguration.json and Firebase's GoogleService-Info.plist are both common hiding spots. The configuration files are meant to ship in the bundle (they hold non-secret identifiers), but developers sometimes add secret-shaped values to them. The scan has to include both filenames specifically.
Key takeaways
- Apple's automated scan checks for private API usage and policy compliance. It does not pattern-match for credentials.
- Credential scanning is a separate, simpler operation. The tools are open-source and the scan takes seconds.
- The architectural fix is removing the need to embed a credential at all: server-side Payment Intents for Stripe, Cognito Identity Pools for AWS, Edge Functions for Supabase.
- For a thorough pre-submission scan, PTKD.com (https://ptkd.com) covers dozens of credential patterns and maps findings to OWASP MASVS.
- Rotation alone does not fix the leak; document the rotation, the architectural change, and the audit in your CHANGELOG.
