Hard paywall vs freemium for indie apps: what devs who tested both saw

You built the app, and now you have to decide what a new user sees after onboarding: a screen that says "subscribe to continue", or the app itself with an upgrade button somewhere. Every indie developer forum has this argument, and both sides sound sure of themselves.

The benchmark data points one way. The developers who actually switched point in several directions at once. This guide puts the two side by side, does the arithmetic for a small app, and ends with a test you can run on your own traffic instead of trusting anyone's anecdote.

What is the difference between a hard paywall and freemium?

A hard paywall blocks the core of the app until the user pays or starts a trial. Freemium lets people use a free version indefinitely and charges for more.

• Hard paywall: onboarding, then a paywall with no way into the main feature without subscribing. It often includes a free trial, which still needs payment details up front.
• Freemium: a free tier that works on its own. Pay to remove limits, ads or extra features.
• Soft paywall: a paywall screen with a close button that drops the user into the free tier. It is a type of freemium, and the data below groups them together.
• Hybrid or reverse trial: full access for a set period, then a fall back to a limited free tier.

What does the data say about conversion and revenue?

Hard paywalls convert roughly five times more downloads into paying users, and each payer is worth more in year one. The figures come from RevenueCat's yearly State of Subscription Apps reports, as summarized by Airbridge and Setgreet.

Two things are worth noticing. The gap is large in both years. And refunds are about 70% higher behind a hard paywall, which is the first sign that the clean headline hides some costs.

Watch out: these are medians across thousands of apps that chose their model on purpose. Apps that use hard paywalls tend to be the ones with an obvious, instant value (a scanner, a calorie counter, a photo tool). That self selection explains part of the gap. Your app will not automatically get 12% by flipping a switch.

What does that mean per 1,000 downloads?

On the 2025 medians, 1,000 downloads earn about $5,960 in first year revenue behind a hard paywall versus about $530 on freemium. Here is the arithmetic, so you can redo it with your own numbers.

1. Hard paywall: 1,000 downloads x 12.1% = 121 payers. 121 x $49.30 = about $5,965, or $5.96 per install.
2. Freemium: 1,000 downloads x 2.2% = 22 payers. 22 x $24.24 = about $533, or $0.53 per install.
3. Subtract refunds: 5.8% of hard paywall revenue is about $346; 3.4% of freemium revenue is about $18. The gap barely moves.
4. Remember Apple's commission (15% for most small developers in the App Store Small Business Program) applies to both, so it does not change the ratio.

For an indie dev without an ad budget, revenue per install is the number that decides whether you can afford to grow. If one install is worth $0.53, you cannot pay $1 to $3 per install on Meta or Apple Ads. If it is worth several dollars, you can. That is exactly the trap one freemium fitness developer described on r/AppBusiness: a year in, two paying subscribers, and no way to justify paying UGC creators "because of freemium."

These are medians, not promises. Plenty of hard paywall apps convert under 2%, and the top tenth of freemium apps beat the median hard paywall app. To see how wide the spread is in practice, read how much apps make per download.

What did developers report after switching?

Devs who moved from freemium to a hard paywall mostly report a jump in conversions, but the replies under those posts keep finding other causes and hidden costs. These are the patterns from the threads that rank for this question.

The sharpest reply in the most cited thread came from a developer who explained why switching often works: the free tier holds two groups, people who would pay if they had to and people who will never pay. Forcing the choice splits them, and the payers pay. It also argued that free tiers convert best when they are limited by volume (number of exports, scans, entries) rather than by hiding features, because the people happily using the free features are by definition getting along without the paid ones.

When does a hard paywall win?

A hard paywall wins when the value is obvious in the first minute and you need revenue per install high enough to fund growth. It fits apps like:

• Single purpose utilities where the result is visible immediately (scan, convert, measure, generate).
• Apps you plan to grow with paid ads or paid UGC, where you need a positive return on each install.
• One time or short term problems. As one r/appledevelopers reply put it, "If it is a one-time thing, paywall is the way to go."
• Apps where server or AI costs make free users a real expense. Free users "drain your servers, not your Stripe account," as one multi app founder wrote.

