Mobile App Retention Rate Statistics 2026: Benchmarks, Churn and Uninstalls

- Table of contents
- Key app retention rate statistics for 2026
- What is app retention rate, and how is it calculated?
- Average app retention rate benchmarks for Day 1 and Day 30
- App retention benchmarks by category
- Why app retention benchmarks can differ by 8×
- App churn rate and app uninstall rate
- Why people uninstall mobile apps
- What one crash costs your app
- Google Play’s published quality thresholds
- What crash-free rates look like in practice
- Retention, quality and revenue
- What re-engagement data can and cannot tell you
- How to benchmark your mobile app retention rate
- Methodology and limitations
- Conclusion
You open your analytics dashboard and see 18% Day 1 retention and 4.5% Day 30 retention. Both numbers look low, but without a comparable cohort, category and measurement period, you cannot tell whether your app has a retention problem or you have chosen the wrong benchmark.
The most defensible baseline is that roughly 25% of installs were retained on Day 1 and 5–6% on Day 30 in the cross-category studies most often cited today. Those figures come from 2020 and 2021, not 2026. Current evidence is stronger for category-level engagement, app churn, uninstall behaviour and crash tolerance than for one universal 2026 average app retention rate. Your benchmark only becomes useful when you know its year, denominator and cohort definition.
Table of contents
Key app retention rate statistics for 2026
What is app retention rate, and how is it calculated?
Average app retention rate benchmarks for Day 1 and Day 30
App retention benchmarks by category
Why app retention benchmarks can differ by 8×
App churn rate and app uninstall rate
Why people uninstall mobile apps
What one crash costs your app
Google Play’s published quality thresholds
What crash-free rates look like in practice
Retention, quality and revenue
What re-engagement data can and cannot tell you
How to benchmark your mobile app retention rate
Methodology and limitations
Conclusion

Get the Mobile Testing Playbook Used by 800+ QA Teams
Discover 50+ battle-tested strategies to catch critical bugs before production and ship 5-star apps faster.
Key app retention rate statistics for 2026
The most widely cited cross-category benchmark is approximately 25% Day 1 retention and 6% Day 30 retention, but the figure links back to AppsFlyer’s 2021 retention research, not a 2026 study.
The frequently quoted 25.3% Day 1 and 5.7% Day 30 figures appear beneath a Statista chart dated August 2020 on Business of Apps’ retention guide.
UXCam’s stated 2026 industry medians range from 12% Day 30 retention for social apps to 2% for ecommerce apps (UXCam).
Mixpanel reports 37% DAU/MAU stickiness for AI apps in APAC, compared with 21% in North America, from a 2026 dataset covering more than 12,000 companies and 3.7 trillion events (Mixpanel).
Android apps recorded a 46.1% 30-day uninstall rate in 2024, based on 1.3 billion installs and 402 million uninstalls measured from January 2023 through November 2024 (AppsFlyer).
15.4% of surveyed U.S. mobile app users said they uninstall after one crash, according to Luciq’s 2026 survey of more than 1,000 respondents (Luciq).
A further 50.4% said they leave after two or three crashes in the same research (Luciq).
Google Play’s bad-behaviour thresholds are 1.09% user-perceived crash rate and 0.47% user-perceived ANR rate across device models, with an 8% threshold for either metric on an individual device model (Google Play Console Help).
What is app retention rate, and how is it calculated?
App retention rate is the percentage of people from an original user or install cohort who return to your app after a defined period. Day 1 retention measures the share that returns one day after the initial event, while Day 7 and Day 30 measure returns after seven and 30 days.
A basic install-cohort formula is:
App retention rate =Users from the original cohort active on Day N÷Total users in the original cohort× 100
AppsFlyer defines retention around people who continue engaging with your app after installation, but the exact implementation depends on the cohort and return events in your analytics system (AppsFlyer).
An install-based cohort asks how many people return after installing. An active-user cohort may measure how many existing users remain active between two periods. Both can be labelled retention while producing different percentages.
AppsFlyer applies a two-month cohort to post-install benchmarks so that a full 30-day period can be observed, and refreshes its data quarterly (AppsFlyer benchmarks methodology).
Before you compare your number with an external benchmark, record four details:
Starting event: installation, registration, purchase or another action.
Return event: opening the app, completing a session or performing a core action.
Time window: Day 1, Day 7, Day 30 or rolling-period retention.
Denominator: original installs, registered users or active users.
Without those details, two percentages carrying the same label may not measure the same behaviour.
Average app retention rate benchmarks for Day 1 and Day 30
The two widely cited cross-category sources reviewed here show the same steep curve: about one-quarter of installs remain on Day 1, falling to roughly 5–6% by Day 30 (AppsFlyer; Business of Apps).
The problem is their age.
Reported source | Measurement vintage | Day 1 | Day 30 | What you should know |
Links to a 2021 AppsFlyer report | About 25% | About 6% | First-party measurement, but not a 2026 benchmark | |
Statista chart dated August 2020 | 25.3% | 5.7% | Exact decimals are often repeated without the chart date |

