Do You Really Need RevenueCat

If your app sells subscriptions on both iOS and Android, or you expect it to, RevenueCat is probably worth using. Its value isn't the paywall or the dashboard. It's that someone else has already built and keeps maintaining the unglamorous part: working out, reliably and across two stores, what a given customer is entitled to right now. If you ship on one platform, have a single simple product and a backend you're happy to own, you can reasonably skip it. The honest answer sits between those, and it depends on how much subscription logic you want to be responsible for.

What it actually does

RevenueCat sits between your app, your backend and the two stores. Apple and Google each have their own purchase framework, their own receipt or purchase-token model, their own server notifications, and their own opinions about renewals, grace periods, refunds and billing retries. RevenueCat wraps both in one SDK and keeps a server-side record of every customer's purchase history, so your app asks a single question: does this person have access to this thing?

That question is expressed through entitlements. Instead of coding against product identifiers like a monthly plan or an annual plan, you define what a customer is allowed to do, and map any number of store products onto it. Offerings sit alongside that. They are the set of products you currently present to customers, configured remotely, so you can change what's on offer without shipping a new binary and waiting for review.

Behind the SDK, RevenueCat receives the stores' server-to-server notifications, validates purchases, and normalises the lifecycle events. It then forwards those events to your systems through webhooks or integrations with analytics and attribution tools. It also provides a hosted paywall builder, experiments and subscription analytics. These are useful, but they're the shop window. The engine room is receipt handling and state.

How it fits with the app stores

It doesn't replace Apple or Google. Money still flows through the stores, they still take their commission, and your products still need to be created in App Store Connect and Google Play Console. RevenueCat doesn't change the purchase itself. The customer pays Apple or Google exactly as before.

What changes is that your app talks to RevenueCat rather than interpreting store responses directly, and your backend learns about subscription changes from RevenueCat's normalised events rather than from two different notification formats. Think of it as a translation and bookkeeping layer. The stores remain the source of money. RevenueCat becomes the source of truth about who has paid for what.

It also helps when you sell outside the stores. RevenueCat has been extending into web checkout, so a customer who subscribes on your website and later opens the app can be recognised as the same person with the same access. That matters more than it used to, given how much the rules around steering customers to the web have shifted in some regions. Check what applies in the markets you sell into, because the legal detail moves faster than any blog post.

The benefits that matter

The first is fewer ways to be quietly wrong. Subscription state has an enormous number of edge cases: a renewal that fails and enters a grace period, a refund issued weeks later, a family-shared purchase, a customer who restores on a new device, an upgrade mid-cycle, a promotional offer, a sandbox purchase that looks nearly identical to a real one. Each of these is individually manageable. Together they are a long tail of bugs that surface as angry emails from people who paid and can't get in, or worse, people who stopped paying and still can. Neither is a good look, and the first is a trust problem as much as a technical one.

The second is speed. Getting a correct subscription flow working on both platforms from scratch is weeks of work for an experienced developer, and the work doesn't end because the stores keep changing their frameworks. Apple's move to StoreKit 2 and Google's regular revisions to Play Billing are the sort of churn you inherit when you own the integration. Outsourcing that churn is a real saving.

The third is that product and engineering stop competing for the same release train. When offerings and paywalls are configured remotely, a pricing experiment doesn't need a developer or an app review. Whether that's a benefit depends on whether your team will actually run experiments, which is a less certain proposition than it sounds in a planning meeting.

What it costs

At the time of writing, the pricing on RevenueCat's own page is free up to $2,500 of monthly tracked revenue, then 1% of tracked revenue above that, with its paywall and experimentation tooling offered as a separate option. Enterprise customers negotiate their own terms. Verify this before you decide, since pricing pages change.

Two details are worth thinking about. The percentage is calculated on revenue before the stores take their cut, so against what you actually keep it's closer to 1.4% if the store takes 30%. And it's a percentage of success, so the fee grows as the product does. At small scale it's trivially cheap compared with an engineer's time. At large scale it becomes a line item that a finance team will eventually question, and a negotiated enterprise arrangement or an in-house build starts to look sensible.

The other cost is dependency. Your entitlement logic now runs through a third party. If their service is slow or unavailable, your customers feel it. The SDK caches state on the device, which softens short outages, but you should still decide up front what your app does when it can't get an answer. I'd also want a plain answer to how I'd leave. Keep your own record of customer identity and purchase history, and don't let the vendor's data model leak into every corner of your codebase.

So do you really need it?

You don't need it to sell a subscription. Plenty of apps work directly with StoreKit and Play Billing and a small backend, and that's a perfectly respectable path, particularly if you're iOS-only, have one or two products, and have a developer who already understands the lifecycle.

You need it more as your situation gets messier. Two platforms, a website that also sells, a backend that has to know who's subscribed, a marketing team asking for analytics, a product manager wanting to test prices: each of these multiplies the surface you'd have to build and keep correct. At that point, buying the solved version of a problem that isn't your competitive advantage is usually the better commercial decision. Your customers will never thank you for an elegant in-house receipt validator.

The question I'd ask before adopting it is not whether RevenueCat is good. It generally is. The useful question is whether subscription plumbing is something you want to be good at. If your product's value lies elsewhere, and for most apps it does, I'd rather spend the time there.

If you do adopt it, treat it as infrastructure rather than magic. Put a thin layer of your own between your app and the SDK so that swapping it later is an inconvenience rather than a rewrite. Test the ugly paths on purpose: refunds, expired cards, restores, and a customer who changes platform. And decide who owns the answer when someone writes in saying they paid and can't get access, because that conversation will happen eventually. A tool can make that conversation rarer. It can't make it someone else's problem.