The first 90 days of app growth after launch: what to do and when

Launch day gets the attention, and it decides very little. The following three months decide whether an app has a future: whether new users reach the point where it becomes useful, whether they come back, and whether the store listing gets better at finding the right people. The order of the work matters more than the amount of it.

The most common mistake is doing it backwards: buying installs in the first week, before anyone knows whether those users stay. This guide sets out a sequence for the first 90 days. The weeks are approximate, and an app with little traffic will move through the phases more slowly, but the order holds.

Contains affiliate links. As an Amazon Associate I earn from qualifying purchases.

Before launch: decide what you will count

Pick one activation event, the single action that shows a new user got what the app promises: a first logged workout, a first shared list, a first completed booking. Then agree on four numbers and write them on one page every Monday:

New installs, split by where they came from (store search, browsing, web referrals, invites).
The share of new users who reach the activation event on their first day.
Day 1, day 7 and day 30 retention for each weekly install cohort.
Crash-free users, from whichever crash reporting tool you use.

App Store Connect and Play Console both report acquisition and basic retention, and your own analytics events fill the gaps. Keep those events free of personal data; counts and step names are enough.

Days 1 to 30: activation and stability

The first month is for fixing what stops people. Crashes and broken sign-in come before any growth work, because they spoil every other number. Plan to ship small updates often in this period, and keep each one focused so you can see what it changed.

Next, find where new users stall before the activation event. Completion data per step shows the screen, and a few watched sessions show the reason; our guide to onboarding flows people actually finish covers the patterns that usually help. Put a feedback link where people can find it, answer every support message personally and read every review. In the first weeks the volume is small enough to do all three.

Reading retention cohorts

A cohort is everyone who installed in the same week. Lay the cohorts out in rows with day 1, 7 and 30 retention in the columns, and read the shape of each curve rather than any single number. No retention figure counts as good across all categories, so compare your cohorts with each other.

What the curves do	What it usually means	What to do next
Fall steeply, then flatten	A core group finds lasting value	Find out what that group did early, and steer new users there
Keep falling with no floor	Nobody has a lasting reason to return	Fix the product before spending on growth
Hold for a week or two, then drop	A trial ends, content runs out, or no habit forms	Look at what happens to users around that point
Later cohorts sit above earlier ones	Your changes are working	Keep shipping in the same direction
One cohort far below the rest	A bad release, or a burst of poorly matched installs	Check that week's release and source mix

With small cohorts, a few users either way move the percentages a lot. Look at several weeks together before concluding anything.

Days 15 to 60: iterate the store listing

Once real traffic arrives, you can see how the product page converts and which sources bring visitors. Change one element per release so you know what moved. On the App Store, keywords and screenshots normally change with a new app version, while promotional text can be edited at any time without one. Google Play lets you update the listing whenever you like, subject to review.

Start with the first screenshots and the subtitle or short description, because most visitors never look further. Our guides to the App Store keyword field and to screenshots that explain the app in five seconds cover the details. Formal store experiments usually come later for a new app, because they need more traffic than a first month brings; the reasons are in our piece on A/B testing in mobile apps.

Reviews and ratings

Ask for a rating at a moment of success, right after the activation event or a finished task, never on first launch and never in the middle of something. Use the system prompts. On iOS, StoreKit shows the request at most three times in a 365-day period to someone who hasn't rated the app on that device, and the system decides whether it appears at all. Google Play's In-App Review API has a time-bound quota that Google doesn't publish, and its guidelines say not to trigger the prompt from a button and not to ask any question, such as whether the person likes the app, before or while showing it.

Reply to reviews in both consoles, especially critical ones that describe a real bug. Google Play lets people update their review after a reply, and the rating it shows is weighted toward recent ratings, so fixes show up over time. On the App Store you can choose to reset the summary rating when a new version is released. The reset is global and can't be undone, and written reviews stay visible, so it is worth considering only when an early version had a serious problem that is now fixed.

Referrals

Referrals work when the app gets better with other people in it, or when users have a natural reason to share: a split bill, a shared shopping list, a team calendar. A reward bolted onto an app that people use alone rarely does much.

The mechanics rest on links that open the app at the right place, Universal Links on iOS and App Links on Android. If you are following an older tutorial, check what it relied on: Firebase Dynamic Links, which many apps used for invite links, shut down on August 25, 2025, and its links stopped working. Never reward ratings or reviews, since both stores prohibit it.

When to start paid campaigns

Start paid campaigns when retention has a floor and you know which users stay, not before. Paid installs poured into a curve with no floor make the same drop more expensive.

Begin small, and treat the first budget as the price of information. Apple Ads (called Apple Search Ads until April 2025) on your own app name and a few category terms, and Google's App campaigns, are the usual first channels. On iOS, App Tracking Transparency limits measurement at the level of individual users, so settle how you will judge results before spending. Then compare paid cohorts with organic ones in the same table. If paid users leave faster, fix the targeting or the creative before raising the budget.

Questions

Should we run paid campaigns from launch day?

Only a small amount, and only if you need users quickly for feedback. Scaling spend before retention has a floor buys installs that leave.

What counts as good retention?

No single figure holds across categories. A meditation app, a tax app and a game have very different natural rhythms of use. Judge your cohorts against each other: as you fix things, later weeks should do better than earlier ones.

How often should we ship updates in the first three months?

Often enough to fix what you learn, with few enough changes per release that you can tell what moved a number. A release every week or two keeps fixes flowing without turning each one into a guessing game.

Should we reset our App Store rating after a weak first version?

Only if the new version fixes the problem behind the low ratings, and you can live with showing few ratings for a while. The reset can't be reversed, and the written reviews stay on the page.