You can use these figures as historical orientation. You should not label them “2026 average app retention rate” data.
No current cross-category Day 7 figure with a readable primary source and stated methodology was found for this report.
Business of Apps also lists iOS retention falling from 25.65% on Day 1 to 4.13% on Day 30, and Android falling from 23.01% to 2.59%. The page does not identify a study for those platform splits, so you should treat them as figures reported by the page rather than current platform benchmarks (Business of Apps).
If you compare platform cohorts, first separate retention from the underlying iOS and Android market mix. Platform share and cohort survival answer different questions.
App retention benchmarks by category
A single average hides large differences between app categories. Your expected return pattern depends on how often your product naturally needs to be used.
UXCam’s stated 2026 Day 30 medians are:
Social: 12%.
Productivity: 8%.
Fintech: 7%.
Streaming and media: 7%.
Health and fitness: 5%.
Gaming: 3%.
Ecommerce: 2%.
Source: UXCam, Mobile App Retention Benchmarks by Industry. These are UXCam’s reported figures rather than a new measurement conducted for this report.

Mixpanel’s 2026 data gives you a more current but methodologically different view. It reports stickiness, measured as daily active users divided by monthly active users, rather than Day 30 install retention.
Across more than 12,000 companies, 3.7 trillion events and 22 billion devices, Mixpanel reports 37% stickiness for AI apps in APAC versus 21% in North America, 31% for B2B products in North America, 31–32% for mobile gaming in North America and EMEA, and 35% for iGaming in EMEA (Mixpanel).
Its gaming analysis, based on 517.6 billion events across 808.2 million devices, reports 32% DAU/MAU stickiness in APAC and North America. One-week retention rose 86% year over year in APAC and fell 53% in Latin America (Mixpanel).
Do not compare a 32% DAU/MAU ratio directly with a 3% Day 30 install-retention figure. One measures how frequently your active monthly audience returns; the other measures how much of an original install cohort remains after 30 days.
Why app retention benchmarks can differ by 8×
Geckoboard reports 42% retention after 30 days and 25% after 90 days, based on Localytics data (Geckoboard). Its Day 30 result is roughly seven to eight times the 5–6% cross-category install-retention figure cited elsewhere.
That gap means “retention” has been applied to different datasets, definitions and periods.
Check the vintage first. Business of Apps presents 25.3% Day 1 and 5.7% Day 30 beneath an August 2020 Statista chart, while AppsFlyer’s glossary routes its approximate 25% and 6% figures to a 2021 report (Business of Apps; AppsFlyer).
Check the cohort definition next. You need to know whether the starting population consists of installs, registered accounts, purchasers or previously active users.
Then check the cohort window. AppsFlyer delays post-install benchmark reporting so that a full 30-day observation window is available, and it suppresses category or country results unless minimum app, company and install thresholds are met over consecutive quarters (AppsFlyer).
Before you use a benchmark in a report or board slide, ask:
When was the behaviour measured?
What event placed someone in the cohort?
What return event counted as retained?
Was the cohort organic, paid or blended?
Which platforms, categories and regions were included?
A benchmark without those answers is context, not a target.
App churn rate and app uninstall rate
App retention rate measures who comes back. App churn measures who stops returning, while uninstall data captures the more definitive act of removing your app.
AppsFlyer’s 2025 uninstall report analysed 2,200 Android apps, 1.3 billion installs and 402 million uninstalls collected from January 2023 through November 2024. It recorded a 46.1% 30-day app uninstall rate in 2024, down from 46.9% in 2023 (AppsFlyer).
The category spread was substantial: dating reached approximately 57.8% for organic installs and 62.4% for non-organic installs, gaming exceeded 50%, news and magazines recorded 27.3%, and travel recorded 29.2% (AppsFlyer).

