Download-to-paid conversion is the share of installs that go on to buy a paid subscription. In RevenueCat's 2026 dataset the median subscription app converts 2.0% of installs into paying subscribers within 35 days. That single figure hides a range from 1.0% in Gaming to 2.9% in Health and Fitness, from 0.7% of installs in India and South East Asia to 2.8% in North America, and from 2.1% for freemium apps to 10.7% for apps behind a hard paywall. It is also the most useful single number a paid acquisition team can know, because multiplied by what a payer is worth it tells you the most you can afford to pay for an install.
It is also the benchmark most often quoted wrongly. The source report publishes two different geographic cuts of the same metric, its own summary text contradicts its chart on the App Store versus Google Play gap, and the most famous figure in it is routinely relabelled as something else. Below are the 2026 numbers with every definition checked against the report text, the traps worth knowing before you quote any of them, and the arithmetic that turns the rate into a media decision.
Download-to-paid benchmarks at a glance, 2026
All figures below are medians across apps from RevenueCat's State of Subscription Apps 2026, which covers more than 115,000 apps, over $16 billion in revenue and more than a billion transactions. Every one is a D35 rate: installs producing at least one paid subscription within 35 days of the install date, divided by all installs.
| Segment | Median download-to-paid (D35) | Top quartile |
|---|---|---|
| All apps (global) | 2.0% | Not published |
| Health & Fitness | 2.9% | Above 6.2% |
| Gaming | 1.0% | Above 2.3% |
| North America (user region) | 2.8% | Above 6.0% |
| India and South East Asia (user region) | 0.7% | Above 1.9% |
| Hard paywall | 10.7% | Above 20.0% |
| Freemium | 2.1% | Above 4.5% |
| App Store | 2.6% | Not published |
| Google Play | 0.9% | Not published |
The spread inside each row matters as much as the median. The floor for most categories sits between 0% and 0.3%, the top 10% of North American apps reach 10.9%, and the top 10% of hard paywall apps reach 38.7%. A median tells you what a typical app does. It does not tell you what yours should do.
What download-to-paid measures, and why D35
RevenueCat defines the metric as the share of installs that result in at least one paid subscription within 35 days of the install date. Two parts of that definition do most of the work.
- The denominator is installs. Not trial starts, not paywall views, not users who completed onboarding. Every install counts, including the ones that never open the app a second time. That is what separates this rate from trial-to-paid, whose denominator is trial starts, and from paywall conversion, whose denominator is paywall views.
- The numerator counts every route to paying. A user who starts a free trial and converts counts. So does a user who pays directly with no trial. For a trial-based app the rate is roughly install-to-trial multiplied by trial-to-paid, plus direct purchases. That makes it the one rate that works across every monetisation model, which is why it is the right figure to compare a hard paywall app with a freemium one.
The 35 day window is long enough to capture a 7 day trial, a 14 day trial and most 30 day trials resolving. It is not long enough to catch everyone. That matters more than it sounds, and we come back to it below, because D35 is best read as a floor rather than a final count.
Where this rate sits in the wider funnel, from install through to renewal, is set out in our subscription app marketing strategy guide.
Download-to-paid by category
The first column is RevenueCat's all-store median by category. The last column comes from a separate chart in the same report that splits the rate by store, and shows the App Store median only. Education appears in the store chart with a stated figure but not in the all-store chart's text, so its all-store median is not quoted here.
| Category | Median, all stores | Top quartile | Median, App Store only |
|---|---|---|---|
| Health & Fitness | 2.9% | Above 6.2% | 3.5% |
| Business | 2.6% | Above 5.0% | 3.0% |
| Education | Not stated in text | Not stated in text | 3.1% |
| Shopping | 1.3% | Not published | Not stated in text |
| Gaming | 1.0% | Above 2.3% | 1.3% (Google Play 0.4%) |
Two things stand out. First, Gaming's top quartile threshold of 2.3% is barely above the median for most other categories. Subscription games are a different business from subscription utilities, and borrowing a general benchmark will make a good game look broken. Second, the ceilings diverge far more than the floors. RevenueCat notes that Health and Fitness, Education and Business show the largest gap between their upper quartile and their top 10%, and in the store chart the leading iOS apps in Education and Health and Fitness reach 12% to 14%. In these categories the app, not the category, sets the ceiling.
If you are a fitness app, the practical point is uncomfortable. At 2.9% the category median is nearly half as high again as the global median, so a fitness app celebrating a 2.2% rate for beating the market is sitting below most of its direct competitors. Benchmark against your category or not at all. For the cost side of the same vertical, the health and fitness CPI benchmarks are the companion read.
Download-to-paid by market, and the two geography charts
This is the first trap in the report. RevenueCat publishes download-to-paid by region twice, and the two charts measure different things.
Chart one: by region
| Region | Median download-to-paid (D35) | Top quartile |
|---|---|---|
| North America | 2.8% | Above 6.0% |
| Asia-Pacific | 2.4% | Above 5.1% |
| India and South East Asia | 0.7% | Above 1.9% |
| Global | 2.0% | Not published |
Chart two: by developer headquarters
| Developer HQ | Median download-to-paid (D35) | Top quartile |
|---|---|---|
| North America | 2.6% | Above 5.6% |
| Western Europe | 2.0% | Not published |
| Latin America | 1.5% | Not published |
| India and South East Asia | 1.4% | Not published |
The second chart groups apps by where the company that built them is based. The first is labelled simply by region, and we read it as the region of the user, since the other chart is explicitly labelled by developer headquarters. The difference is large at the bottom end. By region, India and South East Asia converts at 0.7%, a quarter of North America's 2.8%. By developer headquarters it is 1.4%, a little over half of North America's 2.6%.
The report's own funnel summary then quotes the headquarters figures, written as 2.56% and 1.37%, alongside a North American 90th percentile of 11.3%, which matches neither chart's stated top 10% (10.9% by region, 10.4% by headquarters). Unsurprisingly, the 2.56% figure is already circulating online as the overall North American benchmark.
For anyone buying media, the chart that matters is the first one. You buy traffic by where the user is, not by where your office is. A UK developer expanding into South East Asia should plan around 0.7%, not 1.4%, and the difference halves the CPI that market can support. This compounds with the install-to-trial gap we set out in the 2026 install-to-trial benchmarks, and it is why a cheaper market is only cheaper if its CPI falls by more than its conversion does.
Download-to-paid on the App Store versus Google Play
This is the second trap, and it is a contradiction inside the report itself.
RevenueCat's chart splitting download-to-paid by store and category states a global median of 2.6% on the App Store against 0.9% on Google Play, which it describes as roughly 2.9 times, and says there is no category where Google Play beats iOS at the median. The report's Apple versus Google summary section, a few paragraphs later, says Apple leads on download-to-paid by 2.9% versus 2.6%.
Both cannot be right, and we think the chart is. Its figures are internally consistent: 2.6 divided by 0.9 is 2.9, the multiple the chart itself states, and the category figures beneath it (Health and Fitness at 3.5% on iOS, Gaming at 1.3% on iOS and 0.4% on Google Play) fit a gap of that size. The summary's "2.9% versus 2.6%" reads like the 2.9 times multiple and the 2.6% iOS median transposed into a pair of rates. It is also the only reading consistent with RevenueCat's revenue per install figures for the same comparison, $0.42 on iOS against $0.23 on Google Play at day 60. Adapty's State of In-App Subscriptions 2026 points the same way from a separate panel: it reports iOS converting installs to paid about three times better than Android, and 3.6 times better on annual plans. Adapty's figure is an average of per-app rates rather than a median, so it is corroboration of direction, not of the exact number.
The more interesting fact is where the gap opens. The same RevenueCat report finds trial-to-paid almost identical across stores, at 32.6% on the App Store and 32.5% on Google Play. So the iOS advantage is not about what happens during a trial. It is about how many installs get as far as a purchase decision at all. For a media buyer that means Android's lower CPI has to cover a roughly threefold conversion gap before it is the better buy, which is the argument we make on the cost side in iOS versus Android CPI.
Hard paywall versus freemium download-to-paid
The headline is well known: a 10.7% median for hard paywall apps against 2.1% for freemium. Less well known is the rest of the distribution. The hard paywall top quartile starts at 20.0% and its top 10% reach 38.7%, while RevenueCat describes its low end at 4.2%, about twice the freemium median. Freemium runs from 0.3% to 8.2%. RevenueCat's conclusion is that hard paywalls' wide spread suggests execution matters more than the model alone.
Three caveats belong beside that number every time it is quoted.
- It is a download-to-paid rate, not a trial-to-paid rate. RevenueCat's own summary post once described it as a trial-to-paid figure, and a large number of articles have repeated the wrong label. We explain the damage that does in the trial-to-paid benchmarks.
- The conversion gap does not carry through to retention. RevenueCat finds year-one retention on yearly plans at 27% for hard paywall apps and 28% for freemium, and 9% against 8% on monthly plans. Refund rates are similar too, 2.5% against 2.9%. Hard paywalls convert more people, earlier. They do not appear to convert better people.
- It is correlation. Apps that choose a hard paywall are not a random sample. They tend to have a clear, specific promise that can be sold before the user has tried anything, and that is also what makes people pay. Switching a freemium app with a vague value proposition to a hard paywall will not deliver 10.7%.
Adapty's report adds a finding that looks like it contradicts all of this and does not. Adapty says soft paywalls, the ones a user can close, convert nearly 50% better than hard paywalls. Its denominator is paywall views, not installs. The likely reason the two findings coexist is who sees each paywall: a hard paywall is shown to every install at the gate, including every install that was never going to pay, while a closable paywall's views can come from users who are already engaged. Per view, soft wins. Per install, hard wins. Both are true, and the number that pays for media is the per-install one. Adapty also reports hard paywall users generating 21% higher one-year LTV.
For paid acquisition the practical consequence is speed. RevenueCat's day 60 revenue per install is $3.09 for hard paywall apps against $0.38 for freemium. A hard paywall cohort tells you whether a campaign works within days. A freemium cohort keeps converting for weeks, which changes how and when you should judge it.
Download-to-paid by price point and for AI apps
| Segment | Median download-to-paid (D35) | Top quartile |
|---|---|---|
| High-priced apps | 2.8% | Above 6.1% |
| Mid-priced apps | 2.0% | Above 4.4% |
| Low-priced apps | 1.4% | Above 3.7% |
| AI apps | 2.4% | Above 4.8% |
| Non-AI apps | 2.0% | Not published |
Price tier is relative to the rest of the panel. High-priced apps convert installs to paid at twice the rate of low-priced ones, and the top 10% of high-priced apps reach 13.5%. As with install-to-trial, we would not read this as permission to raise prices. The apps that can hold a high price are usually the ones selling a specific result, and a specific result is also what converts. The data cannot separate the two.
AI apps convert at 2.4% against 2.0% for everything else, a narrower gap than at the trial stage, and RevenueCat notes non-AI apps match or slightly beat AI apps at the top end. The same report finds AI apps churning faster, so a higher conversion rate here is not on its own evidence of a better paying user.
Why D35 is a floor, not a final count
RevenueCat's time-to-paid data shows 50.6% of paid conversions happening on the day of install and 19.2% in week six or later. Both are shares of the conversions that eventually happen, not shares of installs. Week six begins on day 35, so almost all of that final fifth of conversions sits outside a D35 rate.
The tail is not the same for every app:
- Freemium apps see 23% of their conversions arrive six or more weeks after download. Hard paywall apps instead show a spike between days 4 and 7, at 25.7% of conversions, which RevenueCat attributes to 7 day trials expiring.
- By region, North America has the lowest Day 0 share at 44.2% and Western Europe the longest tail, with 21.2% of conversions in week six or later. The Middle East and Africa converts fastest, 63.5% on Day 0.
- By category, Travel has 28.2% of conversions after week six, while Productivity converts 71.9% on Day 0.
Two practical consequences follow. First, any download-to-paid read taken in the first week of a cohort is seeing roughly half of what the cohort will produce, which is why the same cohort's Day 7 ROAS and its eventual return can look like two different campaigns. Second, as an indicative adjustment only: if an app's timing matched the all-category pattern, a 2.9% D35 rate would end up somewhere near 3.6% once the late converters arrived. Late payers are not guaranteed to be worth the same as early ones, so treat the D35 figure as your planning number and the tail as upside.
Paid installs convert below the published medians
Every figure above blends paid, organic, search and referral installs. RevenueCat does not split download-to-paid by acquisition source. That matters, because the benchmark most paid social teams hold themselves to includes installs from people who went looking for the app.
The best public indication of the gap comes from Adapty's Apple Ads install-to-paid benchmarks, drawn from more than a million Apple Ads ad groups. Across that dataset, Apple Ads installs convert to paid at 1.92% against 0.91% for other paid channels, and Adapty's own guidance frames that comparison as Apple Ads against Meta or TikTok. At the trial stage the gap is 3.66% against 1.45%. Adapty attributes the difference to intent: a user who searched for a solution is closer to paying than one whose scroll was interrupted.
That dataset is a different panel from RevenueCat's, reports an average rather than a median and states no conversion window, so the two cannot be subtracted to produce a paid social benchmark. The direction is still the useful part. An account buying most of its installs on Meta should expect a download-to-paid rate below the 2.0% blended median without anything being wrong, and a team that holds its Meta cohorts to the blended figure will conclude its ads are failing when they may be performing normally.
The fix is to stop borrowing a baseline. Track download-to-paid by acquisition source and by campaign, compare each paid cohort with your own paid history, and use the published medians only as a sanity check on the direction of travel. On iOS, where attribution is aggregated and delayed, that usually means reading cohort conversion from your own subscription data rather than from the ad platform, for the reasons set out in our note on SKAdNetwork postback delays.
Turning download-to-paid into the CPI you can afford
This is the reason to know the number. The relationship is direct:
Allowable CPI = download-to-paid rate × the most you will pay to acquire one paying subscriber
The second term should be built from net revenue, after store fees. On the App Store a developer receives 70% of a subscription's price in the subscriber's first year and 85% after a year of paid service. On Google Play the fee on auto-renewing subscriptions is 15% in total. Our guide to subscription app CAC covers building that figure properly, including what to do about creative and agency costs.
The figures below are hypothetical and are not client data. Take a subscription app that is willing to pay up to £40 to acquire a paying subscriber, a figure that might reflect first-year net revenue on an annual plan if the app wants paid growth to pay back within twelve months. Hold that constant and vary only the download-to-paid rate, using published medians and thresholds as the reference points. The last column shows what each payer costs if the app is buying installs at £2.00.
| Download-to-paid | Reference point | Installs per payer | Allowable CPI at £40 per payer | Cost per payer at £2.00 CPI |
|---|---|---|---|---|
| 1.0% | Gaming median | 100 | £0.40 | £200.00 |
| 2.0% | Global median | 50 | £0.80 | £100.00 |
| 2.9% | Health & Fitness median | 34.5 | £1.16 | £68.97 |
| 6.2% | Health & Fitness top quartile | 16.1 | £2.48 | £32.26 |
| 10.7% | Hard paywall median | 9.3 | £4.28 | £18.69 |
At the global median this app can afford £0.80 an install, and at £2.00 it is paying £100 for a subscriber worth £40. At the Health and Fitness top quartile threshold the same £2.00 install produces a payer for £32.26 and the account is profitable. Nothing in the ad account differs between those rows. This is why a CPI benchmark on its own says so little: a £2.00 CPI is disastrous at one conversion rate and comfortable at another. We make the same point from the cost side in CPI vs CPA vs CAC for subscription apps, and the install costs themselves are in the 2026 mobile app CPI benchmarks.
One further observation from the table. Moving from the median to the top quartile threshold in Health and Fitness more than doubles the CPI the app can afford. Very few bidding changes can do that. The download-to-paid rate is where most of the room in a subscription app's economics sits, and the media buyer shares responsibility for it with whoever owns onboarding and the paywall.
If your download-to-paid rate is below benchmark
Because download-to-paid is the product of the stages beneath it, a weak rate is a question about which stage, and it is worth answering before touching budgets.
- Compare against the right slice first. Category, store mix, user region, paywall model and traffic source all move the benchmark by more than most apps' own week-to-week variation. A freemium Android-heavy app buying on Meta in South East Asia is not underperforming at 0.8%.
- Then split it into install-to-trial and trial-to-paid. If install-to-trial is weak, the problem is in the first session: the ad's promise, onboarding or the first paywall. If trials start at a normal rate but do not convert, it is the trial experience, the price or trials started out of curiosity. The two need different fixes.
- Split both by creative concept. If download-to-paid varies widely between concepts landing on the same onboarding, the ads are creating the gap. A concept that wins on installs and loses on paid conversion is buying the wrong people cheaply.
- Check the window before the verdict. A freemium cohort read at day 14 has not finished converting. Compare like with like, at the same cohort age.
What this looks like in an account
The case on our site that speaks most directly to this rate is Steps & Beasts, an indie step-counter and fitness app. Alongside heavy creative testing, onboarding changes lifted install-to-subscriber conversion, which is download-to-paid by another name, and revenue rose 145% with active subscriptions up 118%. The case study does not publish the conversion rate before or after, and we would not invent one. The point it illustrates is that creative and onboarding were worked on together, because the rate belongs to both.
BabyNaps shows why the distinction between a count and a rate matters. More diverse creative cut CPI by over half and paying users grew 829%. That is growth in the number of payers, not a change in the download-to-paid rate, and a buyer should never read one as the other. It does show the thing this article keeps returning to: when the cost of an install falls and the share of installs that pay holds up, the number of payers moves far more than either figure alone would suggest.
Frequently asked questions
What is a good download-to-paid conversion rate for a subscription app?
RevenueCat's 2026 data puts the median at 2.0% of installs producing a paid subscription within 35 days. The useful comparison is your own slice: Health and Fitness has a median of 2.9% with a top quartile above 6.2%, Gaming 1.0%, North America 2.8%, apps with a hard paywall 10.7% and freemium apps 2.1%. On the App Store the median is 2.6% against 0.9% on Google Play. Beating the global median can still mean you are below your own category.
How is download-to-paid conversion rate calculated?
Divide the number of installs that went on to buy at least one paid subscription by the total number of installs in the same cohort. RevenueCat counts a paid subscription only if it happens within 35 days of the install date, which is why the figure is often written as D35. The rate includes users who converted from a free trial and users who paid directly, so for a trial-based app it is roughly install-to-trial multiplied by trial-to-paid, plus any direct purchases.
Is download-to-paid the same as trial-to-paid?
No. Download-to-paid divides paying users by installs. Trial-to-paid divides paying users by trial starts, which is a far smaller number, so trial-to-paid rates are many times higher. RevenueCat's widely quoted hard paywall figure of 10.7% is a download-to-paid rate within 35 days, and it has often been repeated as a trial-to-paid rate. Always check the denominator before comparing any conversion benchmark with your own figure.
Why do hard paywall apps convert so many more downloads to paid?
Because nobody can use the app without choosing to pay or start a trial, so every install is pushed to a decision immediately. RevenueCat reports a 10.7% median for hard paywall apps against 2.1% for freemium, with nearly identical year-one retention. Part of the gap is also selection: the apps that choose a hard paywall are not a random sample. Adapty reports that soft paywalls convert paywall views to payment better than hard ones, which sounds contradictory but uses paywall views as its denominator rather than installs.
What download-to-paid rate should I expect from Meta or TikTok installs?
Usually lower than the published medians, because those medians blend paid, organic and search installs. In its Apple Ads report, Adapty puts install-to-paid at 1.92% for Apple Ads traffic and 0.91% for other paid channels across its dataset. That is a different panel and statistic from RevenueCat's, so the two cannot be subtracted, but the direction is clear. Build your own baseline by acquisition source and judge paid social cohorts against it.
How do I turn download-to-paid into a target CPI?
Multiply your download-to-paid rate by the most you are willing to pay to acquire one paying subscriber. On a hypothetical app willing to pay £40 per payer, a 2.0% rate supports a £0.80 CPI and a 6.2% rate supports £2.48. Use net revenue after store fees when setting the per-payer figure, and remember that a D35 rate slightly understates the eventual conversion because some users pay after week five.
The short version
The median subscription app turns 2.0% of installs into paying subscribers within 35 days, and the figure that applies to you depends on category, store, user region, paywall model and where the installs came from. The source report publishes two geography charts that disagree because they measure different things, and states the App Store versus Google Play gap two ways, of which the 2.6% against 0.9% chart is the credible one. D35 is a floor, and paid social installs convert below blended medians. Multiply the rate that genuinely applies to your app by what a payer is worth to you, and you have the ceiling on what you can pay for an install.
If you know your download-to-paid rate by acquisition source and by concept, you are ahead of most accounts. If you do not, it is usually the first thing we build. Our consumer apps page sets out how we run subscription acquisition on Meta, the creative refresh calculator gives a rough read on how many concepts your spend level needs to test, and if your app is already spending, our pricing is published.