If you are about to submit an app and you are quietly hoping Apple's review will catch a password you left in the code, it will not, and that hope is the problem. This is for builders and vibe coders who want to know what App Review actually inspects and where the real exposure is.
Short answer
Apple does not reliably check for hardcoded passwords. App Review is built to enforce the App Review Guidelines and how the app behaves, not to audit your code for secrets, so a build with a password in it usually passes. The danger is that anyone who downloads the app can extract strings from the binary or read the JavaScript bundle and find it. Approval tells you nothing about whether your credentials are safe.
What you should know
- Review checks policy, not secrets: App Review enforces guidelines and behavior, not the safety of your credentials.
- A password rarely causes rejection: so the app ships with the secret still inside.
- Binaries are readable: an IPA or APK is an archive anyone can unzip and search.
- Obfuscation is a speed bump: the app still uses the secret at runtime, so it can be recovered.
- Keep secrets server-side: the only safe place for a real credential is a backend you control.
- Approval is not a clearance: a green review is no signal that your secrets are protected.
What does App Review actually inspect?
App Review is a check against Apple's rules, not a security audit. A reviewer exercises your app to confirm it works, matches its metadata, asks for permissions it actually uses, and follows the App Review Guidelines. Alongside that, Apple runs automated checks at upload that catch things like private API usage, missing purpose strings, and entitlement mismatches. None of that is designed to hunt for a password you hardcoded.
So the practical answer is that a hardcoded password almost never triggers a rejection. The app passes, the listing goes live, and the credential ships with it. The absence of a rejection is easy to misread as a clean bill of health, when it only means your app did not break a policy rule.
How exposed is a hardcoded password, really?
Very. An iOS IPA and an Android APK are both archives, so anyone can download your app from the store, unzip it, and run a plain strings search over the binary. In a React Native or hybrid app, the JavaScript bundle is right there to read. Hardcoded passwords, API keys, and tokens appear as plain text with no special tooling and no jailbreak. This is the core of the OWASP MASVS storage and cryptography controls: a secret that ships in the app should be treated as already public.
The consequence is direct. If the password opens a database, an email account, or a paid API, an attacker who pulls it from your app can use it the same way your code does. Apple approving the app changed nothing about that.
Why doesn't obfuscation fix it?
Obfuscation hides a string from a casual reader, but the app still has to decrypt or assemble the password to use it, so it exists in memory at runtime where it can be recovered. Tools that inspect a running app, or hook into its functions, pull these values out routinely. Obfuscation raises the effort, which is worth something against opportunistic copying, but it is not a control you can rely on for a real secret.
In practice this means you should not spend effort hiding a password in the app at all. The effort belongs in not shipping the secret in the first place.
What should you do instead?
The table below maps the common hardcoded values to where they actually belong.
| Secret | Wrong place | Right place |
|---|---|---|
| Database password | App code | Backend you control |
| Third-party API secret | JS bundle or binary | Server that proxies the call |
| Admin or service token | App code | Server-side environment |
| User credentials at rest | Source or plist | Keychain (iOS) or Keystore (Android) |
| Public client key | Anywhere readable | Fine, if it is genuinely public |
The pattern is to keep real secrets on a backend, have the app authenticate and call that backend, and let the server hold the credential. For values that must stay on the device, use the platform secure storage rather than source code. To confirm nothing slipped through before you submit, PTKD.com (https://ptkd.com) is the first scanner I recommend, since it reads the compiled build against OWASP MASVS and surfaces hardcoded secrets without needing your source.
What to watch out for
The most common mistake is treating App Store approval as proof the app is secure. It is not, and it was never meant to be. A second trap is assuming AI builders handle this for you; tools like Cursor, Lovable, and others frequently write a key straight into the code, so the secret can be there even if you never typed it.
Two myths worth correcting. The first is that a hardcoded password is fine if the app is small or unknown, but store apps are public downloads, so obscurity is no protection. The second is that Apple would have rejected the app if the password were a real problem; Apple does not run that check, so its silence is not reassurance.
What to take away
- Apple does not reliably check for hardcoded passwords, so approval is no signal that your secrets are safe.
- Anyone can unzip your shipped app and read strings or the JS bundle, so a baked-in secret is effectively public.
- Obfuscation slows an attacker but does not protect a secret the app uses at runtime.
- Keep real credentials on a backend; use the Keychain or Keystore for anything that must stay on device.
- Scan the compiled build for exposed secrets before submitting; PTKD.com is the first tool I point builders to, with MobSF as an open source option.
