The App Store and Google Play Pre-Submission Checklist (2026)

A store submission feels like the end of a project, which is exactly why it goes wrong. Everyone is tired, the launch email is scheduled, and the one thing nobody checked (a demo account, a privacy label, a screenshot from last month) becomes a rejection, or worse, a bad first impression with real users.

This is an app store submission checklist for both Apple's App Store and Google Play, ordered by when you should do each step: a week out, the day before, submission day, and the first days after approval. Bookmark it, copy it into your project tracker, and run it for every release, not just the first one.

Key takeaways

• Start a week early. Accounts, testers, store listings and legal pages take longer than the build.
• Test the release build, not the development build, on real iPhones and Android phones, on a slow network.
• Give reviewers everything: a working demo account, notes for any hardware or location features, and a live backend.
• Match your declarations to reality: Apple's App Privacy answers and Google Play's Data safety form must describe what your app and its SDKs actually collect.
• Release gradually: use phased release on iOS and a staged rollout on Android, and watch crash reports before going to 100%.

One week before submission

Accounts and access

• Apple Developer Program membership active, in your company's name.
• Google Play Console account ready. New personal accounts (created after 13 November 2023) need a closed test with at least 12 testers opted in for 14 days before production access, so start that early.
• Signing set up: iOS distribution certificate and profiles (or EAS-managed credentials), Android upload key with Play App Signing enabled.

Store listings

• App name, subtitle or short description, full description and keywords written.
• Screenshots captured from the current build. Apple's main iPhone set is the 6.9-inch size; add a 13-inch iPad set if your app runs on iPad.
• Support URL and marketing URL live.
• Age rating questionnaire completed on both stores.

Legal and privacy

• Privacy policy published at a public URL.
• Terms of service, if you have accounts or payments.
• Apple App Privacy answers and Google Play Data safety form drafted, including what every SDK collects (analytics, crash reporting, ads, payments).

The day before submission

The build

• Release build installed on at least one iPhone and one mid-range Android phone.
• Core flow tested end to end on cellular data and with no connection.
• No placeholder text, test products, debug menus or staging URLs.
• Version and build numbers increased (iOS build number, Android versionCode).
• Crash reporting and analytics confirmed working in the release build.
• Target SDK meets Google Play's current requirement: Android 16 (API level 36) for new apps and updates from 31 August 2026.

Privacy in the app

• Privacy policy linked inside the app.
• Account deletion available in the app if users can create accounts (both stores require it; Google also requires a web link for deletion requests).
• Permission prompts explain the reason in plain language.
• iOS privacy manifest declares every required-reason API your app and SDKs use.

Payments

• In-app purchases created, approved for review and visible in the build.
• Digital goods use the stores' billing where required. Physical goods and real-world services use your own payment provider.
• Restore purchases works.

Submission day

• Demo account and password in the review notes (Apple) and the App access section (Google), with realistic data in the account.
• Review notes explain anything non-obvious: hardware the reviewer won't have, background location, features behind a subscription, regional limits.
• Backend, payment sandbox and third-party services switched on and monitored.
• Release type chosen: manual release after approval, so you control the launch moment.

After approval

• Release with phased release on iOS (Apple spreads automatic updates over seven days) and a staged rollout on Android (you choose the percentage).
• Watch crash-free sessions, error rates and reviews for the first 24 to 48 hours before widening the rollout.
• Keep an over-the-air update ready for JavaScript fixes, within the stores' rules.
• Reply to early reviews. They shape your rating more than any later ones.

From the field: Full release ownership is part of how I work: EAS builds and submissions, OTA hotfixes with EAS Update, Fastlane and GitHub Actions pipelines, phased rollouts, store review including rejections, and crash triage in Sentry. A checklist like this one is what keeps that process boring, which is exactly what a release should be.

If it's rejected anyway

Even a perfect checklist doesn't guarantee approval, because reviewers interpret rules and rules change. When it happens:

1. Read the full message, including the guideline or policy name and any screenshots of what the reviewer saw.
2. Answer questions in the store's own channel: the App Review section in App Store Connect, or Policy status in Play Console.
3. Fix the cause, not the symptom. If a privacy label was wrong, check every SDK, not just the one mentioned.
4. Add the lesson to this checklist so the next release doesn't repeat it.

Most rejections cost a day or two when handled calmly. The expensive ones are the rejections nobody understood, fixed by guesswork, then repeated.

The copyable version

[ ] Developer accounts active, in company name
[ ] Google closed test running (new personal accounts: 12 testers, 14 days)
[ ] Signing ready (iOS certificates/profiles, Android upload key + Play App Signing)
[ ] Store listing text, keywords, screenshots (6.9" iPhone; 13" iPad if supported)
[ ] Support URL, privacy policy URL live
[ ] App Privacy (Apple) and Data safety (Google) match the app and its SDKs
[ ] Release build tested on real iPhone + mid-range Android, slow and no network
[ ] No placeholders, debug menus or staging URLs
[ ] Version and build numbers bumped; target API level meets Google's current rule
[ ] Crash reporting + analytics working in release build
[ ] Privacy policy in app; account deletion in app (+ web link for Google)
[ ] Permission prompts explain why; iOS privacy manifest complete
[ ] In-app purchases visible, working, restorable
[ ] Demo account + review notes (Apple) / App access (Google)
[ ] Backend and services on and monitored
[ ] Manual release; phased (iOS) / staged (Android) rollout planned
[ ] Watch crashes and reviews 24-48 h before 100%

FAQ

What do I need before submitting an app to the App Store?

An active Apple Developer Program membership, a release build tested on real devices, App Store Connect listing details and screenshots, a privacy policy linked in the listing and the app, accurate App Privacy answers, account deletion if users can sign up, and a working demo account with review notes if your app has a login.

What do I need before publishing on Google Play?

A Google Play Console account, an app bundle signed with your upload key, a completed store listing, content rating, Data safety form and App access details for reviewers, a target API level that meets Google's current requirement, and, for new personal accounts, a 14-day closed test with at least 12 testers.

How long before launch should I submit my app?

Submit at least a week before any public launch date. Apple reviews most submissions within 24 to 48 hours, but a rejection adds another cycle, and Google's review times vary. New personal Google Play accounts also need two weeks of closed testing before production access.

Should I use phased releases for every update?

For most apps, yes. Phased release on iOS and staged rollouts on Android limit the damage if a bug slips through, and you can pause or halt while you fix it. Very small apps sometimes release to everyone at once, but the safety is almost free.

Next steps

If you're preparing a release and want someone to run this checklist against your actual build and store setup before Apple and Google do, I can help. Get in touch, or see my services.

Sources

• App Review Guidelines, Apple
• Screenshot specifications, Apple
• Release a version update in phases, Apple
• App testing requirements for new personal developer accounts, Google Play Console Help
• Target API level requirements for Google Play apps, Google
• Understanding Google Play's account deletion requirements, Google Play Console Help