What makes an app launch different
A website goes live when you deploy it. An app goes live when a reviewer at Apple or Google says it can, and that one fact reshapes the plan. Your launch date is a guess until the build is approved, the listing is limited to what the store allows, and every fix after launch goes back through the same queue.
So work backwards from review rather than forwards from the build. Have the listing, the screenshots, the privacy answers and a demo account for the reviewer ready before you submit, submit well ahead of the date, and use a scheduled or manual release so that approval and launch day are two separate events.
The order that works
Run a beta on real devices first, because it finds the crashes that cause a rejection or a one star first week. Fill in the privacy labels and the store listing together, since both describe what the app does with data and they have to agree. Export screenshots for every size the store requires. Then submit, expect questions, and keep the build you plan to launch with frozen while it is in review.
On Google Play, check your developer account type early. New personal accounts have to run a closed test with a minimum number of testers for a set period before they can publish to production, and that requirement alone can add weeks to the plan.
Type specific
0/5These items appear only for the launch types you selected.
A rejection costs days of review time you cannot get back, and your launch date does not move with it.
What to check
Read Apple's App Review Guidelines and Google Play's Developer Program Policies against what your app actually does: sign-in, payments, user generated content, data collection and anything that resembles another app. Every feature a reviewer can reach has to work without special setup.
How to check it
Walk through the app as a stranger would, with a fresh install and no data. Put a working demo account and short instructions in the review notes: App Store Connect has a field for sign-in details, and Play Console has an app access section. If you sell digital goods, check you use the store's in-app purchase where the rules require it.
What goes wrong
The usual rejections are a crash the reviewer hits, a login screen they cannot get past, links to empty or unfinished pages, and payment flows that go around in-app purchase. Each one costs a full review cycle, so a rejection the week before launch usually moves the date.
Both stores refuse the submission outright if a required size is missing.
What to check
The App Store needs screenshots for the largest iPhone display size it currently requires, and for iPad if the app runs on iPad; smaller sizes can be scaled from those. Google Play needs at least two phone screenshots and a 1024 by 500 feature graphic, and tablet screenshots if you want to appear well on tablets.
How to check it
Open the screenshot section in App Store Connect and the store listing in Play Console before you design anything, and note the exact pixel sizes they list today, because they change with new devices. Export each size from one design file rather than resizing afterwards, and check the text is readable at the size the store shows in search results.
What goes wrong
Uploads rejected for being a few pixels off, iPad left on as a supported destination so submission is blocked without iPad screenshots, and screenshots of an older interface that get the listing flagged as misleading. The first three screenshots do most of the selling, so a set that opens on a settings screen wastes them.
Both stores require them, and correcting them later means going back through review.
What to check
Apple's App Privacy section and Google Play's Data safety form both ask what data the app collects, whether it is linked to the person, whether it is used for tracking and whether it is shared. That includes what the SDKs you ship collect: analytics, crash reporting, ads and sign-in.
How to check it
List every SDK in the build and read its privacy documentation; many publish the answers for both forms. Compare your answers with your privacy policy, which both stores link to, and with the permission prompts the app shows. Apple also expects privacy manifests from many common SDKs, so update them to current versions before you archive the build.
What goes wrong
Answers that leave out an SDK's data collection get questioned in review or reported after launch. Declaring tracking you do not do puts a warning on your listing that puts careful buyers off, so answering too broadly has a cost as well.
Real devices on real networks find crashes a simulator never will.
What to check
Get the build onto real devices you do not own, on real networks, used by people who did not build it. Watch for crashes on launch, sign-in problems, push notifications, sandbox purchases and anything that depends on a slow or dropped connection.
How to check it
On iOS, TestFlight lets you add internal testers straight away, while external testers need the build to pass a lighter beta review first. On Android, Play Console has internal, closed and open testing tracks. New personal developer accounts must run a closed test before they can publish to production; at the time of writing that means at least 12 testers opted in for 14 days in a row, so check Play Console for the current rule before you set a date.
What goes wrong
Testers who never open the build, a beta that starts too late to fix what it finds, and on Google Play a closed test that falls short of the requirement because testers opted out. Crash reports from a beta are only useful if error tracking is already in the build.
Store search is where most app installs begin, and the fields are small enough to be worth thinking about once.
What to check
On the App Store, the name and subtitle (30 characters each) and the hidden keyword field (100 characters) decide which searches you appear in. Google Play has no keyword field: it reads the title, the 80 character short description and the full description.
How to check it
Write down the words a buyer would type before they know your name, then check the store's search suggestions for each one. On the App Store, separate keywords with commas and no spaces, and do not repeat words already in the name or subtitle. On Google Play, use the main phrases naturally in the short and full descriptions.
What goes wrong
Spending the name on a brand nobody searches for yet, repeating the same word across fields, and using competitor names, which the stores can reject. App Store keywords are also tied to a version, so changing them waits for your next submission.
Questions
FAQHow early should I submit to review?
Early enough to absorb one rejection and still hit your date. First submissions are rejected often, usually for something small.
Can I schedule the release?
Yes on both stores, and you should. Get the build approved, then release it on the day you planned rather than the day it clears.
What gets apps rejected most often?
Crashes and broken flows the reviewer runs into, a sign-in they cannot get past, placeholder content, and privacy answers that do not match what the app does. Give the reviewer a working demo account and a note on anything that is not obvious.
Do I need both stores on day one?
No. Launching on one platform first halves the review work and the device testing. Pick the platform your buyers use, launch there properly, and add the other once the first is stable.
Do I still need a website?
Yes. The privacy policy, the support address and the press links all live there, and both stores ask for them.
Should I run a TestFlight or closed beta?
If you can. Real devices on real networks find crashes a simulator does not, and it is cheap insurance against a one star first week. On Google Play a closed test may be required before you can publish at all.
What about Product Hunt for an app?
It works for consumer apps. It is a poor fit if your buyer is an enterprise, which is what the skip note on that item says.
These phases apply to every kind of product. Open any item for its reasons, or read them all on the full product launch checklist.
Before you launch
0/5Product ready
0/5Website ready
0/10Launch assets
0/6Get listed
0/6For some product types the store or the registry is the whole distribution channel, not one listing among many. Mobile app: the App Store and Google Play. Browser extension: the Chrome Web Store. AI tool: the AI directories. Open source: GitHub topics and a tagged release.
Launch day
0/4First week after
0/5First month
0/3More checklists
- The product launch checklistA free product launch checklist for SaaS, apps, AI tools and more. Every step says why it matters and when you can skip it.
- Website launch checklistThe things to have in place before a product website goes live, from HTTPS and share images to page speed and a real contact address.
- SaaS launch checklistSaaS launch checklist: pricing, trials, payments, failed charges and every other launch step, with why each matters and when to skip it.