These figures are Android-only because AppsFlyer says iOS 15 and App Tracking Transparency disrupted comparable iOS uninstall measurement (AppsFlyer). The 2025 edition’s data ends in November 2024.
Why people uninstall mobile apps
Many retention articles repeat a claim that 53% of people uninstall an app after severe problems such as crashes, freezes or errors. The number is real, but its provenance is less clean than the usual citation suggests.
The original research was conducted by Dimensional Research, sponsored by Hewlett-Packard, with 3,011 respondents across seven countries in early 2015. CIO’s contemporaneous coverage identifies the conductor, sponsor, sample and countries, and reports that the findings were released on March 30, 2015 (CIO).
The underlying material contains two different 53% findings: 53% had experienced a crash, freeze or error, while 53% of those encountering severe issues removed the app. A summary slide compressed the second result into the familiar uninstall claim.
An archived whitepaper listing carries the uninstall wording (iTnews). CIO used the incidence interpretation and separately reported that 48% removed an app that regularly ran slowly (CIO). Raygun repeated the uninstall interpretation in 2016, helping it spread into later content (Raygun).
The finding was not invented. The industry still circulates an 11-year-old survey with two interpretations that share the same percentage. Use it as historical evidence, not as a current app churn benchmark.
What one crash costs your app
Luciq’s 2026 research provides a current replacement for the 2015 crash statistic. The survey covered more than 1,000 U.S. mobile app users across different demographics and usage levels (Luciq).
The results describe a tolerance curve:
15.4% said they uninstall after one crash.
50.4% said they leave after two or three crashes.
53.2% said crashes or slowdowns caused them to abandon a purchase during a major sale.
77.5% said repeated poor performance damages brand perception.
83.4% rated stability as extremely or very important.
63.9% admitted to cursing or yelling at an app after a performance failure.
29.1% had selected a paid tier for better performance.
Sources: Luciq’s 2026 user-expectations report and Luciq’s mobile app churn analysis, which provides the exact 50.4% figure.

The curve is the useful finding: one crash costs a measurable share of affected users, while repetition pushes half toward leaving (Luciq; Luciq).
The damage can appear before churn reaches your dashboard. In the same survey, 53.2% reported abandoning purchases during major sales because of crashes or slowdowns, while 77.5% said repeated poor performance harms their view of the brand (Luciq). That pattern belongs beside broader mobile ecommerce conversion and checkout data.
Google Play’s published quality thresholds
Google Play publishes exact crash and application-not-responding thresholds that can affect your app’s visibility.
Core vital | Overall bad-behaviour threshold | Per-device threshold |
User-perceived crash rate | 1.09% of daily users | 8% of daily users on one device model |
User-perceived ANR rate | 0.47% of daily active users | 8% of daily active users on one device model |
Source: Google Play Console Help.

Google defines user-perceived crash rate as the percentage of daily active users who experience at least one crash while actively using your app (Android Developers).
User-perceived ANR rate measures daily active users who experience at least one qualifying ANR. Google currently treats Input dispatching timed out events as user-perceived ANRs (Android Developers).
Google states that an app exceeding a bad-behaviour threshold is likely to become less discoverable, may be steered away from people using affected device models, and can receive a warning on its store listing (Google Play Console Help).
Google explained in 2022 that it adopted user-perceived metrics because they showed a stronger correlation with uninstalls (Android Developers Blog).
The thresholds affect both retention and acquisition: crashes and ANRs can increase app churn, while threshold breaches can reduce discovery (Google Play Console Help). A device-specific failure can become a store-level problem even when your overall average looks acceptable, so pair the data with Android debugging workflows using Logcat and ADB.
What crash-free rates look like in practice
Firebase Crashlytics defines two related measures:
Crash-free users =1 - (crashed users ÷ all users)Crash-free sessions =1 - (crashed sessions ÷ all sessions)
Both metrics are aggregated over time rather than calculated as averages of daily percentages (Firebase Crashlytics).
Firebase recommends crash-free users for apps with long sessions, such as streaming or social products, and crash-free sessions for apps with many short sessions, such as games or finance products (Firebase Crashlytics).
Firebase does not publish an official target. Luciq reports 99.77% at P25, 99.95% at the median and 99.99% at P75, but does not disclose its sample size, measurement period or methodology (Luciq).
Luciq also states that apps above 4.5 stars cluster around 99.95% crash-free, while apps below three stars cluster around 99.82%. It gives approximately 99.7% as a threshold to reach three stars and 99.85% to exceed 4.5 stars, subject to the same limitation (Luciq).
Treat these as Luciq’s published benchmarks, not an independent standard. Compare them with client-side performance testing signals such as responsiveness and load behaviour.
Retention, quality and revenue
Sensor Tower recorded approximately 150 billion downloads in 2025, up 0.8% year over year. During the same period, in-app purchase revenue reached $167 billion, up 10.6%, while time spent reached 5.3 trillion hours, up 3.8% (Sensor Tower).

