The mobile app launch checklist: from store listing to day-30 retention

Most launch plans start about sixty days too late

The pattern repeats often enough to be predictable. The build finishes, somebody submits to review, the app appears in the store, and only then does the team ask what the marketing plan is. By that point most of the useful levers have already been pulled without anyone noticing: the store listing was written by whoever had a spare afternoon, there is no audience to tell, no baseline to compare the first week against, and no instrumentation to explain why the graph looks the way it does.

The day numbers in this article describe the shape of the work rather than a guarantee. A two-person team shipping a utility and a funded company launching a marketplace will run the same sequence at very different speeds. What does not change is the order, and the order is where launches are usually lost.

There is also a hard external constraint that catches new teams. If you are publishing from a personal Google Play developer account created since late 2023, Google requires a closed test with a minimum of twelve testers opted in continuously for at least fourteen days before you can apply for production access — and any gap in enrolment resets the clock. A launch plan written after the build is finished cannot absorb that. It has to be designed in from the start.

T-60: the waitlist, the beta cohort and the store assets

Three things need to exist before you are anywhere near submission, and none of them requires a finished app.

A waitlist with a reason to join. Not a “coming soon” page — a page that states the problem precisely enough that the right people recognise themselves in it, and asks for an email address in exchange for early access. It has two jobs: it gives you a launch-day audience, and a cheap read on whether your positioning lands. If a page describing the problem cannot persuade anyone to leave an email address, the app will not persuade them to install.

A named beta cohort, recruited from where your users already are. Twenty engaged testers who genuinely have the problem beat five hundred people who signed up for a free thing. Recruit from the forums, professional groups and customer lists where the problem gets discussed, and ask each person to commit to something specific, because unpaid testers who agreed to nothing will do nothing.

The store assets, drafted early and revised late. The App Store gives you thirty characters for the app name, thirty for the subtitle, a hundred-character keyword field and a hundred and seventy of promotional text, plus up to ten screenshots and three app previews of no more than thirty seconds each. Google Play works differently and indexes your descriptions properly. Those constraints are tight enough to need several drafts, and drafting at T-60 forces a useful argument about what the product actually is. The field-by-field detail is in the ASO guide; the point here is scheduling, because screenshots need a working interface and therefore a settled design.

The two compliance jobs that block submission

Both stores now require a data declaration before you can ship, and both are slower than teams expect because they depend on facts nobody has written down.

Apple’s app privacy details require you to declare data collected by your app and by any third-party SDK you embed — analytics, advertising, crash reporting, attribution. Google Play’s Data safety form covers the same ground with its own taxonomy, including whether each data type is required or optional. Neither can be completed accurately without a definitive list of every SDK in the build and what each one sends. Produce that list at T-60, and make keeping it current someone’s named responsibility.

The second job is quieter and rejects more apps than people expect. Apple’s guidelines require that any app supporting account creation also offers account deletion from inside the app, that permission purpose strings genuinely describe why you need the data, and that apps without significant account features let people use them without signing in at all. Section 4.2 rejects apps amounting to a repackaged website — so if yours is a web view with a login screen in front of it, that is a product decision to revisit rather than a submission risk to manage.

T-30: TestFlight, Play internal testing and honest crash triage

The beta tracks on the two platforms are not equivalent, and the differences change what you can plan.

	Apple	Google Play
Fastest track	Internal testers — up to 100 App Store Connect users	Internal testing — up to 100 testers, live within minutes
Wider track	External testers — up to 10,000 people	Closed testing by email list or Google Group; open testing, either unlimited or with a minimum of 1,000
Review before testing	First build sent to a group goes to Beta App Review	Internal testing is not subject to the standard policy review
Build lifetime	Builds available for testing up to 90 days	Not time-limited in the same way
Production gate	Standard App Review	New personal accounts: 12 testers, 14 continuous days, then apply

Two practical consequences. Apple’s ninety-day build expiry means a long, slow beta quietly goes dark on your testers, so plan releases rather than letting one build rot. And because the first build sent to an external group goes to Beta App Review, your beta itself can be rejected — submit it earlier than feels necessary.

What to actually do with a beta

Most betas produce nothing because they ask for the wrong thing. “Let us know what you think” generates opinions about button colours from people who never completed the core flow.

Instrument the beta exactly as you will instrument production, then read behaviour rather than feedback: the step where people stop, the device or OS version where things break, and the gap between what testers say they did and what the events say they did. Ask each tester two questions only — what were you trying to do, and where did you give up.

