App Monetisation Platforms: Subscriptions, Paywalls & Ads Compared

App monetisation tooling is not one market — it is three jobs, each with its own platforms: subscription and IAP infrastructure, paywall experimentation, and ad mediation. The moment you sort the landscape by job rather than by brand name, the buying decision stops being a popularity contest and becomes a matter of which gap you actually need to close. Teams overspend here for the same reason they overspend on any tooling: they shop by category label instead of by the question each platform answers.

The three jobs are genuinely distinct. Subscription and IAP infrastructure handles the plumbing of taking money — validating receipts, managing renewals and entitlements across iOS and Android, and surviving refunds, grace periods and billing retries. Paywall experimentation is a separate discipline: it decides what the user sees at the moment of the ask, and how fast you can test a new price, layout or offer without shipping an app update. Ad mediation is a different business model entirely — it auctions each impression across competing demand sources to lift your effective CPM. One app might need all three; many need only one.

Conflating them is where money leaks. A team that "needs better monetisation" buys a subscription platform when their real bottleneck was paywall conversion, or layers an ad network on a premium app where ads would erode the very experience users pay for. The category lens forces the right question first — are you taking money for content (subscriptions), optimising the ask (paywalls), or selling attention (ads)? — and only then which platform fits.

Across our 300+ apps managed since 2013, the most common monetisation audit finding is not that a team picked the wrong vendor; it is that they bought a platform for a job they did not yet have. This guide is vendor-neutral on purpose: it names the real platforms in each category, gives a free-or-cheap starting option for every one, and treats every price as a range to verify rather than a quote, because monetisation pricing changes constantly. For the strategy that sits above the tooling, our app monetisation playbook is the companion read; this post is specifically about the platforms.

The subscription and IAP infrastructure category has two real options: build directly on the native billing APIs — Apple's StoreKit and Google Play Billing — or buy a cross-platform layer such as RevenueCat, Adapty or Glassfy that wraps both behind one SDK with server-side entitlement and analytics. The native APIs are free; the platforms charge a small percentage of revenue above a free tier in exchange for the engineering you no longer have to own.

The native layer is the foundation everything else sits on. Apple's StoreKit and Google Play Billing are fully capable of running a subscription business on their own — they handle the purchase, the renewal and the platform's own receipt. What they do not give you for free is the hard part: a unified entitlement that says "this user is premium" regardless of whether they bought on iOS or Android, server-side validation that survives a reinstall, and the renewal, grace-period and refund webhooks stitched into clean revenue analytics. That is exactly the work the platforms package up.

• RevenueCat: the most widely adopted layer — one SDK for StoreKit and Play Billing, server-side entitlements, subscriber analytics and a paywall builder. Commonly cited as free up to around $2,500/mo of tracked revenue, then a small percentage above it (check current pricing — the tier and rate move).
• Adapty: a close competitor with a strong emphasis on paywall A/B testing and price experiments alongside the billing infrastructure; priced similarly on a tracked-revenue model with a free starting tier.
• Glassfy: a lighter-weight entrant in the same space, useful for teams who want the cross-platform entitlement wrapper without the heavier analytics suite. Verify its current tiers before committing.
• Native StoreKit / Play Billing: zero platform fee, maximum control, maximum engineering ownership — the right call when your billing logic is simple or your team wants no third-party in the revenue path.

The honest framing we give clients is that this category is not about features on a comparison grid — every one of these platforms can take a recurring payment. It is about who owns the edge cases. In our portfolio, the apps that build native and skimp on receipt validation are the ones that later discover a quiet refund or restore-purchases bug that has been silently leaking revenue for months. Whichever you choose, the monetisation infrastructure has to be treated as load-bearing, not as something to bolt on after launch.

Paywall experimentation is a distinct category from billing infrastructure, and the standout dedicated platform is Superwall — built so you can change paywall design, copy, pricing and offers remotely and A/B test them without shipping an app update; RevenueCat and Adapty also ship capable paywall builders inside their billing products. The value of this category is speed: the paywall is the single highest-leverage screen in a subscription app, and the team that can test it weekly will out-earn the team that can only change it on the next release.

The case for a dedicated paywall layer rests on iteration velocity. If your paywall is hard-coded in the app, every test is gated by an app-store review cycle and your slowest user's update cadence — which means a few experiments a year. A remote-config paywall platform decouples the paywall from the binary: you author variants server-side, target them by cohort, and read conversion in near real time. Superwall is the best-known pure-play here, priced on a usage model (broadly tied to conversions or active users — check current pricing). The platforms in the billing category — RevenueCat and Adapty — fold paywall testing into their suites, which for many teams removes the need for a separate tool entirely.

