Comparison · vendor pricing and SDK pages read 23 September 2026
Paywall tools for iOS and Android: what each one adds on top of the store, and what it costs
A paywall is two things: a transaction, which the App Store and Google Play own, and a screen with an experiment behind it, which is where the tools compete. This page is for the product manager or founder deciding whether to add one: the baseline every app has for free, six tools on their published free thresholds, fees and SDK coverage, the questions that decide whether you need a vendor at all, and how to write one paywall spec that ships on both platforms.
Verified
The baseline, before any tool. On iPhone, in-app purchases and subscriptions go through Apple’s StoreKit 2; on Android, through the Google Play Billing Library. The store handles the payment, the receipt, renewals, refunds, family sharing and the tax; the store takes its commission, published on each store’s developer pages; and the app gets an entitlement — this user has paid for this — to check. A native app on both platforms has all of that with no vendor, and the decision of what to charge for is on how to monetize your mobile app.
What a paywall tool adds. Three things product people actually buy: one server that knows, across iOS and Android and web, who is subscribed (so a user who paid on an iPhone is subscribed on their Android tablet); a paywall screen that can be changed and A/B tested from a dashboard without an app release and a review; and revenue analytics — trials, conversions, churn, cohorts — that the two store consoles report differently. The tools below sell those three in different mixes; they differ in free thresholds, fees, and which SDKs they publish.
The six tools on their published numbers
RevenueCat. Free up to $2,500 of monthly tracked revenue, then 1% of tracked revenue. Its installation documentation lists SDKs for iOS and Apple platforms, Android, React Native, Expo, Flutter, Kotlin Multiplatform, Cordova, Capacitor, Unity, Web and Roku — the longest published list of the six. The entitlement server is the core product, with paywalls and experiments added on top.
Adapty. Free until $5,000 per month, then 1%. SDKs for iOS, Android, Flutter, React Native, Unity, and web via Stripe and Paddle — the web SDK names its payment processors, which matters if the product has a web checkout beside the stores.
Superwall. Free up to $10,000 per month of paywall-attributed revenue, then 1% — note the qualifier: the threshold counts revenue its paywalls produced, not all revenue. SDKs for iOS, Android, React Native, Flutter, Expo, Unity, and web. Its product is the paywall screen and the experiment first; it is often used with a separate entitlement server.
Qonversion. Free up to $7,000 of monthly tracked revenue, then 0.8% — the lowest published percentage of the six. iOS, Android, and web.
Apphud. Its pricing page, on 23 September 2026, shows two statements that do not agree: a free tier for apps under $10,000 per month, and a Pro plan at $49 per month described as free until $1,000 of monthly tracked revenue. This page does not resolve that; confirm with the vendor before budgeting.
Purchasely. Quote-based; no price is published. Not stated.
FreemiumKit is omitted because its page could not be read on the verification date.
Three questions before you add a vendor
Do you sell on more than one platform, or on web too? If the product is iPhone only and will stay so, StoreKit 2 already gives you subscription status, and Apple’s own dashboards give you the basic revenue view; a vendor is a convenience. The moment there is an Android app or a web checkout, one entitlement server that knows every user is the reason to add one — and it is the reason to look at the SDK column, not the fee column, first.
Will you change the paywall more often than you release the app? A paywall edit is normally an app update through App Review and a Play release. A tool that serves the paywall from a dashboard turns that into a same-day change and a controlled experiment. If the plan is to test price points, trial lengths and copy monthly, that capability is the product; if the paywall will be set once, it is not.
What is the fee at your expected revenue? Every listed tool is free below a threshold and takes a percentage above it; the thresholds run from $2,500 to $10,000 a month and the percentages from 0.8% to 1%, on the read date. Compute the fee at twelve months of your forecast, not at zero; the free tier is where every product starts, and the percentage is what it pays if the product works.
One paywall spec for both stores
The paywall is a product decision made once and implemented twice — natively on each platform, or once through a vendor’s SDK on both. The spec that makes either implementation unambiguous is short:
Products: the list of things for sale with one identifier each, identical on App Store Connect and the Play Console (a monthly, an annual, a lifetime). Entitlements: what each product unlocks — “pro” — so the app checks entitlements, never products. Trigger: where the paywall appears (after the third saved item; on the locked feature; on day three), and where it must not (never before the first success). Offer: trial length and introductory price, the same on both stores, or the difference stated on purpose. Restore: a “Restore purchases” control, which Apple’s review expects. Copy: the price shown in the user’s currency as the store returns it, never typed by hand.
That spec is a section of the one-page PRD. In a tool that builds both platforms from one project — in Modaal, the paywall’s state and actions are written once and the iPhone app renders the screen in SwiftUI while the Android app renders it in Jetpack Compose — the spec produces both implementations, and adding a vendor is a decision about the SDK, not a second project. Modaal for product managers has the loop.
What Apple’s review checks on a paywall
The paywall is a spec item in Apple’s guidelines, not a design taste. Guideline 3.1.1: “you should make sure you have a restore mechanism for any restorable in-app purchases.” Guideline 3.1.2(c): “Before asking a customer to subscribe, you should clearly describe what the user will get for the price. How many issues per month? How much cloud storage? What kind of access to your service?” And for a time-based trial in a non-subscription app: “Prior to the start of the trial, your app must clearly identify its duration, the content or services that will no longer be accessible when the trial ends, and any downstream charges the user would need to pay for full functionality.” Digital content is sold through the store’s own purchase system. Google Play’s subscription policies cover the same ground in their own wording. The full list of review reasons is on App Store rejection reasons. A vendor’s paywall templates are built for those rules; a paywall built from scratch should carry them as acceptance criteria.
Six paywall tools — published fees and SDKs, 23 September 2026
| Tool | Free up to | Then | SDKs published | Notes |
|---|---|---|---|---|
| RevenueCat | $2,500 monthly tracked revenue | 1% of tracked revenue | iOS/Apple, Android, React Native, Expo, Flutter, Kotlin Multiplatform, Cordova, Capacitor, Unity, Web, Roku | Entitlement server first; paywalls and experiments on top |
| Adapty | $5,000 / month | 1% | iOS, Android, Flutter, React Native, Unity, web (Stripe, Paddle) | Web via Stripe and Paddle |
| Superwall | $10,000 / month paywall-attributed | 1% | iOS, Android, React Native, Flutter, Expo, Unity, Web | Threshold counts paywall-attributed revenue only |
| Qonversion | $7,000 monthly tracked revenue | 0.8% | iOS, Android, web | Lowest published percentage |
| Apphud | Page inconsistent (see text) | Page inconsistent | Not verified for this page | Confirm with the vendor |
| Purchasely | Not stated | Quote-based | Not stated | No public pricing |
From each vendor’s pricing and SDK pages as read on 23 September 2026. Thresholds and percentages change; check the vendor page on the day you decide. FreemiumKit omitted (page not readable on the read date).
Frequently asked questions
No. StoreKit 2 on iOS and the Google Play Billing Library on Android handle the purchase, renewal, refund and receipt, and give the app an entitlement to check. A paywall tool adds a cross-platform entitlement server, a paywall you can change and A/B test without a release, and unified revenue analytics. It is a convenience for one platform and close to a requirement once there are two, or a web checkout.
RevenueCat, Adapty, Superwall and Qonversion publish iOS and Android SDKs, as read on 23 September 2026; all four also publish web SDKs, and RevenueCat, Adapty and Superwall publish SDKs for the cross-platform frameworks. Apphud’s and Purchasely’s SDK pages were not verified for this page.
On the read date: RevenueCat free up to $2,500 monthly tracked revenue then 1%; Adapty free until $5,000 a month then 1%; Superwall free up to $10,000 a month of paywall-attributed revenue then 1%; Qonversion free up to $7,000 then 0.8%; Apphud’s page shows two statements that do not agree; Purchasely is quote-based. The store’s own commission applies in every case and is published on each store’s developer pages.
That is the main thing the tools sell: the paywall is served from the vendor’s dashboard, so price points, trial lengths, layout and copy can be changed and split-tested without App Review or a Play release. Without a tool, every paywall change is an app update.
Products with one identifier each, identical on both stores; the entitlements each product unlocks; the trigger — where the paywall appears and where it must not; the offer, with trial and introductory price stated for both stores; a restore-purchases control; and prices displayed as the store returns them. Six items, one section of the PRD.
Apple’s guidelines make three paywall items explicit: a restore mechanism for restorable purchases (3.1.1), a clear description of what the user gets for the price before they subscribe (3.1.2(c)), and, for a time-based trial, its duration, what stops being accessible when it ends and any charges after it. Digital content is sold through the store’s own purchase system. App Store rejection reasons lists the review reasons with the guideline text.
The store subscription belongs to the store, not the tool, so the users’ purchases survive a switch; what moves is the entitlement mapping, the paywall screens and the analytics history. Keep product identifiers and entitlement names in your own spec rather than only in a vendor dashboard, and the switch is an SDK change.
The decision is one; the implementation is two native screens, or one vendor SDK integrated on both. In a builder that writes each feature once and renders it natively on iPhone and Android, the paywall spec produces both screens from the same project; adding a vendor is then a choice about the SDK, not a second project.
One paywall spec, two native apps
Write the products, entitlements and trigger once; Modaal builds the SwiftUI and Jetpack Compose screens from the same project, with StoreKit 2 and Play Billing or the vendor SDK you choose. Free for one project; Pro adds both platforms and TestFlight.
Keep reading
- How to monetize your mobile app
The model decision before the paywall.
- The PRD prompt
Where the paywall spec goes.
- App Store rejection reasons
What review reads on a paywall.
- Best native app builders
Four questions that settle “native”.
- Modaal for product managers
How a PRD becomes the build.