Crash triage deserves a firm rule: fix crashes before features, always, and fix them in order of affected users rather than in order of how interesting they are. On Android this is not merely hygiene. Google Play publishes bad-behaviour thresholds for its core vitals — an app is flagged when at least 1.09% of daily users experience a user-perceived crash across all device models, or at least 8% on a single device model, and separately when at least 0.47% of daily active users experience a user-perceived ANR. Exceeding them makes the app less discoverable on Play, and Google steers users on affected device models away. A stability problem on Android is a distribution problem.

Launch week: what to sequence, and what to hold back

Launch week is a sequencing exercise, and the most common mistake is doing everything on one day.

Release quietly first. Ship to the store, check the listing renders correctly in every locale, install from the public store on a real device, complete a purchase if you have one, and confirm your analytics events arrive from a production build. A surprising number of launches discover on day one that events were only firing in debug.

Verify deep links before you send anyone one. On Android, App Links verification depends on an assetlinks.json file served from https://yourdomain/.well-known/assetlinks.json, with android:autoVerify="true" in the manifest. If verification fails, links open in a browser or a disambiguation dialog instead of your app, and every campaign leaks users at the door. Test a real link, from a real email, on a real device.

Then tell the waitlist properly. That email is the highest-converting message you will send all quarter: what the app does, what changed since they signed up, and one link that opens the right store for their device.

Hold something back. You do not yet know your activation rate, and paid traffic into a broken onboarding is money set on fire. The same applies to launch surfaces with one-time value: a Product Hunt post, a conference announcement or a press embargo can each be spent once, and firing them all in the same week means you learn nothing about which one worked and you spend them before the product can convert what they bring.

Days 1 to 7: the activation funnel is the whole launch

Installs are a vanity number in week one. The number that predicts everything else is the proportion of people who install and then reach the moment where the product becomes obviously useful.

Define that moment explicitly, before launch, in one sentence. It is not “opened the app” — it is the first genuinely valuable action: the first document created, the first workout logged, the first payment link sent, the first message received from another person. If you cannot name it, you cannot measure activation, and you will spend the first month arguing about which chart matters.

Then instrument the steps between install and that moment, and watch where people leave. In week one the funnel is nearly always the story:

1. Store page to install. A conversion problem, and mostly an app store optimisation problem — screenshots, first frames, rating count.
2. Install to first open. Small but real. On Android, a slow or failed first launch on mid-tier devices shows up here.
3. First open to permission prompts. Asking for push or location permission before the user understands why is the most reliable way to lose both the permission and the user.
4. Permissions to sign-up. Every required field is a reason to stop. If the app can do anything useful without an account, let it.
5. Sign-up to the activation moment. Where design work pays for itself, and where a session recording or a few analytics events beat a week of speculation.

Watch the whole funnel daily in week one, and change one thing at a time. Two simultaneous fixes and a better number tell you nothing about which one worked.

Days 8 to 30: lifecycle messaging that is not spam

By day eight the install spike has passed and the graph looks worse than it is. This is where lifecycle messaging earns its place, and where most teams do the wrong thing enthusiastically.

The useful distinction is between messages triggered by the user’s own state and messages triggered by your calendar. State-triggered messages are welcome because they are relevant: the unfinished draft, the reply someone sent, the report that is ready. Calendar-triggered messages — “we miss you”, “here’s what’s new this week” — are noise unless the product genuinely produces something new on a schedule.

A defensible starting set for most apps:

• Day 0, in-app only. Get people to the activation moment. No push, because you have not earned the permission yet.
• Ask for push permission after value, not before. Explain what you will send, in your own interface, before triggering the system prompt. On iOS, once denied you do not get to ask again.
• One re-engagement message tied to an incomplete action. Not “come back”, but “your draft is still here”.
• Genuine event notifications where the product creates them — someone replied, the price changed, the file finished.
• One recovery message at the point the cohort typically lapses, which you can only identify after watching a few cohorts.

Two rules keep this honest. Every push must deep link to the exact screen it refers to, or it is worse than nothing. And every message should be justifiable to the recipient if they asked why they got it; if the answer is “because our weekly send goes out on Tuesdays”, cut it.

Ratings and reviews: earning them rather than begging

Both stores let you request a rating from inside the app, and both constrain how. Apple allows the system prompt up to three times in a 365-day period per user, and recommends asking after the person has completed something rather than interrupting them. Google’s In-App Review API applies its own time-bound quota, requires the card to be shown unmodified, and forbids pre-prompting — you may not ask “do you like the app?” or “would you rate us five stars?” first, and you should not attach it to a button, because a user who has hit the quota will tap it and see nothing.

Those constraints are a gift, because they force the only approach that works: ask rarely, and at the moment the product has just done something good. After the third successful use, not the second launch. After the export completed, not while it is running.

