What Twelve Paywalls Taught Me About Pricing an iOS App
Pricing is the one decision in an indie app that gets made in the last hour before submission and then never touched again. It is also the decision with the widest range of outcomes — the same app, same downloads, same product, can produce nothing or produce a business depending on choices that took ten minutes to make and were never revisited.
I spend most of my working life on the finance side of other people's companies, and the rest of it shipping iOS apps under my own name. The two halves rarely inform each other as directly as they do here. Because an app's paywall is a pricing decision, a unit-economics decision, and a product decision at the same time — and most indie developers, myself included at the start, treat it as none of those. They treat it as a number you have to enter into App Store Connect before the build will submit.
What follows is not a set of universal answers. Twelve apps across different categories is a small sample and I would distrust anyone who claimed otherwise. But it is enough to have watched a few patterns repeat, and the patterns are more useful than the numbers.
The first question is not the price, it is the shape
Subscription or one-time purchase is a much larger decision than any specific price point, and it is mostly determined by something outside your control: whether your app has an ongoing cost or an ongoing reason to be opened.
If the app runs inference on a server, syncs across devices, or stores anything you have to keep storing, you have a recurring cost per user and a subscription is not a monetisation strategy — it is the only shape that does not eventually lose money on your best customers. A one-time purchase against a recurring cost is a bet that the user will churn before your infrastructure bill catches up with what they paid you. That is a strange thing to be hoping for.
If the app is fully on-device, does one thing, and the user opens it a handful of times a month, a subscription is a tax on your own conversion rate. Users are now sophisticated about this. A single-purpose utility asking for a monthly commitment reads as extraction, and the App Store reviews say so in language that is hard to recover from.
Charge recurring when your costs recur or your value recurs. Charge once when neither does. Everything else — the specific price, the tier structure, the annual discount — is tuning on top of a choice you cannot tune your way out of if you got it wrong.
Trial length changed more than price ever did
The single most surprising thing across these apps is that moving the price up or down within a reasonable band moved revenue much less than changing when and how the paywall appeared.
The intuition most people carry is that price is the primary lever, because price is the number in the equation. But at indie scale you are not competing on price with anyone in particular — you are competing against the user's uncertainty about whether the thing works. A price change addresses the wrong variable. A trial that lets them find out addresses the right one.
What consistently mattered more: whether the user hit the paywall before or after experiencing the thing the app is actually for. An app that asks for money at launch converts on optimism. An app that asks after the user has completed the core action once converts on evidence. The second number is smaller in raw percentage of installs and much larger in revenue, because the people who convert on evidence do not churn in week two.
A high conversion rate on a paywall shown too early is not a good sign. It usually means you are collecting money from people who have not yet found out whether they want the product, and you will give most of it back in refunds and cancellations.
The number almost nobody computes
Here is where the finance half of my week becomes relevant. Ask an indie developer what their app earns and you get a monthly revenue figure. Ask what a user is worth and you usually get a pause.
Lifetime value on a subscription app is not the price. It is the price, net of Apple's commission, multiplied by the average number of periods a subscriber actually stays, minus whatever it costs you to serve them for that duration. For a monthly subscription with a median retention of four months, the real per-user figure is a fraction of what the sticker price implies — and it is the only figure that tells you whether you can afford to acquire users at all.
This matters most at the exact moment developers stop thinking about it: when they consider paid acquisition. Spending on ads without knowing net lifetime value is not a growth experiment, it is a donation with a dashboard. The threshold question — can I pay less to acquire a user than that user will net me over their life — has a specific answer for every app, and most people running campaigns have never calculated it.
The related number is payback period: how many months of subscription revenue it takes to recover the acquisition cost. If it exceeds the median subscription lifetime, the campaign loses money on average even when the ad dashboard shows installs going up and to the right. This is the same failure that shows up in venture-backed companies at much larger scale, and the diagnosis is identical.
Annual pricing is a cash flow instrument, not a discount
The standard advice is to offer an annual plan at a discount to monthly. That is correct, but the usual reasoning — "it improves retention" — undersells what is actually happening.
An annual plan converts twelve months of uncertain, churn-exposed revenue into cash today. For an independent developer with no outside funding, that is not a retention tactic, it is the difference between being able to fund the next three months of development and not. The discount you offer is effectively the cost of capital on money you are borrowing from your own future revenue, and priced against any other form of financing available to a one-person studio it is extremely cheap.
The caveat that comes with it: annual plans also concentrate your churn into a single renewal moment twelve months out, which is invisible for most of a year and then arrives all at once. If a meaningful share of revenue is annual, the renewal cohort is something to actually track rather than discover.
What I would do differently
Three things, in order of how much they would have mattered.
First, decide subscription-versus-one-time from the cost structure rather than from what comparable apps do. Copying a competitor's pricing shape copies their cost structure assumptions too, and you probably do not share them.
Second, instrument the funnel before shipping the paywall, not after. Knowing what fraction of users reach the core action, what fraction of those see the paywall, and what fraction of those convert, is three numbers that turn pricing from a guess into a decision. Without them you cannot tell whether a bad revenue number is a pricing problem, a product problem, or an acquisition problem — and the fix is completely different in each case.
Third, revisit it. Pricing set at submission reflects what you believed about the product before anyone used it. That belief is the least informed one you will ever have about the app, and it is the one most apps are still running on two years later.
None of this is complicated. It is the same discipline I would apply to any company's revenue model, applied to something small enough that one person can hold the whole thing in their head. That is actually the advantage of building alone — the feedback loop between a pricing decision and its consequence is short enough to learn from, if you are looking.