How Do You Turn App Users Into Paying Customers?

An app with healthy installs and no revenue is the most common failure in mobile, and it usually gets diagnosed several months late. The install is the metric that responds to everything. It goes up when the creative works, it goes up when the bid goes up, and it sits at the top of every dashboard. None of that tells you whether anyone will pay.

The conversion from user to customer happens quickly and mostly in one place. Adapty’s State of In-App Subscriptions 2026, built on $3 billion in revenue across more than 16,000 apps, found that 89.4% of free trial starts happen on day zero. An app that does not make its case in the first session is unlikely to get a second chance at it.

What percentage of app users actually pay?

The percentage of app users who become paying subscribers sits between 2% and 10% for most subscription apps, and which end of that range you land in is decided mostly by category and paywall model rather than by anything in the product.

RevenueCat’s State of Subscription Apps 2026, drawn from 115,000 apps, $16 billion in revenue and more than a billion transactions, measures this as download-to-paid conversion at day 35: the share of installs that produce at least one paid subscription within 35 days of the install date. Top performers clear 10%.

The full comparison of the two models, including what hard gating costs in refunds and audience, is in which converts better, freemium, a free trial or a hard paywall.

The spread by paywall model is wider than most teams expect. RevenueCat found that hard paywall apps convert at a 10.7% median at day 35 against 2.1% for freemium apps.

The best decile of hard paywall apps reaches 38.7%, and the bottom quartile still converts at 4.2%, which is double the freemium median. The two distributions barely overlap: freemium runs 0.3% to 8.2% across the same report, hard paywall 4.2% to 38.7%.

Those numbers are not an argument that every app should gate everything. They are an argument that the model sets the range before any optimisation work starts, so a freemium app grinding its paywall from 1.8% to 2.4% is working inside a band a hard paywall app never has to enter.

If your target is a 10% conversion rate and your model has a 2.1% median according to RevenueCat, no amount of button copy closes that gap.

One caution on reading the benchmark. Download-to-paid at day 35 mixes together the quality of the traffic, the onboarding, the paywall and the price. A poor number tells you the chain is broken somewhere without saying where, which is why the diagnostic metrics below matter more day to day than the headline does.

When should an app show its paywall?

Show the paywall at the end of onboarding, in the first session, for almost every subscription app. Adapty’s 2026 dataset found that an onboarding paywall paired with a free trial converts 1.35% of installs, the highest of any placement and trial combination measured across its 16,000 apps.

The reason is the day-zero concentration: with 89.4% of trial starts happening on the install day, a paywall the user does not reach until session three is a paywall most users will never see.

The instinct to delay is understandable and mostly wrong. Teams hold the paywall back because they want the user to experience value first, and the value does need to be concrete before the ask.

What the data says is that the personalisation loop inside onboarding is where that value gets established, not three sessions of free usage. Motivation is highest immediately after install, when the user still remembers the ad that convinced them, and it decays from there.

Design matters less than placement, and there is at least one measured exception worth knowing. Superwall, analysing more than 40 million paywall opens between February and May 2026, found multi-page onboarding paywalls converting at 12.41% against 9.07% for single-page, a 37% lift. That is a real effect and it is still smaller than the effect of putting the paywall in the right session.

The practical sequence for most apps: a short personalisation flow that visibly shapes what the user gets, then the paywall, then the free experience if there is one. Test the timing before you test the design.

Does the paywall model change how many users pay?

The paywall model changes conversion by roughly a factor of five, and it changes long-term retention almost not at all. RevenueCat’s 2026 figures put hard paywall apps at a 10.7% median day-35 conversion and freemium apps at 2.1%.

On retention of those subscribers a year later, freemium sits at 28% and hard paywall at 27%, a difference small enough to ignore. Adapty adds that hard paywalls produce 21% higher lifetime value per subscriber than soft paywalls.

Paywall model	Median day-35 conversion	One-year subscriber retention	Best fit
Freemium	2.1%	28%	organic and word-of-mouth growth, where a free user costs nothing
Hard paywall	10.7% (top decile 38.7%)	27%	paid acquisition, and products whose value is obvious in thirty seconds
Free trial behind a paywall	42.5% of trials convert to paid at 17-32 days, a different measure from the two rows above	not reported separately	products that need a habit to form before the charge lands

So the trade is volume of users against revenue per user, and the answer depends on where the users come from. An app acquiring through organic search and word of mouth can afford a large free tier, because the marginal user costs nothing and some fraction converts eventually. An app buying installs on Meta and TikTok cannot, because every free user is a line item.

That is the calculation most creator-led app launches get wrong. Paid acquisition makes free users expensive, and a freemium model built for organic growth quietly inverts the unit economics when the traffic starts arriving through an ad account.

