Guide
Your app was rejected for security. What now?
The rejections Apple and Google actually issue, what causes them, and how to get back in review quickly.
Short answer
Most security rejections cite App Store Review Guideline 5.1.1 or Google Play's User Data policy, and the usual causes are hardcoded secrets, unencrypted data in transit or at rest, excessive permissions and a missing privacy declaration. Fix the cited issue, document the change, and resubmit with a note naming what you corrected.
A security rejection is usually one specific, findable thing — not a verdict on your app. The frustrating part is that the review note rarely tells you which thing, and each resubmission costs you days.
Here are the causes that come up again and again, roughly in order of how often they are the answer.
The usual causes
Secrets compiled into the binary. API keys, cloud credentials, signing secrets and third-party tokens sitting in the app. Anyone can unzip an IPA or decompile an APK; reviewers and automated scanners do exactly that. This is the single most common one.
Data stored insecurely on the device. Tokens or personal data in plain UserDefaults, SharedPreferences, or an unencrypted SQLite file, instead of Keychain or Keystore.
Transport security disabled. An ATS exception on iOS or a permissive network security config on Android, usually added during development to make a staging server work and then never removed.
Privacy declarations that do not match behaviour. The app collects an identifier the privacy manifest does not declare, or an SDK you embedded does. Apple's required reasons API and Google's Data Safety form are both checked against what the binary actually does.
An outdated or disallowed SDK. A dependency with a known vulnerability, or one on a platform blocklist, pulled in three layers deep by something you did choose.
Debug surface left in the release build. Verbose logging, a developer menu, a test endpoint, or an exported Android component that should not be exported.
How to fix it without guessing
Reviewers test the binary, so test the binary. Take the exact artefact you submitted and go through it the way they do: decompile it, read the strings, list what it stores on disk after a login, watch what it sends and to whom, and check every SDK in the dependency tree against what your privacy declarations claim.
That pass is what OWASP MASVS describes, and it is what our Full Assessment does for one platform. It usually takes less time than one more rejected resubmission.
One warning: fix the class, not the instance. Rotating the one key a reviewer found and resubmitting gets you rejected again next week for the other three.
Avoiding the second rejection
Resubmitting with a single fix and hoping is the most expensive strategy available — each round is days, and repeated rejections attract closer review rather than less. Fix everything in the class at once, verify against the built artefact rather than the source, and include a clear note to the reviewer describing what changed.
If you have a launch date, budget for one rejection. If you have already had one, get the binary checked properly before you send the next build.