Your First App Launch: A Checklist for Testing, Store Submission and Release

Seven things, in this order: developer accounts and agreements, store listing assets, privacy declarations, testing tracks, store review, your release choice, and monitoring in the first days. The one that most often moves a launch date is Google Play's closed test: a new personal Play account must run at least 12 opted-in testers for 14 consecutive days before it can even apply for production. Work backwards from your launch date with that in mind, and remember that the gradual rollout tools both stores offer are for updates, not for a first release.

This is a sequencing guide for a first release. It does not repeat QA practice, which is covered in mobile app testing, or the mechanics of shipping updates safely, covered in release management for live apps.

Each item has a suggested owner and a lead time counted back from the day you want to be live. The lead times are planning assumptions for a small team, not store guarantees, except where a store states a figure. Roles can be the same person; the point is that every item has a name next to it.

The fixed waits are what make a launch slip, so put them on a calendar first. On Android, for a new personal account, the closed test runs for at least 14 consecutive days, and only then can you apply for production access; Google says that application review usually takes seven days or less, but can occasionally take longer. Production review comes on top, and Google notes that for some accounts it can take up to seven days or longer in exceptional cases.

On iOS, Apple says it typically reviews at least 50% of submissions in under 24 hours and 90% in under 48 hours. That is quick, but a rejection means fixing, resubmitting and waiting again, and the first external TestFlight build also goes through review.

Hypothetical example: planning a launch for a two-person team. A founder and one developer want a consumer app live on both stores. They have a stable build five weeks before the target date and a new personal Play account. Week 1: listing copy, privacy declarations and internal testing on both platforms. End of week 1: the Play closed test starts with 15 recruited testers, a few more than the minimum in case some drop out, and the first external TestFlight build goes to review. Weeks 2 and 3: testers report bugs and the developer ships fixes to both tracks. Day 15 of the test: they apply for Play production access. Week 4: they submit to App Review with manual release set. Week 5: with both approvals in hand, they publish on the same morning. If any step had slipped, the plan was to launch on iOS first rather than move the date.

These are the requirements as published when checked on 14 October 2026. Apple in particular has changed which screenshot size is mandatory over time, so open the linked pages before the designer starts.

Both stores ask you to declare what data the app and its SDKs collect. Apple's App Privacy details are required for new apps and include data collected by third-party partners. Google requires the Data safety form for every app published on closed, open or production tracks, even apps that collect nothing, which is why it sits before testing in the checklist. If users can create an account, both stores require a way to delete it: Apple's guideline 5.1.1(v) asks for deletion inside the app, and Google requires an in-app path and a web link where deletion can be requested.

Get an inventory of every SDK before filling in either form. The detail, including privacy manifests and regional law, is in privacy and security before launch.

TestFlight supports up to 100 internal testers from your team and up to 10,000 external testers through email invitations or public links. Internal testers must hold a role on your developer team. Before you can invite external testers, your first build must be approved by App Review for TestFlight.

On Google Play, internal testing is the quick loop for your team. Closed testing is the track that matters for launch on a new personal account: at least 12 testers opted in continuously for at least 14 days, then a production access application where you answer questions about the test and your readiness. If Google judges the testing insufficient, for example because fewer than 12 testers stayed opted in, the closed test may need to continue. When you upload a build, Play's pre-launch report also runs automated checks on real devices for stability, compatibility, performance and accessibility, which is a free second opinion worth reading.

Apple's guideline 2.1 asks that submissions be final, with no placeholder content, tested on-device, and with demo account details included and the back-end service switched on. Apps that crash are rejected. In practice that means four things: a reviewer login that will still work days later, review notes that explain any feature that needs hardware, a location or a paid plan to see, servers that stay up and unchanged while the review is pending, and no "coming soon" screens. If your app needs a custom backend, the mobile backend guide explains what has to be running for reviewers to get past sign-in.

If Apple rejects the build, read the cited guideline, fix that issue and resubmit, and use the review notes to explain anything the reviewer may have missed. Apple also offers an expedited review for critical bug fixes or an event you are directly associated with, which is worth knowing about for a launch tied to a date.

The gradual rollout tools you may have read about are update tools. Google states that staged rollouts can only be used for app updates, not when publishing an app for the first time. Apple's phased release is documented for version updates, rolling out over seven days to users with automatic updates on. So v1 reaches everyone in your chosen countries at once.

Launch day is when real devices, networks and user behaviour meet your app for the first time. Have these in place before you release.

It covers a typical consumer or business app on the public stores. Apps in regulated categories such as health, finance or children's apps face extra review rules and documentation. Apps distributed privately to employees use different programmes. Games, apps with in-app purchases or subscriptions, and apps that rely on location, health data or background activity need extra review preparation that this guide does not cover.

Store rules also move. Build requirements change each year, screenshot requirements change with new devices, and Google's testing requirements for new accounts may change. Check every linked source in the week you submit, and if you are a founder whose developer has left before submission, start with item 1: make sure the accounts are yours.

Apple: Apple Developer Program; Screenshot specifications; Platform version information; App Review Guidelines; App Review; TestFlight; App Privacy details; Release a version update in phases; Upcoming requirements.

Google: Testing requirements for new personal developer accounts; Review times and managed publishing; Preview assets; Pre-launch reports; Staged rollouts; Data safety section; Account deletion requirements; Target API level requirements.

Accessed 14 October 2026. Store fees, asset specifications, review times and policy deadlines change; check the current pages before you submit.

A first launch is mostly a sequencing problem. Secure the accounts in the business's name, start the Play closed test as soon as a stable build exists, prepare assets and privacy declarations from the stores' current pages, give reviewers everything they need, and hold approved builds for a release you control. Then watch the first fortnight closely, because v1 goes to everyone at once.

If the build itself is still in progress, the launch steps above belong in the plan from the start of mobile app development, not in the final week.