Subscription Revenue for Mobile Apps: RevenueCat, StoreKit 2, and What We Learned Shipping 5 Apps in 2025–2026

We've shipped five subscription-based apps over the past eighteen months. Some performed well. One flopped hard. All of them taught us something we couldn't have learned from a blog post.

This is that blog post anyway.

The goal isn't to tell you subscriptions are the future (the market will do that on its own), or to recommend one SDK over another without nuance. The goal is to give you the honest, practitioner-level breakdown we wish we'd had before App #1 went live. If you're about to ship your first subscription app, or your team is debating RevenueCat vs. going native with StoreKit 2, read this before you commit to anything.

---

Why We Went Subscriptions (And Whether We'd Do It Again)

The market case for subscriptions is hard to argue with. Global mobile app subscription revenue is projected to reach $103.5 billion in 2026, with subscriptions accounting for approximately 70% of total app store revenue, according to Statista's 2026 projections. That's not a niche strategy anymore. That's the default.

Our own reasoning was more pragmatic: we wanted recurring revenue that let us plan headcount, fund ongoing development, and not be hostage to launch-day spikes. One-time purchases feel clean, but they create brutal feast-or-famine cycles. Ad-supported models require scale we didn't have.

What we underestimated was the operational overhead. Subscriptions are a relationship, not a transaction. Every week after launch, you're managing renewals, failed payments, cancellation flows, proration logic, and upgrade/downgrade paths. If you're not thinking about all of that before you write a line of code, you'll be rewriting infrastructure under pressure later. We did both.

---

RevenueCat vs. StoreKit 2: The Honest Comparison

By the time we shipped App #3, we had used RevenueCat on two apps and gone native StoreKit 2 on one. Here's what that actually feels like from the inside.

RevenueCat is genuinely excellent for cross-platform apps or teams that want to move fast. Integration is fast, the dashboard is usable from day one, and the abstraction over both App Store and Google Play Billing is worth real engineering hours. According to RevenueCat's State of Subscription Apps Report 2025, the platform managed over 10,000 apps, tracking over $700 million in total revenue and supporting over 15 million subscribers. That scale matters because it means the edge cases are already handled.

The pricing model: RevenueCat offers a free tier for apps generating up to $1,000 in monthly revenue, after which plans scale based on a percentage of revenue, starting at 1% for the "Starter" plan (per RevenueCat's pricing page as of June 2026). For early-stage apps, the free tier is genuinely generous. As you scale, that percentage starts to sting. We won't put a number on how much it stung for us specifically, because your app category and ARPU will make our numbers irrelevant. Run your own projections.

StoreKit 2, going native, is a different proposition. Apple's 2025 updates to StoreKit 2 and the App Store Server API introduced meaningful improvements including better offer code redemption flows and Server-to-Server Notifications v2 for real-time subscription events, per Apple's developer documentation. If you're iOS-only and your team has solid Swift chops, the native path is more capable than it used to be.

The catch is that you own the complexity. Server-side receipt validation, webhook handling, entitlement logic, and all the edge cases around grace periods and billing retries? That's yours to build and maintain. We underbuilt this on App #2. It cost us subscribers we didn't even know we'd lost until we audited three months later.

Our honest take: for a solo developer or two-person team shipping cross-platform, RevenueCat is almost certainly the right call. For a larger iOS-only team with backend resources, native StoreKit 2 is worth serious consideration. The migration from RevenueCat to native (which we attempted partway through App #4) is painful and not worth it unless you have a very specific reason. We didn't have a specific enough reason.

---

Paywall Design and Pricing Experiments

This is where we made the most mistakes, and learned the most.

Industry averages from data.ai's Mobile App Trends Report 2025 put trial-to-paid conversion at 25%, monthly churn at 5%, and Day 30 retention at 40%. ARPU for subscription apps generally ranged from $10 to $30 per month. Across our five apps, we landed in those ranges for most metrics. But the variance between apps was significant enough that "industry average" became almost meaningless for individual decision-making.

What actually moved the needle for us:

Shorter trials converted better in productivity categories, longer trials in lifestyle. A seven-day trial felt urgent enough in task management contexts that users who were going to convert did so before it ended. In a wellness app, users needed the habit to form. We gave them three weeks and saw meaningfully better conversion.

Annual plans deserve upfront prominence. We buried the annual option on three paywalls and featured it on two. The apps where we led with annual pricing had higher ARPU and lower early churn. Users who commit to a year churn at far lower rates. This is not a hot take, but we still buried it anyway because it felt "pushy." It wasn't.

Price anchoring works, but only if the anchored price is believable. Showing a $99.99/year crossed out next to a $59.99 offer only helps if the higher price looks legitimate. App #3 had a paywall that looked like a discount it wasn't. Users noticed. Conversion tanked.

---

Churn, Retention, and the Subscriber Lifecycle

Churn is where subscription businesses quietly bleed out. Monthly 5% churn sounds manageable until you do the compound math over a year.

Our worst churn rates came from apps where we failed on two fronts: weak onboarding that didn't demonstrate value before the trial ended, and no re-engagement for lapsing subscribers. RevenueCat's event hooks made it relatively straightforward to trigger re-engagement flows on subscription cancellation or billing failures. On the native StoreKit 2 app, we had to build that infrastructure ourselves and were six weeks late to it.

Involuntary churn, failed payments specifically, was a bigger source of subscriber loss than intentional cancellations on three of our five apps. This surprised us. App Store and Google Play both have retry logic, but it's not always enough. Building grace period handling properly, and sending timely payment-failure communications, recovered a meaningful portion of users we would have otherwise lost. We won't claim a specific percentage because it varied substantially by app and audience.

One practical thing: if you're using RevenueCat, set up their webhook integrations to your CRM or customer messaging tool on day one, not after you notice churn is high. Retroactively building retention workflows is much harder than starting with them.

---

The Hidden Costs Nobody Warns You About

Let's talk about the parts that don't show up in the tutorial.

App store commissions. Apple and Google both maintain a 15% commission for the first $1 million in revenue under their Small Business Programs, with a reduced 15% rate applying after the first year of a subscription (versus the standard 30% rate), per updated App Store and Google Play developer policies. The mechanics here matter: that first-year reduction applies per subscriber, not per app, and there are eligibility conditions. Model your revenue carefully. Don't assume you'll always be in the small business tier.

Tax and VAT compliance. Apple and Google handle VAT collection in most jurisdictions for payments processed through their stores. But your obligations don't stop there, particularly if you sell through any other channel or have specific business structures. Get a tax professional involved before you're in multiple markets. This is not a corner case. We got a surprise compliance question on App #5 that took weeks to resolve.

RevenueCat's pricing at scale. The free tier is great. The jump into paid plans can be abrupt depending on your growth trajectory. Budget for it, or at least model the crossover point before launch.

Engineering time is not free. The apps where we went native on StoreKit 2 "saved" on RevenueCat fees but cost more in engineering hours than the savings justified, at our team's size and billing rate. Your math may differ. Do the math.

---

What We'd Do Differently

Six things, bluntly:

1. Start with RevenueCat unless you have a concrete reason not to. Migrate later if the math demands it.
2. Design retention workflows before launch, not after churn shows up in your dashboard.
3. Lead with annual pricing on the paywall. Test from there.
4. Instrument your trial flow obsessively. Know exactly where users are dropping off before they convert.
5. Don't guess at tax compliance. Pay for professional advice once rather than paying for mistakes repeatedly.
6. Read your Server-to-Server Notification logs. Seriously. Things fail silently. We found a webhook misconfiguration three months in that had been quietly dropping subscription events.

The subscription model works. The developer survey data from Indie Mobile Dev Insights 2025 confirms the indie community continues to rely heavily on RevenueCat for exactly the reasons we did: comprehensive features, ease of integration, and the peace of mind that comes from not rebuilding solved problems. But "works" doesn't mean "easy." It means there's a reliable path, if you're willing to do the operational work that comes after the SDK is installed.

Five apps later, we're still building subscriptions. We're just a lot less surprised by what that actually involves.