What is a good retention rate for a mobile app?

There is no single figure. Published benchmarks differ by category, platform, data source and retention definition, so use them only as a rough guide. A better target is steady improvement in your own weekly cohorts, especially day-1 and day-7 retention.

When should an app ask for notification permission?

After the user has seen some value and ideally from an action that relates to notifications, with a short explanation first. Android advises against asking at launch, and Apple advises asking at a sensible moment with context. On Android, a denial cannot be undone by the app.

Does app stability affect retention and discovery?

Yes. Crashes and freezes drive users away, and on Google Play, exceeding the Android vitals bad behavior thresholds can reduce visibility and show a warning on the store listing.

What is the difference between classic and rolling retention?

Classic retention counts users who return on exactly day N. Rolling retention counts users who return on day N or any later day, so it is always equal or higher. Check which one your analytics tool reports before comparing numbers.

Mobile App Retention: How to Keep Users After Install

What retention actually measures

Retention is the percentage of a group of new users who return on a later day. If 1,000 people install the app on Monday and 250 open it on Tuesday, day-1 retention for that cohort is 25 percent. The same logic gives day-7 and day-30 retention.

Two details matter before you compare any numbers. First, definitions differ: classic retention counts users who return on exactly that day, while rolling retention counts anyone who returned on that day or later. The two can differ by a lot, so always check which one a tool or report uses. Second, published benchmarks vary widely by category, platform and data source, so a single industry average is a weak target. Your own cohorts, compared week over week, tell you far more.

Measure by cohort, not by total users

Total active users hide problems. If installs double because of a campaign, your active user count rises even when retention falls. Group users by install week and watch each cohort over time instead.

Look at where each cohort drops off. A steep fall between install and day 1 usually points to onboarding or a mismatch between the store listing and the product. A steady decline between day 7 and day 30 points to weak habit formation: the app is useful once but has no reason to be reopened.

Day-1 retention: did onboarding deliver a first useful moment?
Day-7 retention: did the user find a reason to come back?
Day-30 retention: has the app become part of a routine or need?
Segment by acquisition source, country and platform, because an average across them hides which channel brings users who stay.

Fix onboarding first

Apple’s Human Interface Guidelines advise keeping onboarding brief, letting people start quickly and teaching features in context instead of through a long upfront tour. The same guidance suggests deferring sign-in until a feature actually needs an account.

In practice, the aim is to shorten the time to the first valuable action. Write down what that action is for your app, such as scanning a document, saving a place or completing a first workout, and count the taps and screens between launch and that moment. Every screen that does not help the user reach it is a candidate for removal or postponement.

Show the core experience first and ask for an account only when it is needed to save or sync something.
Replace feature tours with short hints shown the first time a feature is used.
Let people skip anything that is not essential.
Ask for each permission at the moment the related feature is used, with a sentence explaining the benefit.
Make sure the first screen matches the promise made in the screenshots and description, so users do not feel misled.

Ask for notification permission at the right moment

Notifications can bring users back, but only if they are allowed, and the way you ask matters. On Android 13 and higher, notifications are off by default for new installs and require the POST_NOTIFICATIONS runtime permission. Android’s documentation says that if the user chooses not to allow, the app cannot send notifications unless it qualifies for an exemption.

Because a refusal is hard to reverse, Android’s guidance is to let users become familiar with the app before asking, and to trigger the request from a user action, such as tapping an alert bell, following an account or placing an order. It also suggests waiting until the third or fourth launch, and showing a short explanation of the value before the system dialog. Apple’s guidelines point the same way: ask when it makes sense, explain why, do not request at launch without context, and do not nag after a denial.

Apple also describes interruption levels, from passive to time-sensitive and critical. Keep the higher levels for things people genuinely need to see now. A delivery arriving today fits; a discount does not.

Use a soft pre-prompt screen that explains the benefit; only show the system dialog after the user agrees.
Tie each notification to something the user chose, such as a reminder they set or an order they placed.
Cap frequency, and use passive delivery for low-priority updates like a weekly summary.
Offer notification settings inside the app so people can reduce volume instead of disabling everything.

Stability is a retention feature

Crashes and freezes are one of the fastest ways to lose a new user, and on Google Play they also affect visibility. Android vitals tracks user-perceived crash rate and user-perceived ANR (application not responding) rate. Google lists bad behavior thresholds of 1.09 percent for crashes and 0.47 percent for ANRs, averaged across devices, with a per-phone-model threshold of 8 percent for each. Its documentation says that exceeding them can reduce your title’s visibility and may show a warning on your store listing, and that the data is based on the last 28 days.

The practical lesson applies to both platforms: treat crash-free sessions as a product metric. Release in stages, watch crash and ANR data after each version, and fix the issues that affect the most users first. A feature that ships with a startup crash on a popular device costs more retention than a month of onboarding polish can recover.

Build a reason to return

Retention beyond the first week depends on the product, not on messages. Ask what job brings someone back. A fitness app has the next workout, a utility app has the next time the problem occurs, and a content app has new material. If the honest answer is nothing, no notification strategy will fix it.

Once a genuine reason exists, you can support it with light touches: a streak or progress view that shows value built up over time, saved data that makes the app more useful with every use, widgets or shortcuts that put the app in reach, and lifecycle messages timed to what the user did or did not do. Each should be tested on a cohort, not rolled out to everyone at once.

A simple four-week plan

You do not need a large programme to start. A small, measured cycle usually shows where the leak is.

Week 1: set up analytics events for first launch, the first valuable action and each permission prompt, and chart retention by weekly cohort.
Week 2: cut the path to the first valuable action and move sign-in and permission requests to the moment of need.
Week 3: review crash and ANR data, and fix the top issues affecting the most users.
Week 4: add one lifecycle message tied to a user action, test it on a share of the cohort, and compare retention against the rest.

Where a team can help

Retention work sits between product, design and engineering, which is why it often stalls. If you want an outside team to set up the measurement and run the first experiments, dagtech works on app growth and retention from Istanbul, alongside development, so fixes in onboarding or stability can ship in the same cycle.

Mobile App Retention: How to Keep Users After Install (Onboarding, Notifications and Stability)