App Store and Google Play Launch Checklist

Launching a mobile app is a small project of its own. The code can be finished and the app still sit in review for days because a privacy field is wrong, a demo account does not work, or a screenshot shows a feature that is not in the build.

This checklist is organized by time, starting a few weeks before launch. Store rules change, so treat the specifics as things to confirm in Apple's and Google's current documentation. The structure holds even when the details move.

Four to six weeks before: accounts and decisions

Account setup is slow and not under your control, so start it early.

• [ ] Apple Developer Program membership. If the app belongs to a company, enrollment as an organization requires business verification, which can take time. Individual enrollment is faster, but the app then appears under a personal name.
• [ ] Google Play Console account. Google verifies identity for developers. Check the current requirements for your account type, including any testing requirements for new personal accounts before you can publish to production.
• [ ] Decide who owns the accounts. The company should own them, with the agency or contractor added as a team member. Moving an app between accounts later is possible but adds work.
• [ ] Bundle ID and package name. Choose them once. They cannot be changed after release without publishing a new app.
• [ ] App name check. Search both stores for conflicts and trademark problems. Names have character limits.

Three to four weeks before: privacy and policy

Privacy is the most common source of rejections and delays, and it is the part teams leave until last.

• [ ] Write a privacy policy at a public URL. Both stores require it. It must match what the app really does.
• [ ] List every kind of data the app collects, including what third-party SDKs collect (analytics, crash reporting, ads, push services). Read each SDK's documentation. You are responsible for what they do inside your app.
• [ ] Complete Apple's privacy details in App Store Connect and Google's Data safety form in Play Console. Answers must agree with your privacy policy and with the app's actual behavior.
• [ ] Permission prompts. Each permission (location, camera, contacts, notifications) needs a usage description that says why you ask, in plain words. Request permissions at the moment the feature needs them, not on first launch.
• [ ] Account deletion. If users can create an account inside the app, both stores expect a way to delete that account from inside the app. Confirm the current rule and build the flow.
• [ ] Third-party sign-in. Apple has rules about offering Sign in with Apple, or an equivalent privacy-preserving option, when you offer other social logins. Check the current guideline.
• [ ] Content and legal. User-generated content needs reporting and blocking tools. Health, finance, kids and gambling categories have extra rules.

Two to three weeks before: store listing

• [ ] Title and subtitle or short description. Put the plain description of what the app does first. Keep promotional language out of the title, since reviewers can reject it.
• [ ] Long description. Lead with the problem the app solves. Keep features factual and match the build.
• [ ] Screenshots. Each store lists required sizes by device class. Use real screens from the real build, with short captions if you add any. Do not show features that are not shipped.
• [ ] App icon. Test it at small sizes on a real home screen, on light and dark backgrounds.
• [ ] Keywords (Apple) and tags or categories (Google). Pick the category that fits the main use, not the one with less competition.
• [ ] Support URL and contact email. A real person should answer it.

Two weeks before: build and testing

• [ ] Release build, not a debug build. Test the signed release build on real devices. Some bugs only appear with code shrinking, obfuscation or production configuration.
• [ ] Production services. Point the app to production APIs, production push keys and production payment settings. Check that test keys are gone.
• [ ] Device matrix. Test on at least one older and one newer phone per platform, one small screen and one large screen, and the lowest OS version you support.
• [ ] Network conditions. Test on weak connections, airplane mode, and switching from Wi-Fi to mobile data in the middle of a request.
• [ ] TestFlight (Apple) and internal or closed testing (Google). Send builds to real testers and collect crash reports. Do this at least a week before submission.
• [ ] Target SDK and tooling requirements. Both stores raise minimum requirements over time (Google's target API level, Apple's required Xcode and SDK versions). Confirm the current minimums before you build the final release.
• [ ] Payments and subscriptions. Test purchase, restore, cancel, and expiry using the sandbox tools provided by each store.

One week before: submission

• [ ] Demo account for reviewers. If login is required, provide working credentials and any special steps in the review notes. A missing or broken demo login is among the most common avoidable rejections.
• [ ] Review notes. Explain anything that is not obvious: hardware needed, region restrictions, how to reach hidden features.
• [ ] Backend is live and stable during review. If your server is down when the reviewer tests, you will be rejected for a broken app.
• [ ] Complete everything in the app. No placeholder text, no "coming soon" screens, no dead buttons. Apple's guidelines call out apps with minimum functionality or unfinished content.
• [ ] Submit for review and choose manual release, so approval does not publish the app before you are ready.
• [ ] Staged rollout (Google). Plan to release to a small percentage first and increase it if crash rates stay low.

Common rejection causes and fixes

Cause	Fix
Reviewer cannot log in	Provide a working demo account and keep it active
Privacy label or Data safety form does not match behavior	Audit every SDK and update the form
Screenshots show features not in the build	Replace them with captures from the release build
Crash on launch on a specific device or OS version	Test the release build across the device matrix
Permission requested without a clear reason	Add a specific usage description and ask in context
Broken links, such as the privacy policy or support page	Open every URL from a clean browser before submitting

Launch day and after

• [ ] Verify the store pages on a real device in each target country.
• [ ] Install from the store, not from a test link, and run the main flow once.
• [ ] Watch crash reports and reviews closely for the first week.
• [ ] Prepare a fix release process. A small bug fix should be able to go out within a day or two of approval time.

FAQ

How long does review take? It varies and neither store promises a time. Plan for a few days on first submissions and leave extra buffer before any fixed date.

Can I launch on one store first? Yes. Many teams ship Android first for faster iteration, or iOS first for the audience. Decide based on where your users are.

What if the app is rejected? Read the reason carefully, fix exactly what is named, reply in the review thread if you disagree with the interpretation, and resubmit.

Talk to us

If you are close to launch and want a second pair of eyes on your submission, or you want help planning a release, write to hello@risingstation.com or use risingstation.com/contact-us.