Revenue and usage grew faster than downloads, increasing the value of keeping an acquired user active.
The timing differs by monetisation model. AppsFlyer’s 2026 monetisation report covers January 2025 through March 2026 and analyses $900 million in in-app purchase revenue, $800 million in in-app subscription revenue and $7.2 billion in in-app advertising revenue (AppsFlyer).
Apps using in-app advertising recover approximately 89% of Day 60 revenue by Day 7, while in-app subscription apps reach only 52% by Day 7 (AppsFlyer).
More subscription revenue therefore sits behind the retention wall. Someone who leaves in the second or third week can remove revenue that an advertising-led app may already have captured.
Retention analytics shows when people stop returning. Crash monitoring can expose instability, while pre-release QA sits earlier in the chain.
For product like Quash, BrowserStack, Sauce Labs and Firebase Test Lab, that is the relevant place in the retention conversation: upstream of the retention dashboard, alongside the broader device-testing ecosystem, rather than positioned as a replacement for analytics or crash reporting.
What re-engagement data can and cannot tell you
Airship’s 2026 push-notification benchmark covers 681 billion notifications sent to 3 billion users across 15 industries. It reports results at the 90th, 50th and 10th percentiles instead of reducing every sender to one average (Airship).
Airship reports that Android and iOS opt-in rates moved closer to parity after Android 13’s runtime notification permission. Median and lower-tier Android senders cut volume 15% year over year, while top-tier senders increased it (Airship).
Food and drink apps show a 57.32 percentage-point spread on Android and 49.63 points on iOS between top and bottom performers (Airship).
These figures measure push performance, not lapsed-user recovery. No public dataset reviewed here combined a named conductor, stated sample and disclosed methodology with a mobile-app win-back conversion rate.
How to benchmark your mobile app retention rate
1. Define the cohort before reading the percentage
Record the event that starts your cohort and the event that counts as a return. An install-based Day 30 cohort cannot be compared cleanly with a monthly active-user calculation.
2. Put the benchmark year beside the number
Do not write “average Day 30 retention is 6%” without a date. Write that AppsFlyer’s 2021 cross-category measurement reported approximately 6%, or that the August 2020 Statista chart reproduced by Business of Apps reported 5.7% (AppsFlyer; Business of Apps).
3. Match the category and usage pattern
Compare your product with an app that has a similar natural frequency. A social app, finance app and ecommerce app do not ask people to return on the same schedule.
4. Keep retention and stickiness separate
Day 30 retention measures the survival of an original cohort. DAU/MAU stickiness measures how frequently your current monthly audience returns. Label each metric before comparing it with an external benchmark.
5. Analyse quality data beside app churn
Track whether retention declines coincide with crash rate, ANRs, app versions or device models. Google Play’s per-device threshold means a concentrated device problem can matter even when your overall average remains below the platform-wide limit (Google Play Console Help).
Use your retention segments to decide where to test. A practical mobile functional testing process can then turn the affected journeys, versions and devices into reproducible checks.
6. Segment before acting
At minimum, split your cohort by:
Platform.
App version.
Acquisition source.
Country or region.
Device model.
New versus returning user.
Crash or ANR exposure.
Completion of your app’s first meaningful action.
A blended average tells you that something changed. Segmentation tells you where to investigate.
Methodology and limitations
This report prioritised first-party measurement, official platform documentation and disclosed sample sizes. Figures without a named study, date or methodology were excluded.
The cross-category baseline is not current measurement. AppsFlyer’s approximate 25% Day 1 and 6% Day 30 figures link to its 2021 report, while Business of Apps’ exact 25.3% and 5.7% figures sit beneath a Statista chart dated August 2020 (AppsFlyer; Business of Apps).
UXCam’s category medians are presented as UXCam’s stated figures rather than independently verified primary measurement (UXCam).
Mixpanel’s 2026 figures measure DAU/MAU stickiness, not classic install-cohort retention (Mixpanel).
AppsFlyer’s uninstall analysis is Android-only and covers January 2023 through November 2024 (AppsFlyer).
Luciq’s user-tolerance findings come from more than 1,000 U.S. mobile app users (Luciq). Its crash-free benchmark page does not disclose a sample size, period or methodology, so those figures are labelled as Luciq’s published benchmarks (Luciq).
Airship’s 2026 data measures push-notification performance, not lapsed-user recovery (Airship).
No proprietary Quash telemetry is included. Any future Quash benchmark would need an explicit measurement window, denominator, aggregation method and privacy threshold before publication.
Conclusion
A good app retention rate is not one universal percentage. The benchmark you can defend is the one that matches your cohort definition, category, platform and measurement period.
The familiar 25% Day 1 and 5–6% Day 30 curve remains useful as historical orientation, but it should be labelled as 2020–2021 data. For a current diagnosis, combine cohort retention with app churn, uninstall behaviour, crash exposure, ANRs, app versions and device-level concentration.
Use external benchmarks to locate the gap. Use your own product and quality data to decide what to fix.