The discipline that makes this category pay is knowing what to test and what "good" looks like. Paywall conversion is sensitive to a handful of high-leverage variables — the offer framing, the trial-versus-no-trial decision, annual-versus-monthly default, and the social-proof and value-recap copy above the buttons. We document the realistic numbers and the test sequence in our paywall optimisation benchmarks, and the broader trial mechanics in the playbook. The platform only gives you the lever; the experiment design is what moves revenue.

One caution we give before any team buys a dedicated paywall tool: it is genuinely worth it only once you have the install volume to reach statistical significance on a test within a reasonable window. We have seen pre-revenue apps buy a paywall platform and then run "tests" on a few hundred views a month that never reach significance — paying for an experimentation engine they cannot yet feed. If your billing platform already ships a paywall builder and your volume is modest, start there and add a specialist tool when test velocity is the actual constraint.

Ad monetisation is a separate category built on two layers — a mediation platform that auctions each impression across competing demand, and the ad networks that supply that demand — and the dominant mediation platforms are AppLovin MAX, Google AdMob and Unity LevelPlay (which absorbed ironSource), all free to use because they earn on the ad revenue flowing through them. Mediation is the lever most ad-funded apps underuse: a single network leaves money on the table, while a properly configured auction across several demand sources routinely lifts effective CPM by double digits at no licence cost.

The mechanism is the reason to care. Without mediation you sell each impression to one network at whatever it offers. With mediation — increasingly run as a unified or in-app bidding auction rather than a manual waterfall — every impression is contested by multiple networks in real time, and the highest bid wins. The three platforms differ in emphasis but share the model:

• AppLovin MAX: a leading in-app-bidding mediation platform with broad demand and strong reporting; documented in the AppLovin MAX developer docs. Popular with gaming and high-volume apps.
• Google AdMob: Google's mediation and network combined, with deep Google demand and the easiest path if you already run Firebase and Google App Campaigns; see the AdMob mediation documentation. A strong default for most non-gaming apps.
• Unity LevelPlay (with ironSource): after Unity's merger with ironSource, LevelPlay is the combined mediation stack, strongest in the games ecosystem where Unity already lives.

The networks themselves — AppLovin, Unity Ads, Meta Audience Network, Google's demand, and a long tail of others — are the demand sources you plug into whichever mediation platform you pick. The practical rule is that the mediation platform is the decision that matters; the networks are connectors you add to thicken the auction. In our portfolio, the ad-funded apps that treat mediation as set-and-forget routinely run a single demand source and wonder why their CPM lags the category, when adding two or three competing networks to the auction would have lifted it for free.

Build natively when your billing is simple, your team wants no third party in the revenue path, and you can own receipt validation and entitlement properly; buy a platform when cross-platform entitlement, renewal edge-cases and subscriber analytics would otherwise consume engineering time you would rather spend on the product. This is the single most consequential decision in the subscription category, and it deserves more than a feature comparison — which is why we wrote a dedicated StoreKit vs RevenueCat comparison that works the trade-off in full.

The case for building native is real and often underrated. The native APIs are free, fully documented, and remove a percentage-of-revenue fee that grows with your success — a platform taking even a low single-digit percentage of tracked revenue becomes a meaningful line item at scale. You also keep every byte of payment data first-party and avoid a third-party SDK in the most sensitive path in your app. For a single-platform app with one or two simple subscription products, native is frequently the correct, cheaper answer.

The case for buying is about where engineering time actually goes. The hard part of subscriptions is not the purchase — it is everything after: validating receipts server-side so a reinstall does not lose entitlement, reconciling renewals and cancellations from Apple's and Google's server notifications, handling billing-retry and grace periods so a failed charge does not instantly churn a paying user, and presenting one unified "is this user premium?" answer across iOS, Android and web. A platform packages all of that into one SDK and a webhook feed, and the percentage fee is the price of not building and maintaining it yourself.

The decision rule we use with clients is a question, not a preference: would the engineering time to build and maintain robust cross-platform entitlement cost you more than the platform fee at your revenue? Below a certain scale the answer is usually no, and native wins. Above it — especially once you are on both platforms with non-trivial subscription logic — the platform fee is cheaper than the salaried hours and the revenue lost to edge-case bugs. We have seen both calls be correct for different apps in the same quarter; the mistake is treating it as ideology rather than arithmetic.

Pick by two axes at once — your monetisation model (subscription, ads, or hybrid) decides the category, and your stage (pre-revenue, scaling, or mature) decides whether you run the free option or pay for the platform. The wrong way to choose is to copy whatever a successful app in a different model and stage uses; the right way is to locate yourself on both axes and read off the fit.

By app type, the mapping is clean. A content or utility app charging for access is a subscription app — its category is billing infrastructure plus, eventually, paywall experimentation. A casual game or free utility funded by attention is an ad app — its category is mediation. A growing number of apps, especially in India, are hybrid: a subscription tier for power users and ads for everyone else, which means you run both categories and the join between them becomes the real work.

