A rejection a few days before launch is one of the most avoidable delays in mobile delivery. In our experience the cause is rarely a crash or a bad architecture decision. It is a reviewer who could not sign in, a privacy disclosure that does not match what the app collects, or a subscription link that breaks a payment rule.
This guide covers what Apple and Google look at, how to prepare the privacy forms, what reviewers need from you, and how to use test tracks and staged rollouts so a bad release reaches as few users as possible. Store policies change often, so treat this as a checklist of what to verify, and always read the current guidelines before you submit.
How the two review processes differ
Apple reviews every build and metadata change before it reaches users, with a human reviewer involved for most submissions. Google Play combines automated checks with human review, and new apps or new developer accounts tend to face more scrutiny than updates from established ones. Both can reject or suspend an app after release if a policy problem is found later.
| Area | Apple App Store | Google Play |
|---|---|---|
| Rulebook | App Review Guidelines (safety, performance, business, design, legal) | Developer Program Policies plus Play Console requirements |
| Privacy disclosure | App Privacy details (privacy labels) in App Store Connect, plus privacy manifests in the build | Data safety form in Play Console |
| Pre-release testing | TestFlight internal and external testers | Internal, closed and open testing tracks |
| Gradual release | Phased release for automatic updates over seven days | Staged rollout by percentage, can be halted |
| Reviewer access | Sign-in details and notes in App Review Information | App access section in Play Console |
Common rejection reasons, by category
The guideline numbers change between versions, but the categories stay stable. These are the ones we prepare for on every iOS release and every Android build:
Completeness and stability
Crashes, placeholder text, broken links, or features that need a backend the reviewer cannot reach.
Minimum functionality
Apps that are essentially a wrapped website or offer too little native value.
Account and data rules
No way to delete an account created in the app, sign-in required before it is necessary, or unclear permission prompts.
Privacy mismatches
Disclosures that omit data collected by analytics, ads or crash-reporting SDKs.
Payments
Selling digital content outside the store's billing where that is not allowed, or unclear subscription terms.
Metadata
Screenshots that do not reflect the app, misleading descriptions, or references to the other platform.
Privacy labels and the Data safety form
Both stores ask you to declare what data the app collects, why, and whether it is linked to the user or shared. The hard part is that your own code is only part of the answer. Analytics, attribution, crash reporting, ads and customer support SDKs all collect data, and you are responsible for declaring it.
- 1
Inventory every SDK
List each third-party library, what it collects, and link to its own privacy documentation.
- 2
Map data types to purposes
For each data type, record the purpose (functionality, analytics, advertising) and whether it is tied to identity.
- 3
Check iOS privacy manifests
Apple expects privacy manifests for your app and many common SDKs, including reasons for using certain system APIs. Update SDKs that lack them.
- 4
Complete both forms from the same source
Fill in App Privacy details and the Data safety form from one shared inventory so they never contradict each other.
- 5
Re-check on every SDK change
Adding a new analytics tool is a privacy change. Make it part of the release checklist.
Give reviewers everything they need
A reviewer cannot test what they cannot reach. Prepare these before you click submit:
- A demo account with realistic data that does not expire, need two-factor codes sent to your phone, or get locked after failed attempts.
- Notes for gated features, such as an account that needs admin approval, a QR code to scan, or a specific region.
- Hardware workarounds if the app pairs with a device: a demo mode or a short video showing the flow.
- A working backend on the environment the release build points to, monitored during the review window.
- Contact details for someone who can respond quickly if the reviewer has questions.
In-app purchase rules in plain terms
The general rule on both stores: if users buy digital content or features consumed inside the app, such as subscriptions, premium features or virtual currency, you use the store's billing system. Physical goods and real-world services, such as a taxi ride, a meal or a hotel booking, use your own payment provider.
The detail is where it gets complicated. Rules about linking to external purchases and offering alternative billing have changed in several regions in recent years, following regulation and court rulings, and they continue to change. Exceptions also exist for some categories, such as reader apps. Confirm the current rules for every storefront you ship to, and make subscription pricing, renewal terms and cancellation steps clear in the app and in the store listing.
Use test tracks before review
TestFlight lets internal testers on your App Store Connect team install builds quickly, while external testers need a lighter beta review first. TestFlight builds expire after 90 days, so keep a current one available. On Google Play, the internal testing track is the fastest way to get a build onto team devices, and closed and open tracks let you widen the audience.
Newer personal developer accounts on Google Play must run a closed test with a minimum number of testers for a minimum period before they can publish to production. Check the current requirements early, because this can add weeks to a launch plan if you discover it late.
Staged rollouts after approval
Approval is not the finish line. Release gradually so a bug reaches a fraction of users first. Apple's phased release spreads an update to users with automatic updates over seven days, and you can pause it. Google Play's staged rollout lets you choose a percentage, increase it as crash and ANR rates stay healthy, and halt it if they do not.
- Watch crash-free sessions, ANRs, startup time and key funnel events for each rollout step.
- Keep server changes backward compatible, because older app versions stay in use for months.
- Use feature flags so you can switch off a broken feature without another review.
This monitoring is ongoing work, which is why many teams fold release management into post-launch maintenance and support rather than treating each release as a one-off project.
Frequently asked questions
How long does app review take?
It varies. Many submissions are reviewed within a day or two, but new apps, sensitive categories and busy periods can take longer. Build a buffer of several days into any launch date.
What should we do after a rejection?
Read the cited guideline carefully, fix the issue or explain in the resolution center why the app complies, and resubmit. If you believe the reviewer misunderstood, a clear reply with screenshots often resolves it faster than an appeal.
Do we need to declare data collected by third-party SDKs?
Yes. Both stores hold you responsible for everything the app collects, including data gathered by libraries you include. Keep an SDK inventory and review it at every release.
Can we release on iOS and Android on the same day?
Yes, if you submit with enough buffer for both reviews and use manual release on Apple so the approved build waits until you publish both together.
This article is general guidance based on common delivery practice. It is not legal, tax or financial advice; platform rules and regulations change, so confirm current requirements with the relevant provider or adviser.