If you go this way, the trial question comes next. Our guide to free trial vs no free trial for iOS apps covers that test, and the App Store Apps pack walks through building the paywall screen itself, from the headline to the plan order.

When does freemium win?

Freemium wins when users need days of real use to see the value, or when ratings, word of mouth and daily users are your growth engine. It fits:

• Habit apps (journals, trackers, budgeting) where value builds over weeks.
• Apps in crowded categories with a genuinely better product, where reviews and referrals bring users. One reply argued: tons of competition, low budget, high quality app, go freemium.
• Apps that need a network or shared content to be useful.
• Developers who care most about goodwill. One dev planning to go all in on freemium listed easier implementation, more daily users for App Store reputation and more referrals.

The honest downside: freemium needs volume. At around 2% conversion, 100 downloads a month gives you two payers. If your app gets ten downloads a day, the math is hard either way, and distribution is the problem to fix first.

What about hybrids like reverse trials?

Hybrids try to keep most of the hard paywall's revenue without its refunds and anger, and many experienced devs now default to one. Common versions from the threads:

• Reverse trial: full pro for 7 to 30 days, then a limited free tier.
• Paywall after the first win: let the user complete one real task free, then show the paywall right after that moment. "Easier to make it stricter than to loosen it once reviews start coming in," one dev advised.
• Freemium plus time limited offer: a free core with a discount for new users in their first days.
• Credits: a free allowance, then pay per use for people who dislike subscriptions.

There is little public benchmark data on hybrids yet, which is why you should test them rather than assume.

How do you test hard paywall vs freemium on your own app?

Change one thing, keep the traffic the same, and compare revenue per install after trials and refunds settle. A plan that works for a small app:

1. Track installs, trial starts, paid conversions, refunds and revenue per install by source. RevenueCat or a similar tool makes this easy.
2. Pick two variants only, for example a hard paywall versus one useful free action, as a reply in the top thread suggested.
3. Keep onboarding, price and screenshots identical, so you know the paywall caused the change.
4. Send both variants the same traffic source. Apple Ads traffic and TikTok traffic behave very differently.
5. Wait for a few hundred installs per variant and two to five weeks, so renewals and refunds show up.
6. Check reviews and ratings weekly. A conversion gain that tanks your rating is not a gain.
7. Keep the winner, then test the next variable (trial length, price, weekly plan). See weekly vs yearly subscription pricing for that step.

Tip: do not read trial start rate as success on its own. One reply in the top thread warned that a 20% trial start rate proves little until you see paid conversion, cancellations and retention.

What mistakes do devs make with this choice?

The biggest mistakes are changing several things at once, ignoring reviews, and picking a model before fixing distribution.

• Crediting the paywall for an onboarding change. If you rewrote onboarding the same week, you do not know which one worked.
• Hiding the price or the close button. That is where the "scam app" reviews and refunds come from. Apple's guidelines also require clear pricing on the purchase screen.
• A free tier that gives away everything. If free users never hit a limit, they will never pay.
• A free tier so thin it is useless. Then it is a hard paywall with extra steps and none of the goodwill.
• Judging after a weekend. Early spikes fade, and refunds arrive later.
• Blaming the model for a traffic problem. At ten downloads a day, no paywall choice will save the app.

Where to go from here

If you are deciding today, this order works for most indie apps:

1. Ask whether a new user can see the value in the first minute. If yes, start with a hard paywall or a paywall after the first win.
2. If the value takes days, start with a reverse trial or a volume limited free tier.
3. Instrument revenue per install, refunds and ratings before you change anything.
4. Run one clean two variant test on the same traffic.
5. Move on to price and trial tests once the model is settled.

The App Store Apps pack has the full step by step behind this: 24 lessons across 6 modules on picking the gap, ranking in search, paywall and pricing tests, and getting installs without ads, with the checklists and templates to run each one, for $19. All 16 Money Printer packs are $39.