• Subscription app, pre-revenue: native StoreKit/Play Billing or a free subscription tier (RevenueCat's free band). Do not pay yet.
• Subscription app, scaling: a billing platform whose free tier you have outgrown, plus paywall experimentation once conversion is the bottleneck.
• Ad app, any stage: a mediation platform (AppLovin MAX, AdMob or LevelPlay) from day one — it is free, and a single network from the start is leaving CPM on the table.
• Hybrid app: a subscription platform and a mediation platform, with analytics that can tell you whether a user is worth more as a subscriber or as ad inventory.

By stage, the principle is that you should never pay for a percentage-of-revenue or volume-priced platform before you have the revenue or volume to justify it. The free tiers exist precisely so a pre-revenue app can ship a complete monetisation stack for nothing. Across our portfolio, the apps that scale cleanly almost all start on a free or native setup and add a paid platform only when a specific limitation bites — which is the upgrade logic the next sections make concrete.

Every monetisation category has a genuinely free or free-to-start option, so a pre-revenue app can run a complete stack for nothing: native StoreKit and Play Billing (or a subscription platform's free tier) for billing, a billing platform's built-in paywall builder for experimentation, and AppLovin MAX, AdMob or LevelPlay for ad mediation — all free until real scale arrives. You do not need to spend a rupee on monetisation tooling to ship a fully monetised app.

Here is the free-first starter, category by category, that we would hand an early-stage team:

• Subscription / IAP infrastructure: build on native StoreKit and Play Billing for zero fee, or adopt RevenueCat's free tier (commonly cited up to around $2,500/mo tracked revenue — check current pricing) to skip the entitlement engineering while you are still small.
• Paywall experimentation: use the paywall builder already bundled in RevenueCat or Adapty rather than buying a dedicated tool — free with the platform, and enough to run your first meaningful tests once volume allows.
• Ad mediation: AppLovin MAX, AdMob or Unity LevelPlay are all free to use, because they earn on the ad spend flowing through them. Start with one and add demand sources to the auction over time.

The total fixed software cost of that stack is zero — every platform here is either free outright or free below a revenue or volume threshold you have not yet crossed. What you pay instead is attention: wiring the billing platform's analytics to your product analytics so you can see revenue by cohort, and configuring the mediation auction with more than one network so your CPM is competitive from the start.

The point is not that free tools match paid depth — it is that for an app still proving its loop, depth you cannot act on is depth you should not pay for. In our portfolio, the teams that get monetisation right rarely start by buying; they start by shipping the free stack cleanly, instrumenting it, and letting the data tell them which single category to upgrade first. That sequencing keeps the budget pointed at the product, not at dashboards, until the revenue justifies otherwise.

The cross-platform consideration that matters most is unified entitlement — one authoritative answer to "is this user premium?" that holds whether they bought on iOS, Android or the web, and survives reinstalls and platform switches. This is the single hardest thing to get right with native billing alone, and the main reason teams adopt a subscription platform even when their billing is otherwise simple.

The problem is structural. Apple and Google each run their own billing, their own receipts, and their own server-to-server notifications, and they do not talk to each other. A user who subscribes on their iPhone and later opens your app on an Android tablet must still be recognised as premium — which only works if your server holds a platform-agnostic record of entitlement keyed to the user, not to a single store receipt. Apple's auto-renewable subscriptions and Google Play Billing each expose the signals to build this, but you build it, or you buy a platform that has.

• Entitlement source of truth: keep it server-side and platform-agnostic, never on the device and never tied to one store's receipt. This is the join that makes cross-platform subscriptions work at all.
• Restore purchases: a reinstall or new device must restore entitlement cleanly — a broken restore flow is a support and refund magnet and one of the most common silent revenue leaks we find.
• Web and direct billing: if you sell a subscription on the web to avoid store commission, that entitlement still has to flow into the app, which adds a third billing source to reconcile.

The practical takeaway is that the cross-platform layer is where build-vs-buy is decided in practice. If your app is single-platform with no web tier, native billing carries you fine. The moment you are on iOS and Android — and especially if you add web billing — the entitlement reconciliation is exactly the work a subscription platform exists to remove, and doing it badly yourself is more expensive than the platform fee.

The India lens changes two things: the payment rail and the model. Recurring subscriptions in India run on UPI Autopay e-mandates under the NPCI framework rather than card-on-file, and low ARPU pushes most India-first apps toward a hybrid subscription-plus-ads model instead of pure subscriptions. A monetisation stack that ignores either of these will under-monetise an Indian user base no matter how good the paywall is.

Start with the rail. UPI is now the default way Indians pay, and recurring app billing increasingly runs on UPI Autopay — the NPCI Autopay framework governs the mandate limits, authentication and pre-debit notification rules that decide whether a renewal succeeds. For store-billed subscriptions, Google and Apple handle the UPI integration for you; for web or direct billing outside the store, the UPI Autopay mandate flow becomes your responsibility, and a mandate that fails silently is churn you never see coming. Getting that renewal flow right is as load-bearing as the paywall itself.

Then the model. Indian ARPU is structurally lower than in Western markets, which means a pure-subscription strategy converts a small premium tier and leaves the large free majority entirely unmonetised. The economic answer for most India-first consumer apps is hybrid: a subscription for the willing minority and ad mediation across everyone else. That is why an India-focused stack so often runs both categories at once — a billing platform and an ad mediation platform — with the analytics to decide, per cohort, whether a user is worth more as a subscriber or as ad inventory.

We work through the full hybrid economics — the segmentation, the ad-load that does not poison retention, and the subscription tier that does not cannibalise it — in our guide to hybrid monetisation for apps. The platform implication is simple: an India-first app should assume it will run subscription infrastructure and ad mediation together, and choose platforms in both categories that the team can operate without a dedicated revenue engineer from day one.

Upgrade each category on a specific trigger, never on a calendar — the signal is always the moment the free option stops being able to do a job that is now costing you money to leave undone. Buying ahead of the trigger is how the unused-subscription drawer fills up; here is the upgrade signal for each monetisation category, in the order it usually fires.

• Subscription infrastructure → paid platform tier: upgrade when you cross the free tracked-revenue band and a single billing edge-case — a failed renewal cohort, a cross-platform entitlement bug, a broken restore — would cost more than the platform fee. For native builders, the trigger is the second platform: the moment you ship on both iOS and Android, the entitlement reconciliation often tips the build-vs-buy maths.
• Paywall experimentation → dedicated tool: upgrade when test velocity is the constraint — you have enough paywall views to reach significance quickly and your billing platform's built-in builder can no longer run the volume or sophistication of tests you need. Not before you can feed it.
• Ad mediation → richer auction: there is rarely a paid upgrade here since the platforms are free, but the "upgrade" is operational — add more demand sources and move from a manual waterfall to in-app bidding once impression volume makes a few CPM points material.

Notice the common shape: every trigger is a limitation you can feel and name, not a milestone on a roadmap. If you cannot point to the specific job the free option failed to do this month, you are not ready to pay. Across our portfolio, the apps that upgrade well do it one category at a time, on a trigger they can articulate, slotting a better platform into a working revenue pipeline rather than rebuilding it.

The monetisation categories connect through one shared number — revenue per user by segment — which your billing and ad platforms must both report into the same analytics view so you can see whether a cohort is worth more as a subscriber, as ad inventory, or both; and the two mistakes that wreck this are paying too early and platform lock-in. A monetisation stack is only as good as the join between what each platform measures.

The data flow is the whole point of thinking in categories. Your subscription platform reports revenue and entitlement per user; your ad mediation platform reports ad revenue per user; both have to land in the same analytics layer so you can compare them on a common axis. That is what lets a hybrid app answer the only question that matters — for this cohort, does a subscription paywall or an ad-supported free tier produce more lifetime value? Break that join and you are guessing, optimising one revenue source while blind to whether it cannibalised the other.

Two mistakes cost more than any others:

• Paying too early: buying a percentage-of-revenue subscription platform or a dedicated paywall tool before billing edge-cases or test velocity actually cost you anything. The platform then takes a cut of revenue you could have kept, or sits underused on traffic too thin to test — and the spend crowds out the product work that would have grown the app. Every paid upgrade should follow a limitation you have already hit.
• Platform lock-in: wiring your entitlement logic, paywall config and revenue reporting so tightly to one vendor that switching later means a rewrite. Keep your source-of-truth entitlement on your own server, abstract the platform SDK behind your own interface, and you preserve the option to change vendors as pricing and features move. The convenience of a platform should never become a cost you cannot escape.

The discipline that avoids both is the one this whole guide is built on: sort tooling by job, run the free option until it visibly fails, upgrade one category at a time on a trigger you can name, and keep the entitlement source of truth yours. Do that and your monetisation stack stays lean, your revenue data flows end to end, and you keep the freedom to switch platforms as the market shifts. The single most expensive lock-in is letting a vendor own your entitlement logic, because unwinding it later means re-validating every active subscriber across both stores — so even when you buy a platform, keep a clean record of who is entitled to what on infrastructure you control. If you want a second pair of eyes on which category to upgrade first — or a hybrid stack built and measured properly for an India-first user base — that audit is exactly what our monetisation team runs, and you can talk to us about your specific app.