Should You Use RevenueCat? The Advantages and Disadvantages, Honestly Weighed
A clear-eyed look at RevenueCat in late 2026: what it actually saves you, what the 1% really costs, where the lock-in lives, and a simple rule for deciding whether your app needs it.
Every mobile app that sells a subscription eventually hits the same wall. Apple and Google each have their own purchase APIs, their own receipt formats, their own server notification systems, and their own list of edge cases: grace periods, billing retries, refunds, family sharing, upgrades mid-cycle, restores on a new phone. None of it is hard individually. All of it together is a quarter’s worth of work that has nothing to do with the product you’re trying to build.
RevenueCat exists to make that wall go away. Since 2017 it has been the default answer to “how do I do subscriptions without losing my mind,” and in 2026 it has grown well past receipt validation into paywalls, A/B testing, web checkout, and analytics. That growth is exactly why the decision is less obvious than it used to be. This post lays out the real advantages, the real disadvantages, and a rule for deciding.
What RevenueCat Actually Does
The core product is a server that sits between your app and the stores. Your app sends purchases to RevenueCat (via its SDK or server-side notifications), RevenueCat validates them with Apple, Google, Amazon, Roku, or Stripe, and it hands back a single answer to the only question your app cares about: does this user have the “pro” entitlement right now?
In Flutter, the entire check looks like this:
1
2
3
4
5
6
import 'package:purchases_flutter/purchases_flutter.dart';
Future<bool> hasPro() async {
final info = await Purchases.getCustomerInfo();
return info.entitlements.active.containsKey('pro');
}
That same call works identically on iOS and Android, whether the subscription was bought in the App Store, on Google Play, or on your website through Stripe. The SDK caches the result, so it works offline too. Everything that makes this one line possible is the product.
The Advantages
1. Cross-platform entitlements are a solved problem
This is the headline benefit and it’s genuinely hard to overstate. A user who subscribes on an iPhone and logs in on an Android tablet gets access. A user who buys on your website gets access in the app. You never write code that says “if iOS, check StoreKit; else if Android, check Play Billing; else check Stripe.” RevenueCat maintains one customer record keyed by your app user ID and tells you what’s active.
If you support more than one platform, this alone justifies the product for most teams.
2. The edge cases are handled by people who have seen all of them
Grace periods, billing issues, involuntary churn, refunds, promotional offers, introductory pricing eligibility, subscription group upgrades and downgrades, price-increase consent, family sharing, consumables vs. non-consumables: RevenueCat processes billions of dollars in tracked revenue and has encountered every weird state the stores can produce. When Apple’s receipt server went down for roughly eleven hours in July 2026, RevenueCat granted short-term temporary entitlements so new buyers weren’t locked out, then replayed the purchases when Apple recovered. That’s the kind of thing you don’t think to build until it bites you at 2 a.m.
3. Server-side data without building a server
Webhooks fire on every lifecycle event (initial purchase, renewal, cancellation, billing issue, expiration). Pre-built integrations push events to analytics and marketing tools. Scheduled data exports dump transaction-level data to your own S3 bucket or Google Cloud Storage. The dashboard gives you MRR (Monthly Recurring Revenue), churn, trial conversion, and cohort charts out of the box. For a small team, this is the difference between knowing your numbers and guessing.
4. The growth tooling has become a real product
Remotely configurable paywalls, A/B experiments, a Customer Center for in-app subscription management (cancel, refund request, change plan), and as of the June 2026 launch, hosted web funnels and an AI paywall editor. The paywall editor is component-based with reusable elements, branding presets, and video support. You can change your pricing, layout, or offer without shipping an app update and waiting on review.
5. Web billing with a merchant of record
RevenueCat Web Billing now supports Stripe Billing products and Stripe Managed Payments, where Stripe acts as the merchant of record and handles tax collection and remittance globally. Selling subscriptions on the web (where you avoid the 15% to 30% store cut) used to require stitching together Stripe, a tax provider, and your own entitlement sync. Now it’s part of the same system that already tracks your app purchases.
6. Generous free tier, no feature gating
Everything is free up to $2,500 in monthly tracked revenue, and the free tier includes all features. There’s no “paywalls cost extra” or “webhooks are enterprise only.” A pre-revenue app pays nothing and gets the full product. There’s also an SDK-less integration path if you’d rather keep your own purchase code and just feed RevenueCat server notifications for the analytics and webhooks.
The Disadvantages
1. The 1% is on gross revenue, forever, and it has a cliff
Once you cross $2,500 MTR (Monthly Tracked Revenue), you pay 1% of all tracked revenue, not just the amount above the threshold. RevenueCat’s own FAQ says it plainly: “For $2.5K, we’ll charge you $25.” MTR is measured before the store takes its cut, so you’re paying 1% of a number you never actually receive 15% to 30% of.
| Monthly tracked revenue | RevenueCat fee | Your fee as % of what you actually keep (after 15% store cut) |
|---|---|---|
| $2,499 | $0 | 0% |
| $2,500 | $25 | 1.18% |
| $25,000 | $250 | 1.18% |
| $100,000 | $1,000 | 1.18% |
| $500,000 | $5,000 | 1.18% |
A thousand dollars a month at $100K MTR is not a lot. Five thousand a month at $500K is a mid-level engineer’s salary for a service whose core work (receipt validation) is mostly commodity by that point. Enterprise pricing with volume discounts exists above roughly $500K MTR, but you’ll be negotiating it. If you use RevenueCat’s web funnels on top of Stripe, you pay both the 1% and Stripe’s normal fees.
The honest framing: 1% is cheap when you’re small and an increasingly visible line item as you grow. Plenty of apps at scale decide it’s still worth it. Some don’t.
2. Leaving is harder than joining
RevenueCat’s own migration docs are candid about this. The self-service exports (scheduled transaction exports, audience exports, chart CSVs) do not include Apple original transaction IDs, raw Google Play purchase tokens, or Stripe subscription IDs. Those are the identifiers any replacement system needs to keep validating your active subscriptions. To get them, you open a Support ticket, specify your destination’s import schema, get owner approval, and wait for a Support-prepared file delivered through time-limited access.
That’s not hostile, and people do successfully migrate. But it means you cannot leave on a Friday afternoon. Mitigations if you adopt RevenueCat anyway: always set your own app user ID (never rely on anonymous IDs), and keep a copy of entitlement state in your own database via webhooks so your backend never depends on a live RevenueCat API call.
3. You’ve added a dependency to the money path
RevenueCat has had a dashboard and API outage (October 2025) and inherits every Apple and Google incident on top of its own. The SDK’s offline entitlements and local caching mean existing subscribers keep working during an outage, and purchases queue and retry. But new purchases can’t be validated until the service is back, and if your backend checks entitlements through RevenueCat’s REST API, that path is down too. For most apps this is an acceptable risk. For an app where a purchase failure costs real money per minute, you need to think about it.
4. SDK major versions have broken things
The v9 SDKs moved to Google Play Billing Library 8, which removed the ability to query consumed one-time purchases. The result: lifetime products that had been configured as consumables could no longer be restored, and RevenueCat staff at one point recommended staying on 8.x until a fix shipped. Separately, the React Native 9.x SDK switched its default to StoreKit 2, which silently requires a new App Store Connect configuration key, and purchases simply stopped showing up for people who hadn’t read the migration guide.
None of this is unusual for an SDK that wraps two moving platform APIs. But it’s real work on every major bump, and “the SDK handles it for you” is only true until it doesn’t.
5. Debugging entitlement problems is opaque
The most common technical complaint from developers is some variant of “the user paid, Apple shows an active subscription, RevenueCat says no entitlement, and I can’t tell why.” The customer history view in the dashboard is decent, but when the answer involves sandbox vs. production receipts, a mismatched app user ID, or a product not attached to an entitlement, you’re reasoning about RevenueCat’s internal state rather than your own. Support quality in these moments gets mixed reviews: some teams report fast, excellent help; others report slow email turnaround and inconsistent docs.
6. Paywall and experiment flexibility has limits
The paywall builder has improved enormously, but it’s still a template system. Teams with strong design opinions tend to build their own paywall UI and use RevenueCat only for the purchase and entitlement layer, which is fine but means you’re not getting the remote-config benefit. Third-party comparisons also note that experiments are limited in variant count and weighting compared to a dedicated experimentation platform. Verify those limits against current docs before you plan a serious testing program around them.
7. It’s overkill for simple cases
If you have a single iOS app with one non-consumable “unlock everything” purchase, StoreKit 2 plus Apple’s App Store Server Notifications V2 gets you a signed transaction, a current-entitlements stream, and server-side verification with far less ceremony than it needed in 2020. Adding RevenueCat means another dashboard, another SDK, another account, and another vendor for something you could finish in an afternoon. The same is true for a simple one-time purchase on Android.
When to Use It and When to Skip It
A rule that holds up well:
Use RevenueCat when any of these are true:
- You ship on more than one platform and need shared entitlements
- You sell on the web and in the app and want one customer record
- You have fewer than three engineers and no one wants to own billing infrastructure
- You plan to iterate on pricing and paywalls without app updates
- You’re pre-revenue or under $2,500 MTR (it’s free; the only cost is the lock-in)
Skip it when all of these are true:
- Single platform, single simple product
- You already have a backend and an engineer who’s comfortable with StoreKit 2 or Play Billing
- You have no plans for paywall experiments
- You’d rather own the data than save the time
Re-evaluate when:
- You cross roughly $250K MTR and the fee becomes a visible budget line
- You find yourself building your own paywalls, webhook store, and analytics anyway, which means you’re paying 1% for receipt validation alone
If you adopt it, do three things on day one: set your own app user ID, mirror entitlement state into your own database from webhooks, and configure every lifetime product as a non-consumable. Each of those is five minutes now and a painful week later.
Key Takeaways
- RevenueCat’s core value is cross-platform entitlements and edge-case handling. For multi-platform apps, it’s hard to beat.
- The free tier is genuinely complete up to $2,500 MTR. Above that, it’s 1% of gross tracked revenue with a cliff, not a marginal rate.
- Migration away requires a Support-prepared export of store identifiers. Plan for lock-in before you need to leave.
- The SDK takes major-version bumps seriously; read every migration guide, especially around consumables and StoreKit 2 defaults.
- Single-platform apps with simple products can reasonably use native StoreKit 2 or Play Billing directly in 2026.
- Whatever you choose, own your user IDs and keep a copy of entitlement state in your own backend.