TL;DR: Most App Store and Google Play rejections are not about your code. They come from a handful of predictable gaps: the reviewer could not log in, the app looks incomplete or like a thin website wrapper, there is no in-app way to delete an account, digital purchases bypass the store's billing, the privacy labels do not match what the app actually does, or (increasingly) user data goes to a third-party AI model without clear disclosure. On Google Play there is one more trap for new personal developer accounts: you need a closed test with at least 12 testers for 14 consecutive days before you can publish to production at all. I managed App Store and Play Console releases as CTO at RAQTS across React Native apps and a Unity platform, and this is the checklist I now run before every first submission so review becomes a formality instead of a week-long back and forth.
Founders tend to treat store review as a final hurdle on launch week, which is exactly why it hurts. A rejection on launch day costs you a press date or a campaign. A rejection two weeks earlier, on a build you submitted on purpose, costs you nothing.
Submit early, on purpose
Treat the first submission as a test, not a launch. Get a real build through review weeks before the date that matters, then ship updates on top of an app that already exists in the store.
Both stores let you hold an approved build back. On Apple you can choose manual release after approval. On Google Play you can stop a release at the review stage or publish to a closed or internal track first. Either way you learn what the reviewer objects to while you still have time to fix it calmly.
Review is usually quick now, but a first-time app on a new account gets more scrutiny than an update. Plan for one rejection and a resubmit.
The Google Play gate most founders do not know about
If you create a new personal Google Play developer account, you cannot publish straight to production. You must first run a closed test with at least 12 testers who stay opted in for 14 consecutive days, and then apply for production access, answering questions about how you tested.
This is a calendar problem, not a technical one. Find out on launch week and you are two weeks late before anyone reviews the app.
Two ways around the surprise:
- Register an organization account if you have a company. Organization accounts need verification (a D-U-N-S number and business details), which takes its own time, but they are not subject to the 12-tester rule in the same way.
- Start the closed test the moment you have a usable build. Recruit real testers, not twelve email addresses you control. Google asks what you learned from them, and an honest answer is easy if people actually used the app.
The general lesson: whoever owns the developer accounts should be set up in week one, not week ten. I made the same point in how to hire a Unity developer: the company should own the store accounts and signing keys, never the contractor.
The rejections I plan for on every app
1. The reviewer could not get in
If your app needs an account, give the reviewer one. Apple has a dedicated field for demo credentials in the App Review Information section, and Google Play has an equivalent under App access. The account should already be set up with realistic data, not an empty state where every screen says "nothing here yet".
At RAQTS this mattered more than usual, because the product connected players and facilities. An account with no facility, no sessions and no leaderboard history shows a reviewer a product that looks broken. The fix is a seeded demo account that exercises the main flows, and review notes that say in two sentences what the app does and where the interesting part is.
If a feature depends on hardware or a physical location, say so and include a video. A reviewer cannot walk into a sports facility or stand in a field with an AR headset, which is the same problem I describe in field testing AR apps.
2. It looks incomplete or like a website in a box
Apple rejects apps that crash, show placeholder content, have dead buttons, or link to "coming soon" pages. It also rejects apps whose main value is a wrapped website with little native functionality.
Hide unfinished features behind a flag rather than leaving them visible. The thin wrapper case is a product question. If your mobile app is your web app in a WebView, ask what the app does that the website does not: push notifications, offline access, native camera or audio, widgets. If the honest answer is nothing, the store is telling you something real. I covered the framework side of that decision in React Native vs Flutter vs native.
3. No in-app account deletion
Both stores now require that if users can create an account, they can delete it. Apple wants the deletion to be initiated inside the app. Google Play also requires a web link where users can request deletion without reinstalling the app.
"Email us to delete your account" is not enough. Build a real delete flow in version one: confirm, delete or anonymize server data, sign the user out.
4. Payments that skip the store
If you sell digital content, features or subscriptions consumed inside the app, the default rule on both stores is that you use their billing. Physical goods and real-world services, like booking a court at a facility, are different and can use your own payment processor.
The rules here have loosened in some regions after legal changes, and they keep moving, so check the current guidelines for the storefronts you launch in. What does not change is that the reviewer will look at every paywall, every "Upgrade" button and every link that goes to a checkout page. Decide your billing model before the first submission, not after the first rejection.
5. Privacy labels that do not match reality
Apple's privacy nutrition labels and Google Play's Data safety form ask what data you collect, why, and whether it is linked to the user. Reviewers and automated checks compare those answers against what your app and its SDKs actually do.
The common mistake is forgetting the SDKs. Analytics, crash reporting, attribution and ad libraries all collect data on your behalf. List every third-party SDK in the app, read what each one collects, and fill in the forms from that list. On Apple, also make sure your privacy manifest covers any required-reason APIs your code or dependencies use, or the upload will be flagged before a human even looks at it.
6. AI features without disclosure or controls
This is the category that has grown fastest, and it matters for most of the apps I build now. Apple's guidelines require apps to clearly disclose when personal data is shared with third parties, including third-party AI, and to get the user's permission first. If your app sends a user's voice, notes or photos to an external model, say so plainly in the flow where it happens, not only in the privacy policy.
Google Play's policy on AI-generated content adds another requirement: if your app generates content with AI, users need a way to report or flag offensive output from inside the app. A simple "Report this response" action wired to a backend log satisfies the intent and is useful to you anyway.
The broader principle is the same one I use for voice agents in call recording consent and AI disclosure: tell people when an AI is involved and what happens to their data, early and in plain words. It is good for review and good for trust.
7. Metadata that overpromises
Screenshots must show the actual app. Descriptions cannot claim features that are not there, mention other platforms, or make health and medical claims the app cannot back up. For anything near health, wellness or diagnostics, be careful with the words "diagnose", "treat" and "cure" unless you have the regulatory standing to use them. Clinical tools like the eye-tracking diagnostics I worked on at Nystag live under very different rules from a consumer self-improvement app, and the store copy should reflect which one you are.
Reading a rejection without panicking
When a rejection arrives, it cites a guideline number and usually a short explanation, sometimes with a screenshot. Three habits help:
- Reply in the review thread before resubmitting if you think the reviewer misunderstood. A clear, polite explanation with a video often resolves it without code changes.
- Fix the category, not just the instance. If they flagged one dead link, check every link. A second rejection for the same guideline is slower and more frustrating than the first.
- Use the appeal and expedited review options sparingly. Apple offers both, and they work best when you have a genuine reason, like a critical bug fix for live users.
Release discipline after the first approval
Getting approved once is the start. For updates on a live product, I lean on the stores' own safety tools:
- Phased release on Apple and staged rollout on Google Play, so a bad build reaches a small slice of users before everyone.
- A minimum-version gate on the backend, because old builds stay in the wild for months. I wrote about that in designing a backend for old mobile app versions.
- Builds from CI, not laptops, so the signing keys and the release process do not depend on one person. The Unity CI/CD notes apply almost unchanged to React Native and Flutter.
- Target API level reminders. Google raises the required Android target level every year. If an app sits untouched, it eventually stops being offered to new users on newer devices. Put the date in a calendar.
At RAQTS the release pipeline was one of the first places I put my weight when I stepped in as CTO, because a platform people depend on every day cannot afford a release that surprises anyone, least of all the reviewer.
My pre-submission checklist
- Developer accounts created and owned by the company, Play closed test started early if required.
- Seeded demo account and two-sentence review notes, plus a video for hardware or location features.
- No placeholder screens, dead buttons or "coming soon" links.
- In-app account deletion, plus a web deletion link for Google Play.
- Billing model decided for every paid feature.
- Privacy labels and Data safety form filled in from a real SDK list, privacy manifest checked.
- AI data sharing disclosed in the flow, with user consent and a way to report AI output.
- Store copy and screenshots that match the actual build.
None of this is hard. It is the work that turns store review from a launch-week gamble into a box you tick.
I build mobile, web, XR and AI products for founders, and take on fractional CTO roles for teams that need someone to own the technical side, releases included. If you are getting ready for a first submission or stuck in a rejection loop, more about my background here, or book a call and we can get your app through.