Paid, freemium or subscription for indie apps

This is a decision guide, not an implementation guide. StoreKit and the purchase flow belong in StoreKit 2 and in-app purchases. What it costs to build and run an app is a separate question, which I have written about in What an iOS app really costs. Apple’s commission, tax and programme rules change; I will describe the existence of commission and point you at the current terms, and I will not treat a percentage as a permanent figure.

The model is a product decision, not just a price

Before you talk about “£2.99 versus £4.99,” decide what the person is paying for:

• a finished tool they can keep using in its current form
• extra pieces of a tool they can already try
• an ongoing service: new content, synced data, a server, or a promise that the app will keep up with the OS

Those are three different products. A calculator that works offline is a finished tool. A camera app with optional film packs is a tool with extra pieces. A news reader that depends on your server is an ongoing service. A subscription on a finished, offline tool is a hard sell, and a one-off payment for an app that will stop working if you turn the servers off is a nasty surprise.

Write a sentence in the Website Brief & Quote Builder, or in any notes file, that a stranger could read: “This is a paid app because…,” “This is free with a one-off unlock because…,” or “This is a subscription because….” If you cannot finish the sentence without using the word “monetise,” the model is not ready.

The MVP checklist is useful here too. A first version can ship with a simpler model than the one you hope to grow into, as long as you do not paint yourself into a corner with your first customers.

Paid up front: clear, and limited

A paid app has a price on the product page. The person pays, they download, they own the use of that app under the store’s rules, and you do not have to invent a paywall. For a small, focused utility — the kind I have written about in the case study of small Apple apps spirit, even when the commercial details differ — this is still a coherent choice.

Its strengths are real:

• The deal is obvious. A visitor can see the price before they install, and App Review will not have to hunt for a hidden charge.
• You are not running an account system just to record who paid, if the store handles the purchase.
• Family Sharing can apply, which is a genuine benefit you should mention if you have enabled it.
• You can still charge for a major, later edition if you eventually ship a new app, though that is a heavy way to do business and should not be the plan on day one.

Its limits are also real:

• Discovery is harder. Many people browse the free tab, and a paid app asks for a decision before the first launch. Screenshots and a clear subtitle have to do more work.
• The money arrives once. Upkeep, OS changes and support still have to be paid for, somehow, from that one payment and from later new customers.
• Refunds and “I bought this on my old phone” still happen, and they are Apple’s process, not yours, but you will still hear about them.
• Trials are less natural than they are for a subscription, though Apple has offered mechanisms that you should check in the current StoreKit documentation if you need a try-before-you-buy path.

Paid up front works when the app is complete enough to be worth a decision, when it does not depend on your servers for basic use, and when you can live with a slower trickle of customers who already understand the job. It is a poor fit if the first launch is empty without an account, or if you already know you will be adding paid features every month.

Freemium and one-off purchases

“Freemium” here means the app is free to install, and some of its capability is unlocked with a one-off in-app purchase (or several). That is different from a subscription, and it is different from a free trial of the whole app.

This model is honest when:

• the free part is already useful, not a broken demo that exists only to tease
• the purchase is a clear unlock (remove limits, add a feature set, unlock a pack), described in the language of the app, not as “pro gold premium”
• you are prepared to support both the free and the paid states, including restore-purchases, for as long as the app is for sale

It is a mess when the free mode is a sequence of pop-ups, when every useful button opens a paywall, or when a one-off purchase is silently converted into a recurring charge. App Review has rules about how you present purchases; follow the current App Review Guidelines and Apple’s in-app purchase documentation, and don’t try to walk around the system payment sheet.

One-off purchases also work inside a paid app (a “paid plus IAP” mix). That can be fair for optional packs. It can be resented if the paid app already felt complete and you later move basic features behind a new counter.

Think about restore, about multiple devices, and about what happens if you later want to switch to a subscription. The last of those is possible but awkward, and it is one of the reasons to pick carefully now rather than “just make it free for now.”

Subscriptions, and the support they imply

A subscription is a promise. The person is paying for the next month or year, not only for the binary they installed. That promise is easier to keep if something actually continues: new content, a sync service, a model you pay to run, compatibility with new OS releases that takes real time, or a feature that is expensive to provide per user.

A subscription is harder to justify when the app is a finished, offline tool that you might not open for a year, and that will still do the same job. People are not wrong to resist that. “Updates” in the thin sense of “I might fix a bug” is what paid-up-front already implied, not a reason for a monthly charge.

If you do charge a subscription, be prepared to:

• run the account and the status checks reliably, including in the offline and expired states
• explain the price and the period on the product page and at the point of purchase, in the way Apple currently requires
• offer a way out that is no harder than the way in, using the system’s subscription management
• keep doing the work you described, or be honest when you stop and shut the subscription down according to the current rules

A weekly price that only makes sense if someone forgets they subscribed is not a model; it is a trick. Don’t use it.

