Guide
The models — subscriptions, purchases, ads, and the hybrids — plus the part most guides skip entirely: the subscription infrastructure layer, with real tools, their real pricing from their own pages, and an honest account of what Apple and Google take.
Most monetization guides cover the models and stop, as if choosing "subscriptions" were the work. It is maybe a fifth of it. The rest is implementation — entitlements, receipt validation, paywalls you can change without shipping an update, knowing which price test actually worked — and there is a whole tooling layer for exactly that, which the guides written by web-platform vendors tend not to mention, for a structural reason we will get to.
This guide covers both halves. The models first, briefly and without invented revenue statistics. Then the store commissions as actually published. Then the tools — RevenueCat, Adapty, Superwall — with what each does, what each costs from its own pricing page, and when you genuinely need one versus when Apple's own StoreKit is enough.
One disclosure, as everywhere on this site: Modaal builds native iOS and Android apps and we sell it. The relevance to this article is one specific fact — a Modaal project is a standard Xcode project, and every tool below integrates with a standard Xcode project the ordinary documented way. None of these tools pays us and none is a partnership; they are here because they are what working subscription apps actually use.
The App Store's dominant model for a reason: recurring revenue compounds, and Apple and Google handle the renewal machinery. They suit apps used repeatedly whose value renews — tools, content, services. Their cost is an obligation: a subscription is a promise the app keeps improving, and churn is the price of breaking it.
Consumables (coins, credits, exports) and non-consumables (unlock pro, remove ads, lifetime access) — they suit apps whose value is a thing rather than a stream. "Lifetime" deserves respect as more than a subscription apology: for utilities people genuinely prefer to own, it converts users subscriptions never would.
Nearly extinct outside niches, because it prices the app before the user has felt it. The niches are real, though: professional tools with reputations, and audiences actively hostile to subscriptions.
Needs scale before it pays — the going rates per thousand impressions mean small audiences earn coffee money — and every ad format spends your users' patience. We will not quote eCPM figures because every published number is either invented or stale; if ads are your plan, get current rates from the networks themselves and model honestly.
Less a model than a delivery mechanism for one of the above: free tier as the top of the funnel, a paywall somewhere in the middle. Where that paywall sits — and how it behaves — is the highest-leverage monetization decision most apps ever make, which is exactly why a whole tool category exists for testing it.
The actual norm: subscription plus lifetime option; free with ads plus paid ad removal. The store rules allow it and mature apps almost all end up here.
The published baseline: Apple's standard commission is 30% of digital-goods revenue, reduced to 15% under the Small Business Program for developers earning under $1M a year — which is nearly everyone reading this. Google Play mirrors the shape: 15% on the first $1M each year. For a small app, plan on 15% plus payment processing being handled for you.
Two boundary rules matter more than the rate. First: digital goods and services consumed in the app must, as the baseline rule, use the store's own billing — you cannot simply drop a Stripe checkout into an iOS app to sell premium features. Physical goods and many real-world services are exempt, which is why shopping apps take cards directly. Second: the boundary itself — external purchase links, "steering" users to your website, web checkout for app content — has been redrawn repeatedly in recent years by courts and regulation, and it differs by region. We are deliberately not printing today's specifics, because they have changed several times and will again; before building a web-checkout flow, read Apple's current rules for your storefronts, not a blog post's memory of them.
The practical takeaway is calmer than the discourse: for a small subscription app, store billing at 15% with the renewal machinery, tax handling and refunds done for you is a reasonable deal, and the infrastructure tools below all work on top of it.
Here is what StoreKit alone does not give you. Server-side receipt validation, so entitlements survive reinstalls and cannot be trivially spoofed. Subscription state that syncs across iOS, Android and web when you expand. Analytics that answer "did the annual plan test win?" rather than "how many transactions occurred?". And — the big one — paywalls you can edit and A/B test remotely, without shipping an app update through review for every price experiment.
You can build all of that yourself on Apple's APIs. Teams did for years. But a category of tools now does it as a product, priced almost identically — free until real revenue, then roughly 1% — which tells you it is a commodity layer you buy, not a differentiator you build.
Why does a guide from a web-platform vendor skip this section? Structurally, it has to: these are native SDKs that drop into an Xcode or Android Studio project, and a platform-hosted app is not one. This is the place where owning a standard native project stops being an abstract virtue and becomes a concrete capability — the entire subscription-tooling ecosystem simply works, the documented way, because your app is the ordinary case it was built for.
Three leaders, verified 30 August 2026. The pricing similarity is the tell — this layer is a commodity you rent, and the choice is about emphasis, not price.
The default choice — subscription state as a service
RevenueCat is the incumbent and the safest default. Its core job: one SDK that wraps StoreKit and Google Play Billing, validates receipts server-side, and turns "what has this user paid for?" into a single API call that answers identically on every platform. Around that core: analytics, charts, integrations with the marketing stack, plus remotely-configurable paywalls and A/B testing.
Its own pricing line is "pay for what you track": free up to $2,500 in monthly tracked revenue, then 1% of tracked revenue above that. The free ceiling is the lowest of the three — and still generous in the only way that matters, since an app doing $2,500 a month has thoroughly proven the tool's keep.
Pricing
Free to $2,500 monthly tracked revenue; 1% of MTR above. Growth tools (paywalls, web-to-app funnels) 1% on conversions they drive. Enterprise custom.
Source: revenuecat.com/pricing, 30 August 2026
Paywall-first, with the most generous general free tier
Adapty sells the same infrastructure with its weight on the paywall itself: a no-code paywall builder with 50+ templates, onboarding flows, A/B testing, and prediction features around them. If your monetization work is mostly "iterate on the paywall until conversion moves" — which for consumer apps it usually is — Adapty's tooling aims at exactly that loop.
Its pricing is the simplest sentence of the three: "Free until you earn at least $5K/month, 1% of monthly revenue after." Nearly the full feature set is in the free tier, so the evaluation costs nothing but integration time.
Pricing
Free until $5K monthly revenue; 1% of monthly revenue after. Enterprise custom.
Source: adapty.io/pricing, 30 August 2026
Paywall experimentation, with infrastructure free at any scale
Superwall began as pure paywall experimentation — treat the paywall as a remotely-served, endlessly testable surface — and has grown into what it now calls "a complete, standalone subscription platform." Its pricing makes the sharpest promise of the three: the subscription infrastructure (entitlements, receipt validation, webhooks, analytics, SQL access to your own data) is free at any scale, and you pay only on paywall-attributed revenue — free to $10K a month of it, then 1% of that revenue alone. Their own words: "revenue the platform didn't help earn is never billed."
That attribution model matters if you are migrating an existing subscriber base or selling meaningfully outside the paywall: the meter only runs on conversions the tool demonstrably drove.
Pricing
Infrastructure free at any scale. Paywall product free to $10K/month paywall-attributed revenue; 1% of paywall-attributed revenue above.
Source: superwall.com/pricing, 30 August 2026
When you need none of them: a paid-up-front app, a single non-consumable unlock, or a pure experiment. StoreKit alone is genuinely fine there, and adding infrastructure before revenue is procrastination with an SDK.
When you need one: the day you run subscriptions you intend to optimise — price tests, paywall placement, win-back offers — or the day Android joins iOS and entitlements must agree across platforms. Which one: RevenueCat as the general default; Adapty if paywall iteration is the job; Superwall if you want infrastructure unmetered and pay only for attributed conversions. At roughly 1% each, the wrong choice among the three costs you little; the wrong choice between "one of these" and "build it yourself" costs you a quarter.
If the app is useful again next month without you shipping anything new to that user — subscriptions fit. If the value is delivered once, a one-time purchase is honest, and honest pricing churns less.
Professionals expense subscriptions and buy lifetime unlocks; consumers tolerate ads and buy consumables. B2B-ish utility apps can charge 10× what consumer apps can, to 100× fewer users.
The paywall belongs after it, not before. Everything upstream of the moment a user first feels the value should be free; everything downstream is negotiable. Finding that line precisely is what the A/B tooling above is for.
Five numbers run every subscription business: conversion to trial, trial-to-paid, churn, ARPU, and LTV — with LTV being the one that funds everything, since what a user is worth over their lifetime is what you can afford to spend acquiring one.
Competing guides print benchmark values for these. We will not, because the honest benchmarks vary by category, price point, platform and country to the point where a single number misleads — and because the tools above show you your own numbers, which are the only ones that matter, from the first paying user. Instrument first; benchmark against your own last month.
There is no category-independent answer, and any guide giving one is selling something. The dominant pattern for apps whose value renews is freemium with subscriptions — free tier, paywall after the moment of first value, monthly and annual prices. For deliver-once value, one-time purchases are more honest and churn-free. Most mature apps end up hybrid. The three questions in this guide — does value renew, who is the customer, where is the aha moment — settle it faster than any benchmark.
Both are processed by the stores’ billing systems. A subscription renews automatically until cancelled — recurring revenue, renewal machinery handled by Apple and Google. An in-app purchase is one transaction: consumable (usable up: credits, exports) or non-consumable (permanent: pro unlock, lifetime access). The commission rules are broadly the same; the business difference is that subscriptions compound and churn, purchases spike and stop.
Apple: 30% standard, 15% under the Small Business Program for developers earning below $1M/year. Google Play: 15% on the first $1M each year. For a small app, plan on 15%. The rules for routing around store billing via external links or web checkout have changed repeatedly by region and continue to — read the stores’ current rules rather than any article’s summary, including this one’s.
RevenueCat wraps Apple and Google billing in one SDK: server-side receipt validation, cross-platform subscription state, analytics, and remotely-testable paywalls. You do not need it for a one-time unlock or an experiment — StoreKit alone is fine. You want it (or Adapty, or Superwall) the day you run subscriptions seriously: it is free until $2,500 of monthly tracked revenue, then 1%, which is cheaper than building receipt validation yourself by roughly the cost of a quarter.
The screen where a free user meets the paid offer. Hard paywalls block everything behind payment; soft paywalls let users feel the product first. Placement is the highest-leverage monetization decision most apps make, and the working answer is: after the moment a user first experiences the value, not before. Tools like Superwall and Adapty exist to move and restyle the paywall remotely and A/B test it without shipping an app-review update per experiment.
For digital goods consumed in the app — premium features, content, credits — the baseline rule remains that store billing is required, so a plain Stripe checkout in an iOS app is not compliant for those. Physical goods and many real-world services are exempt, which is why commerce apps charge cards directly. The external-link and web-checkout exceptions differ by region and have been redrawn several times recently; check Apple’s current rules for your storefronts before designing around them.
It depends entirely on what the builder outputs, which is the quiet monetization argument for owning native code. A Modaal project is a standard Xcode project, so StoreKit, RevenueCat, Adapty and Superwall integrate the ordinary documented way. A platform-hosted app can only offer the billing its platform built in, and a wrapped web app selling digital goods still has to route through store billing — from inside a container these SDKs were not designed for. Ask any builder vendor this exact question before committing: "how do I add RevenueCat?"
Build for as long as you want on the Free plan. Only upgrade when you're ready to launch.
The other side of the ledger, every number checkable.
The build process this article assumes.
Including which outputs can actually run these SDKs.
Monetization is one of the places the answer changes.