Getting Through App Store and Google Play Review
By CodexierPublished 6 min read
Every app goes through a human or automated review before it appears in the App Store or Google Play, and most first submissions are rejected for reasons that have nothing to do with code quality: a login screen the reviewer cannot get past, a privacy label that contradicts the app, a screenshot showing a feature that does not exist. This guide explains how review works on each store, the rejections we see most, and how to prepare a submission that passes the first time.
The short answer
Store submission is part of every cross-platform app build we deliver, and it is where a launch date most often slips when a team does it for the first time.
How review works on each store
| Aspect | Apple App Store | Google Play |
|---|---|---|
| Who reviews | Human reviewers against the App Review Guidelines | Automated scanning plus human review for policy areas |
| Typical time | Usually within 48 hours, longer at first submission | Hours to several days; new developer accounts wait longest |
| Testing before release | TestFlight, with its own lighter review for external testers | Internal, closed and open testing tracks |
| New personal accounts | Standard review | Required closed testing with real testers for a set period before production |
| Rejection communication | Message in App Store Connect citing a guideline number | Email and console notice citing a policy |
Both stores update their rules several times a year. Read the current guidelines the week you submit, not the version you remember.
One practical difference matters for planning: Apple's reviewer will actually use the app, so anything they cannot reach or understand becomes a rejection. Google's automated checks focus on permissions, data safety declarations and policy categories, so mismatches in the console are the usual failure there.
Common rejection reasons
- The reviewer cannot log in: no demo account, BankID-only login with no alternative, or a verification code sent to a phone they do not have.
- The app is a website in a shell with nothing an app adds. Apple rejects these under minimum functionality.
- Crashes or obvious bugs on the reviewer's device, often an iPad or a screen size the team never tested.
- Privacy labels or data safety form contradict what the app does, such as declaring no data collection while using analytics.
- Permission prompts without a clear reason: the string explaining why you need the camera or location is missing or generic.
- Payments for digital content that bypass the store's in-app purchase, or a subscription without the required terms and restore option.
- Screenshots or descriptions that show features not in the build, or mention other platforms.
- Missing account deletion: both stores require that a user who can create an account in the app can also delete it.
Demo accounts and reviewer notes
The single most effective thing you can do is write the reviewer a note. They see hundreds of apps and have minutes for yours. Tell them in a few sentences what the app is for, who uses it, and how to reach each main feature. Give a demo login that works, with data already in it, and that does not expire or require a code sent elsewhere. If the app depends on hardware, a physical location or a membership, explain how the reviewer can still exercise it: a demo mode, a test QR code, a video.
Swedish apps and BankID
A reviewer in another country cannot use BankID. Provide a test login path that bypasses it for review, gated to a demo account, and say so in the note.
Apps for existing customers only
Explain that users are onboarded by your company and supply a full demo account. Apple accepts this if the note is clear.
Internal staff apps
Consider unlisted distribution on Apple or a private track on Google rather than public listing, which also softens review.
Privacy details and permissions
Both stores now require a public declaration of what data the app collects and why, and both check it against the app. Before you fill in Apple's privacy labels or Google's data safety form, list every SDK in the app, analytics, crash reporting, maps, payments, push, and what each sends. The declaration must cover all of it, the privacy policy linked from the listing must match, and under GDPR you must have a legal basis for each item anyway, so the exercise is not wasted. Then look at every permission the app requests, remove those it does not need, and write a specific one-sentence reason for each one that remains. A location prompt that says the app needs your location is rejected; one that says it needs your location to show the nearest workshop is not.
Responding to a rejection
A rejection is a message, not a verdict. Read the cited guideline, work out whether the reviewer misunderstood the app or found a real gap, and respond accordingly. If they could not log in, reply in the resolution centre with better instructions and, if needed, a screen recording; often no new build is required. If the issue is real, fix it, submit a new build, and reference the previous conversation in the note. Argue politely only when you are certain the guideline does not apply, and expect that to take longer than fixing. Keep every reviewer exchange in a shared document so the next release does not repeat it.
When you do not need help with this: a team that has shipped to both stores before, with an existing developer account and a routine for privacy declarations, can handle review internally. It is the first submission, the BankID login and the privacy paperwork that cost first-time teams weeks. If that is where you are, or if you are still deciding whether you need an app at all, our guide on app, PWA or mobile website comes first, and a fifteen-minute call settles the rest; our fixed app prices are on the pricing page.
Frequently asked questions
How long should we allow for review in the launch plan?
Allow two weeks from first submission to approval for a new app on either store, even though the typical case is faster. That covers one rejection cycle, and on Google Play the mandatory testing period for a new personal developer account, which can be considerably longer.
Do we need in-app purchase for subscriptions?
If the subscription unlocks digital content or features inside the app, yes on both stores, with their commission. Physical goods and services consumed outside the app, such as a gym membership or a booking, may use your own payment flow. Grey areas exist; ask before building, not after rejection.
Can we publish an app that only works for our own customers?
Yes. Explain in the reviewer note that accounts are provisioned by your company and supply a working demo account. For staff-only apps, Apple's unlisted app distribution and Google's private or managed distribution avoid public listing entirely.
What happens to review after the first release?
Every update is reviewed again, usually faster. Keep the demo account alive, update the reviewer note when features change, and re-check the privacy declarations whenever an SDK is added. Most later rejections come from a stale demo account or a new SDK that was not declared.
Submitting an app for the first time?
Tell us what the app does and how users log in. In fifteen minutes we list the reviewer note, demo account, privacy declarations and permission texts you need before you press submit.
Book a free 15-minute call