A smooth App Store and Google Play submission, approved first time, needs four things ready before you press submit: active developer accounts, a stable build tested on real devices, complete store listings with accurate privacy disclosures, and a working demo login for the reviewer. Most rejections come from missing one of these, not from the code itself.
Apple and Google review every app before it goes public. Apple's process is stricter and more human; Google leans more on automated policy checks, with tighter rules for new developer accounts. Both publish their rules (the App Store Review Guidelines and the Google Play Developer Policy Center), and both update them regularly, so check the current versions before each major release.
This checklist sits within our wider guide to mobile app development for businesses. If you're still planning your build, read how long it takes to build a mobile app first, because submission deserves its own slot in the schedule.
What do you need before you can submit at all?
You need a developer account on each store, owned by your business, not your developer. If the agency or freelancer owns the account, they effectively own your app's listing.
| Item | Apple App Store | Google Play |
|---|---|---|
| Developer account | Apple Developer Program, annual fee (US$99/year at the time of writing) | Google Play Console, one-time registration fee |
| Organisation verification | D-U-N-S number required for company accounts | Identity and organisation verification required |
| Who should own it | Your business, with your developer added as a team member | Your business, with your developer given user access |
| Testing channel | TestFlight (internal and external testers) | Internal, closed and open testing tracks |
| Extra step for new accounts | None beyond verification | Newly created personal accounts must run a closed test with a group of testers before production access |
| Staged release | Phased release over about a week | Staged rollout by percentage of users |
Start account setup in week one of the project. Organisation verification can take several days, and Apple's D-U-N-S lookup (a free business identifier from Dun & Bradstreet) sometimes needs your company details corrected first.
What does the pre-submission checklist look like?
Work through this list in order. Each item maps to a common reason for rejection or delay.
Build quality
- ☐ Tested on at least one older and one newer phone per platform, plus a tablet if your app supports tablets
- ☐ No crashes in the main flows: sign-up, login, core action, payment, logout
- ☐ Works on a slow or patchy connection, with clear error messages instead of blank screens
- ☐ Built with the current required SDK versions (Google Play sets a minimum target API level each year; Apple sets minimum Xcode and SDK versions)
- ☐ No test screens, "lorem ipsum" text, debug menus or broken links left in
Reviewer access
- ☐ Demo account username and password entered in the review notes
- ☐ Demo account has realistic data, so the reviewer can see every feature
- ☐ If features need hardware, a location or a QR code, explain how to test them, or include a short video
- ☐ Any feature behind a paywall is either testable with the demo account or explained in the notes
Privacy and data
- ☐ Privacy policy published on your website and linked inside the app and in both listings
- ☐ Apple's App Privacy details and Google's Data safety form completed accurately, including data collected by analytics and advertising SDKs (the third-party code libraries your developer adds)
- ☐ Every permission request (camera, location, contacts, notifications) has a clear, specific reason shown to the user
- ☐ Users who can create an account can also delete it from inside the app; Google also asks for a web link where deletion can be requested
Store listing
- ☐ App name within the character limit and not stuffed with keywords
- ☐ Screenshots taken from the real app, at the required sizes, showing current screens
- ☐ Description that matches what the app actually does today
- ☐ Age rating questionnaire answered honestly
- ☐ Support URL and contact email that work
Payments
- ☐ Digital goods and subscriptions sold inside the app use Apple's and Google's in-app purchase systems
- ☐ Physical goods and real-world services (food, bookings, deliveries) use your own payment provider, which is allowed
- ☐ Subscription terms, price and renewal are shown clearly before the user pays
What are the most common rejection reasons?
Most rejections fall into a handful of predictable categories. Reviewers reject what they can't test or can't understand, so clarity in your review notes prevents half of these.
| Rejection reason | What the reviewer experienced | How to fix it |
|---|---|---|
| Crashes or bugs | The app froze or closed during testing | Test the exact build you submit on real devices; check crash reports in TestFlight or Play Console |
| Can't log in | Demo credentials missing, expired or locked behind SMS codes | Provide a working demo account that bypasses one-time codes, or explain the process |
| Incomplete content | Placeholder text, empty screens, "coming soon" sections | Remove unfinished features or hide them until ready |
| Too little functionality | The app is essentially a website in a wrapper | Add genuine app value (offline use, notifications, device features) or launch as a website or progressive web app instead |
| Privacy mismatch | Data collected that isn't disclosed, or no privacy policy | Audit every SDK; update App Privacy and Data safety answers to match |
| Vague permission requests | A pop-up asked for location with no clear reason | Write specific purpose text, and request permissions only when the feature is used |
| No account deletion | Users can sign up but can't delete their account | Add an in-app deletion flow and, for Google, a web request page |
| Payment rule breach | Digital content sold via an external checkout | Use in-app purchase for digital goods, or restructure the offer |
| Misleading metadata | Screenshots or description promise features not in the app | Align the listing with the current build |
| Sensitive permissions (Google) | App requests background location, SMS or call logs | Remove them, or complete the declaration explaining the core use |
The "too little functionality" rejection deserves a special mention. Apple in particular is unwilling to approve apps that add nothing beyond a mobile website. If your plan is to wrap your existing site, read our comparison of web apps, websites and mobile apps before investing in store submission.
How should you handle a rejection?
Read the message carefully, fix the specific issue, and reply in the review system with what you changed. Don't resubmit the same build hoping for a different reviewer.
- Find the exact guideline cited. Apple's Resolution Center and Google's Play Console policy status both name the rule.
- Decide if it's a misunderstanding. Sometimes the reviewer missed a feature. A polite reply with steps or a screen recording can resolve it without a new build.
- If it's a real problem, fix and resubmit. Note the change in the review notes so the next reviewer can verify it quickly.
- Appeal only when you're confident. Both stores have appeal routes. Use them for genuine disagreements, not to argue with clear rules.
Keep a simple log of every rejection and fix. It becomes your own checklist and helps if you change developers.
How do you plan the release itself?
Release gradually, so problems reach a small share of users first. Apple's phased release and Google's staged rollout let you pause if crash reports spike.
- Use manual release on iOS for launches tied to a marketing date. The build is approved in advance and you choose the moment it goes live.
- Start a Google staged rollout small, then increase it after a day or two of clean crash data.
- Prepare your support channel before launch day. Early reviews in the store are shaped by how fast you respond to the first problems.
- Plan for regular updates. Both stores keep raising their SDK and policy requirements, which is one reason ongoing mobile app maintenance costs belong in your budget from the start.
Frequently asked questions
How long does app review take?
Apple's review often completes within a few days, while Google Play reviews vary and can take longer for new developer accounts. Plan one to two weeks for the whole submission phase so that one rejection doesn't push your launch date. Updates to an existing app are usually reviewed faster than a first submission.
Can my developer submit the app under their own account?
They can, but you shouldn't let them. Transferring an app between accounts later is possible but adds work, and you lose control of the listing and reviews if the relationship ends. Create the accounts in your business name and invite your developer as a team member.
Do I need a privacy policy if my app doesn't collect personal data?
Yes. Both stores ask for a privacy policy link, and most apps collect some data through analytics, crash reporting or login. The policy should match what you declare in App Privacy and Data safety, so review it whenever you add a new SDK.
Why was my app approved on Google Play but rejected by Apple?
The two stores apply different rules and different review methods. Apple places more weight on design quality, minimum functionality and in-app purchase rules, so an app that passes Google's checks can still fail Apple's. Fix the Apple issue and keep both versions consistent where you can.
Will an update ever get rejected after the app is live?
Yes. Every update is reviewed, and policy changes can catch apps that were approved under older rules. Keeping SDKs current, privacy answers accurate and your demo account working avoids most surprises.
Getting your app through review
A clean first submission is mostly preparation: accounts in your name, honest privacy disclosures and a reviewer who can see every feature. If you'd like a team that handles the build and the store process end to end, see our services and talk to us about your app launch.