The other half is answering reviews. A one-star review that gets a specific, non-defensive reply from someone who fixed the problem is often revised upwards, and everyone reading your listing sees how you behave when something goes wrong.

The dashboard: five numbers, and what each is for

Most launch dashboards fail by having thirty charts, none of which anyone can act on. Five numbers, reviewed on a fixed cadence, beat a wall of graphs.

Number	Definition to agree in advance	What it tells you	What it does not tell you
Installs by source	New installs, split by acquisition channel	Whether distribution is working	Anything about product quality
Activation rate	Share of new installs reaching the named activation moment, within a fixed window	Whether onboarding works	Whether the value lasts
Day-7 retention, by cohort	Share of a given day’s installs opening again on day 7	Early signal on habit formation	Whether they will pay
Day-30 retention, by cohort	Same, at day 30	Whether the product has a place in someone’s life	Why they stayed
Crash-free users and ANR rate	Platform-defined, from Play Console and your crash reporter	Whether stability is suppressing everything else	Which crash matters most commercially

Two disciplines make this dashboard useful. Measure retention by cohort, never in aggregate — an aggregate retention line rises when installs fall, which has misled a great many teams into celebrating a bad week. And write each definition down before launch, because the fastest way to lose an argument in month three is discovering that two people have been counting activation differently since day one.

Days 60 to 90: the first honest read

Around day sixty you get the first data not distorted by launch enthusiasm. The people who installed because a friend mentioned it have either stayed or gone, and what is left is closer to the truth.

The question is not “are the numbers good” but “which curve is this”. Retention curves for successful products flatten: they fall steeply, then settle at a plateau representing the people for whom the product has become part of how they do something. Curves for unsuccessful products keep falling towards zero. The plateau’s height matters commercially; its existence matters more, because a flattening curve means there is a real audience to expand and a falling one means there is not yet a product to market.

By day ninety you should be able to answer three questions with evidence: which segment retains best, what those people did differently in their first session, and what it costs to acquire another one of them. Until you can, spending heavily on acquisition buys the same uncertainty in larger quantities.

When the launch goes badly

It frequently does, and the useful response depends entirely on which of three things went wrong.

Low installs, healthy retention. The product is fine and nobody knows about it — the best of the bad outcomes. The work is distribution: listing conversion, channels, positioning, and eventually paid acquisition, now that you know the funnel holds water.

Healthy installs, low activation. People arrive and never reach the value. Almost always a design problem, and the cheapest of the three to fix. Watch ten first sessions end to end and it is usually embarrassingly obvious by the third.

Good activation, falling retention. People understand the product and choose not to keep it. The expensive one, because no messaging campaign fixes it: either the problem is not frequent enough to sustain an app, or your solution is not better than what people did before.

The instinct in all three cases is to add features, and it is almost never right in the first ninety days. A launch is a measurement exercise; finish it knowing something you did not know before.

The checklist, in one place

Before submission

1. Activation moment defined in one sentence, and instrumented.
2. Analytics events verified firing from a production build, not just debug.
3. Complete SDK inventory, with what each one collects.
4. App privacy details and Data safety form completed accurately.
5. Account deletion available in-app if you support account creation.
6. Permission purpose strings that state the real reason.
7. Store listing drafted, screenshots from a working build, first frames arguing the case.
8. Deep links configured and assetlinks.json served correctly.
9. A support route a real person monitors.
10. Beta run on instrumented behaviour; crash backlog cleared by affected-user count.

Launch week

11. Ship quietly, install from the public store, complete a full first run on a real device.
12. Verify one deep link end to end, from an email, on a phone.
13. Tell the waitlist, then the communities the beta came from.
14. Hold back most of the paid budget and at least one one-time launch surface.
15. Watch the funnel daily; change one thing at a time.

Days 8 to 90

16. Push permission requested after value, with an in-app explanation first.
17. Lifecycle messages triggered by user state, each deep linking to the right screen.
18. Rating prompts after a completed action, within platform quotas.
19. Reviews answered, particularly the angry ones.
20. Cohort retention reviewed weekly against your own earlier cohorts, on a definition written down before launch.

If you are deciding whether to run this yourself, the honest answer is that most of the list is a discipline problem rather than a specialist one, and a competent product team can do all of it. The parts that reliably benefit from outside hands are the store listing craft, the analytics implementation, and the platform-specific stability work on Android and iOS, where the failure modes are unfamiliar. If the app itself does not exist yet, that is a different conversation about building it — and the framework decision is worth making deliberately, because it determines how much of the above you end up doing twice.