Category matters too, and it is the one variable you do not control. Utility and productivity apps with a clear single job tend to survive a hard paywall because the user knows within thirty seconds whether the app does the thing. Social and content apps generally do not, because the value depends on use.

Why do users install an app and then never pay?

Users install and never pay, most often, because the ad and the paywall are selling two different products. An ad promising a free tool sets up a paywall asking for forty dollars a year to fail, and the cost of that mismatch lands in the paywall conversion rate, where it reads as a monetization problem.

This is the seam nobody owns. Performance agencies are measured to the install and stop there, so the ad that produces the cheapest install wins regardless of what it promised. Monetization consultants start at the paywall and take the traffic as given. Between them sits the single question that decides whether the spend works: does the promise that earned the install match the promise that asks for the money?

The check takes an afternoon. Open your five highest-spending ads and your paywall headline in the same window, and write down the claim each one makes.

If the ad says “track your workouts free” and the paywall says “unlock your personalised plan”, the user was recruited for a product the paywall does not sell. Expect low install-to-trial and normal trial-to-paid, which is the signature of an acquisition and monetization mismatch rather than a product failure.

Fixing it usually means changing the ad, not the paywall. Creative that states the paid proposition up front will cost you a higher cost per install and deliver a lower cost per paying user, and cost per paying user is the number that decides whether the channel works.

This is the half of an app launch we run end to end alongside the creative, and the reason we treat app launches as one experiment rather than two.

How long should a free trial be?

Longer than most apps make it. RevenueCat’s 2026 dataset found that trials of 17 to 32 days convert at a 42.5% median, against 25.5% for trials of under four days. A three-day trial converts at roughly half the rate of a three-week one.

The short trial exists to limit how much value gets given away, and for a narrow set of apps with a single high-value action that reasoning holds. For everything else the calculation runs the other way.

A subscription app is asking the user to form a habit, and habits do not form in 72 hours. A trial long enough to survive a full weekly cycle gives the product a chance to become part of one.

There is a second reason to prefer the longer window, which is that it separates two failures that a short trial confuses. A user who cancels on day two of a 30-day trial never intended to pay. A user who cancels on day 25 tried and was not convinced. The first is an acquisition problem, the second is a product problem, and a three-day trial makes them look identical.

Trial length interacts with price and billing period, so it is not a setting to change alone. The pricing architecture question deserves its own treatment, and the short version is that apps whose revenue is led by annual plans monetise installs about twice as well as other apps by day 14, and post a $0.46 median day-60 revenue per install against $0.29 for monthly-led apps, per RevenueCat’s 2026 figures.

What should you measure at each stage?

Measure three rates rather than one, because each isolates a different failure and the composite benchmark hides all of them. Install-to-trial tests whether the ad, the onboarding and the paywall are describing the same product. Trial-to-paid tests whether the product delivered inside the trial. Day-35 download-to-paid is the composite, and its only real use is comparison against the published benchmarks.

Read them in that order. A weak install-to-trial with a healthy trial-to-paid points at acquisition: the creative recruited people who were never candidates. A healthy install-to-trial with a weak trial-to-paid points at the product or the trial length. Both weak usually means the paywall is the wrong offer for the audience, not that the button is the wrong colour.

The number that governs whether any of it is viable is cost per paying user, and it is a multiple of cost per install rather than a variant of it. AppsFlyer data compiled by Digital Applied puts global iOS cost per install at $5.84 in Q1 2026, up 19% year on year, against $1.92 on Android.

Divide that by RevenueCat’s 2.1% freemium median and one paying customer costs about $278 to acquire, against an annual plan with a $34.80 median price. At the 10.7% hard paywall median the same install costs about $55 per paying customer, which is the whole argument for the model in one line.

That arithmetic is why conversion work and acquisition work cannot be run by separate teams with separate targets. Moving conversion from one install in forty to one in twenty-five does more for payback than any bid change, and it is invisible to anyone measuring the account alone.

The short version

Paying customers are won in the first session. Put the paywall at the end of onboarding, pair it with a free trial, and make the trial long enough to survive a weekly cycle.

Choose the model deliberately: hard paywalls convert around five times better than freemium (10.7% against 2.1% at day 35 in RevenueCat’s 2026 data) and retain their subscribers just as well, and paid traffic makes free users expensive in a way organic traffic does not.

At a $5.84 iOS install that difference is roughly $278 per paying customer against $55.

Then check the seam. The most expensive fault in app monetization is not a badly designed paywall, it is a paywall selling something the ad never promised, and no amount of paywall optimisation repairs a user who was recruited for a different product.

Where the advice stops: none of this applies cleanly to social or content apps, where the value depends on other people being there and a hard paywall in the first session removes the thing being sold. Those apps have to earn the subscription later, which means accepting a freemium conversion rate and making the free tier cheap enough to run that the arithmetic still closes.