The app launch checklist for iOS and Android

A mobile launch has a constraint a web launch does not: two companies get to say no, on their own timetable, after you have already scheduled everything else around the date. Every other item on this list exists to stop that from being a surprise.

This checklist assumes you are shipping to both stores. If you are shipping to one, skip the other column and keep the sequence.

Eight weeks out: accounts and the things with lead times

Developer accounts, enrolled and paid. Apple’s Developer Program and a Google Play developer account both take time to approve, and Google requires identity verification that can add days. An individual account on Play has requirements that a new personal account will not satisfy instantly. Do this first, because nothing else can start until it is done.

Bundle identifier and package name. Permanent. You cannot change either after the first submission without shipping a new app and losing everything attached to the old one. Pick something you can live with.

App name availability. Check both stores and check the trademark, in that order.

Signing. Apple certificates and provisioning profiles, and a Play app signing key you have actually backed up somewhere that is not the laptop you are typing on.

Privacy declarations. Apple’s privacy nutrition labels and Google’s Data Safety form both ask exactly what you collect, why, and who you share it with. If you use any third-party SDK for analytics, crash reporting or ads, you are answering for its collection too. Apple also requires privacy manifests from SDKs in a defined list. Get this right the first time, because a wrong answer here is a rejection and, later, a policy problem.

Age rating questionnaires. Both stores. Answer honestly, including about user-generated content, which is the single most common source of a rating dispute.

Six weeks out: the store listing itself

The store listing is the highest-leverage asset in a mobile launch and the one most often written in an hour on a Thursday.

Title and subtitle. Apple gives you a 30-character name and a 30-character subtitle. Google gives you a 30-character title and an 80-character short description. These are indexed, so they carry your primary term, but keyword stuffing reads badly to a human scanning a search result and human scanning is what converts.

The first three lines of the description. On both stores, everything after roughly the first three lines is behind a “more” tap that most people never take. Treat those lines as the whole description. Everything below is for the person already sold.

Keywords field. Apple only, 100 characters, comma separated, no spaces after commas, no repeats of words already in your title or subtitle. Google has no keywords field and indexes your description instead.

Screenshots. This is where launches are won and lost. Both stores show the first two or three in search results, which means those two decide your conversion rate before anyone opens your page. Use captions. Show the product, not a person holding a phone. Provide the required sizes for the current reference devices on Apple, and phone plus tablet sets on Google if you support tablets.

App preview video. Optional and worth it. Fifteen to thirty seconds, autoplaying muted, so it must be legible with no sound.

Icon. Test it at the size it will actually be rendered, which is small. Then test it on a dark home screen and a light one.

Localization. Even translating only the title, subtitle and first three description lines into your top two or three secondary markets moves numbers. Full description translation is a later optimization.

Run whatever you have through the App Store Listing Checker before you submit. It scores title and subtitle length, screenshot count and aspect ratios, the first three description lines, rating count, update recency and localization coverage against category norms, and hands back a ranked fix list.

Four weeks out: builds, testing and the review gate

Internal testing. TestFlight on iOS, internal testing track on Google Play. Get the actual signed release build onto real devices, not the simulator.

External beta. TestFlight external testing requires a Beta App Review, which is faster than a full review but is still a review and still a queue. Google’s closed testing track requires a sustained tester count before you can promote a new personal developer account to production, which is a genuine multi-week gate that catches people out.

Crash-free rate. Instrument it, then hold the release until it is boringly high. A launch-week crash spike lands directly in your reviews and reviews do not decay.

Deep links. Universal Links on iOS, App Links on Android, both verified with the association file served from your domain over HTTPS. Every launch post, directory listing and email you send during launch week should open the app for someone who already has it. Test the cold-start path, where the app is not running and must route to the right screen after launch.

Accessibility pass. Dynamic Type or font scaling, VoiceOver and TalkBack labels on every interactive element, contrast, and tap targets. Apple’s editorial teams weight this, and the App Store’s own award citations regularly name accessibility work. Tiimo, a visual daily planner built around ADHD and autistic executive-function needs, was named Apple’s 2025 iPhone App of the Year. Accessibility is not a compliance chore.

Submit for review early. Apple’s review is usually fast now but the distribution has a long tail, and holidays lengthen it. Submit with a release date set in the future, so an approval simply waits rather than shipping early. On Google, use a managed publishing setting so an approved build does not go live the moment it clears.

Write the review notes. A demo account with credentials, anything behind a paywall, and a plain explanation of any permission that is not self-explanatory. Most rejections we see described are information problems, not product problems.

Two weeks out: everything outside the stores

Stores are distribution, not discovery. The work that compounds happens on the open web.

A real landing page on your own domain. Not a store link. A page with the value proposition, screenshots, a link to each store and your privacy policy. Serious directories reject app-store-only submissions, BetaList’s own FAQ says so explicitly, and this one rejects them too.

Structured content written once, used everywhere. Three to eight features, two to seven use cases as persona plus scenario, differentiators, and an FAQ. Write it for your landing page and it fills every directory form you touch afterwards.

Directory submissions, respecting their queues. Mobile apps are welcome on nearly every launch directory, but the queues differ and the free lines are long. Our where else to launch page has cadence, free tier, entry price and link policy for ten of them in one table.

Press and newsletters, if you have a genuine angle. An award, a number, an unusual maker story. Without one of those, a cold pitch to a tech publication is not a plan.

Your own list. If you ran a beta, those testers are the best launch-day audience you will ever have, and they have already installed the app.

Launch week

Phased rollout, not all at once. Apple’s phased release rolls a new version over seven days and can be paused. Google’s staged rollout lets you start at a small percentage and halt it. Both give you the chance to catch a bad build before it reaches everyone. Use them on updates even more religiously than on the first release.

Watch the right dashboards. Crash-free rate, install-to-open ratio, and reviews. Not the ranking.

Reply to reviews. Both stores allow it and both surface the reply publicly. A fast, specific reply to a one-star review is visible to every future reader of that review, which makes it one of the highest-return twenty minutes in the launch.

Ask for ratings inside the app, at the right moment. Use the native prompt on each platform, trigger it after a success moment rather than on launch, and respect the system limits. Rating count is one of the strongest conversion factors on both stores.

The thirty days after

Ship an update in the first month. Both stores treat update recency as a freshness signal and both surface a last-updated date to users. It is also the cheapest possible demonstration that the app is maintained.

Turn launch-week feedback into the roadmap in public. A changelog on your own domain, linked from the store listing and your directory listings.

Run the listing checker again. Now that you have rating counts and real search data, the fixes are different from the ones you made pre-launch.

Keep the directory listings alive. Update version numbers, refresh screenshots when the UI changes, and use a relaunch when a version genuinely warrants one. A permanent listing that reflects the current product keeps sending traffic long after launch week is over.

When the app is live on at least one store and you have a landing page on your own domain, submit it here. Both stores get recorded as separate distribution entries on the listing, with their own store URLs, versions and minimum OS versions.