Trials, paywalls and not tricking people

Trials are useful, and they are easy to abuse. A fair trial:

• has a clear length and a clear end, shown before the person agrees
• does not start a paid period in the background without a purchase they understood
• lets them use the thing the app is for, not a crippled mode that cannot show them the value
• reminds them, in the ways the store already supports, that a charge is coming

Paywalls should be readable in one glance: what you get, what it costs, how often, and how to cancel. If that sentence is turning into a paragraph, cut it; the Word Counter is a useful check that the offer is still short enough to read on a phone. They should be reachable from settings later, when the person wants to buy, not only sprung once at launch. They should not impersonate a system alert, and they should not hide a decline button.

If the app is free with an optional tip or a one-off unlock, don’t dress the prompt up as a fake error. If the app is paid up front, don’t install a second paywall on top without a very good reason. Read the current guidelines for subscriptions, paid apps and prominently displayed prices before you ship, not after a rejection.

The tone of the rest of the app matters here. A careful, quiet tool with a shouting paywall feels like a different product, and people will review it as one.

Commission, VAT and the price people actually see

Apple charges a commission on paid apps and in-app purchases sold through the App Store. The rate, the Small Business Programme, and any alternative terms that may apply in a given country can change, and they depend on your current status. Read the latest Apple developer and App Store agreements and the current commission documentation when you do the sums. I will not quote a percentage here as if it were a constant.

Two practical consequences, regardless of the current rate:

• The number in your head is not the number that arrives. Budget for commission, and for the fact that a price tier is a gross figure, not a net one.
• The number on the product page is not always the number you typed. Taxes, including VAT, can change what a customer in a given storefront sees, and who collects that tax. I have written a map of that in VAT when selling apps and digital products in the UK; it is not tax advice, and you should confirm the current position with HMRC and with Apple’s tax forms.

Price the app in the currency you think in, then look at the storefronts you actually care about, on a device or in App Store Connect’s pricing view, before you announce a figure. A “simple” £3.99 can surprise you in another country. There is more on choosing the number itself in How to price a small app or digital tool.

Don’t pick a subscription price by dividing a paid-up-front price by twelve and hoping. The products are different, and the support is different. Use a short cost list (Apple’s fee, your own time, any servers, the tax treatment) rather than a competitor’s screenshot. The Performance Budget Calculator is a reminder of the same idea in another form: set a budget, then see whether the design still fits. Here the budget is money and upkeep, not kilobytes.

A decision guide for a small app

Work through these in order, and stop when the answer is uncomfortable:

1. Does the app do a complete job without your servers or a regular feed of new content? If yes, start with paid up front or a free app with a one-off unlock, not a subscription.
2. Can a new user understand the value in a minute or two of honest use? If not, a paid-up-front price will be a steep ask, and a paywall in the first session will be worse. Fix the first run, or narrow the MVP, before you pick a model.
3. Is there a free part that is genuinely useful on its own? If yes, a one-off unlock can work. If no, don’t ship a hollow free app; ship a trial or a paid app.
4. Will you still be doing chargeable work for this person in six months? If you cannot describe that work, don’t charge a subscription for it.
5. Can you support the unpaid state, the paid state, restore, and refunds without a team? If not, prefer the simplest model — usually paid up front — until you can.
6. Does the store page tell the same story as the paywall? If the subtitle says “one-off purchase” and the app is a weekly subscription, fix the story.

Write the answer down, and show the paywall or the price to someone who is not you. If they cannot explain the deal back to you, it is not clear enough.

Changing model later

You can change, and it is work.

Moving from paid up front to a free app with purchases, or to a subscription, means a new product-page story, a new review, and a decision about people who already paid. The decent options are to grandfather them into the features they paid for, to offer a discount, or not to take away what they bought. Taking away features and asking for a subscription in their place is how you earn one-star reviews you will deserve.

Moving from a subscription to a one-off, or to paid up front, is less common and can be cleaner, but you must still handle existing subscribers according to the current rules, and you must not strand a person who paid for a year of a service you are about to stop.

Don’t invent a fourth model as a compromise (a subscription and a confusing lifetime IAP and a paid tier) unless you have the support capacity of a much larger team. A small app should be explainable in one sentence at the till.

Key takeaways

• Choose the model that matches the job and the upkeep: a finished tool, optional extras, or an ongoing service.
• Paid up front is still viable when the app is complete, understandable, and not a server in disguise.
• Freemium only works if the free mode is useful and the unlock is clear; a subscription only works if you will keep doing the work people are paying for.
• Don’t trick anyone with paywalls or trials, and don’t treat Apple’s commission or VAT as a rounding error — check the current terms.
• If you change model later, look after the people who already paid.

If you want a second pair of eyes on a pricing model, tell me about it.

Frequently asked questions

Written by Lee Johnson. Published 10 November 2026.