Why Apps Get Rejected — and How to Pass Review the First Time
Privacy declarations that don't match behaviour
Both stores now require detailed disclosure of what data you collect, why, and which third parties receive it — and reviewers check declarations against observed network traffic. The common failure is an SDK collecting identifiers that nobody on the team knew about, because it was added for analytics or advertising two years ago. Audit your dependencies and their data behaviour before submitting, and keep the declaration updated when SDKs change. This is now one of the largest single causes of rejection and it is entirely preventable.
Account deletion and sign-in requirements
If your app lets users create an account, it must let them delete it from within the app, not by emailing support. Apps offering third-party social login on iOS generally need an equivalent privacy-respecting option. And requiring registration before the user can see anything of value is challenged when the app's core function does not need an account. These are simple to satisfy in the build and expensive to discover during a launch week review cycle.
Payments and the in-app purchase boundary
Selling digital content or features consumed in the app generally requires the platform's purchase system, while physical goods and services delivered in the real world do not. The rules around linking to external purchase options have shifted through regulatory pressure and vary by jurisdiction, which makes this the area where guidance ages fastest — check current policy for each store and each market before designing your monetisation. Ambiguity here is worth resolving with the platform before you build, not after.
Incomplete submissions and broken demo access
A large share of rejections are procedural: a demo account that does not work, a feature behind a code the reviewer was not given, a crash on the reviewer's device configuration, placeholder content still visible, or a privacy policy URL returning an error. Run through the submission as a stranger with a clean device before sending. This costs an hour and saves a review cycle, which is typically several days of schedule.
Minimum functionality and web wrappers
An app that is a thin wrapper around your website with no platform capability offers nothing the browser did not, and reviewers reject it on that basis. If your app is largely web content, give it a real reason to exist on the device — offline capability, push notifications, camera or location integration, biometric authentication, native navigation. This is also just good product advice: users abandon wrapper apps quickly even when they get through review.
Plan the calendar around review, not despite it
Assume a first submission may bounce, and submit at least two weeks before any date you have promised marketing. Use phased release for large updates so a problem reaches a small percentage first. Keep a tested rollback path. And read the current guidelines yourself before each major release — they change several times a year, and 'it passed last time' is not a defence anyone at the store will accept.
Have a project that needs this kind of thinking?
Let's talk through what you're building — free consultation, no commitment.
Get in Touch