You picked a subscription model for your app. You set up products in App Store Connect. Then you discovered that Apple and Google handle the payment transaction, but everything above that layer is your problem: servers, databases, receipt validation, cross-platform state syncing, and entitlement checks.
RevenueCat is the most common answer to that problem, but it is not always the right one. Combined App Store and Google Play consumer spending grew 6.7% year-over-year in Q3 2025, so the subscription model is working. The real decision is how much infrastructure you want to own to support it.
What RevenueCat actually does
RevenueCat is a subscription backend-as-a-service. It sits between your app and Apple or Google's payment systems, handling receipt validation, subscription state tracking, and entitlement management so you do not build that infrastructure yourself.
Most indie builders do not struggle with charging a card. They struggle with everything that happens after the purchase. RevenueCat handles much of that subscription infrastructure, but some responsibilities still stay on your side.
Receipt validation and entitlements
The most common integration path for indie builders is straightforward. You use the RevenueCat Purchases SDK on the client side, and their servers handle everything else.
Entitlements are the access levels users earn when they purchase. Instead of checking platform-specific product IDs that differ between iOS and Android, your code checks a single named entitlement like "pro". Entitlements decouple app code from platform-specific SKU strings, and most apps need only one.
Cross-platform subscription syncing
When a user subscribes on iOS and opens your Android app, RevenueCat's backend has already tracked the renewal, grace period, and expiration state. The result is a single property check instead of separate platform logic.
Remote paywalls and A/B testing
RevenueCat's Paywall SDK lets you configure your entire paywall view from a dashboard. Changes deploy remotely with no app store update required. You can run A/B tests on pricing, copy, and structure without resubmitting your app, which native platform tools do not support out of the box.
What RevenueCat does not replace
You still create and configure products in App Store Connect and Google Play Console. Apple and Google still process the actual financial transaction. RevenueCat provides paywall templates, but your app's core UI and UX remain yours to build.
When you actually need it
RevenueCat makes sense when cross-platform state, backend maintenance, or remote paywall control becomes expensive to own. That is what separates a useful abstraction from one more tool to manage.
Three factors shape the decision:
- how many platforms you support
- whether you want to maintain a backend
- how much you value remote configuration
Strong reasons to use RevenueCat
You are building for both iOS and Android. One developer chose RevenueCat because the native in_app_purchase Flutter package does not provide subscription state tracking infrastructure.
You do not want to build or maintain a backend. One developer abandoned a DIY approach after encountering the complexity of subscription plans, cancellations, cross-device sync, trials, and upgrade paths.
You want to iterate on your paywall without app store reviews. Remote paywall configuration and A/B testing are valuable if conversion optimization matters to your business. Changing pricing or copy without a full app update cycle saves time on each experiment.
You are using a cross-platform framework. Developer complaints about Google Play Billing appear in developer discussions, which suggests that a managed service may absorb some of that pain.
If several of these apply to you, RevenueCat is probably solving real complexity in your stack rather than adding optional tooling.
When native StoreKit 2 is enough
StoreKit 2 changes the tradeoff for small iOS apps. If you are iOS-only and your purchase logic is simple, native tooling may be enough without adding another dependency.
One developer who had used RevenueCat concluded that StoreKit 2 is more than enough for small indie apps. Subscriptions, one-time purchases, and restore flows are all buildable without adding another dependency and another dashboard to manage. StoreKit 2 now includes SwiftUI purchase views that require minimal code, and the framework handles receipt validation format changes automatically.
Skip RevenueCat if all three of these apply:
- You are iOS-only with a simple subscription model
- You are technically capable of handling billing edge cases
- You do not need remote paywall configuration or analytics dashboards
If that list fits your app, RevenueCat is more likely to be optional than necessary. One developer open-sourced a wrapper specifically to avoid RevenueCat's fee, noting that fees compound on top of Apple's existing store cut.
What RevenueCat costs in practice
RevenueCat offers a Pro plan and an Enterprise plan, with all figures drawn from the pricing page. The Pro plan is free to $2,500 in monthly tracked revenue (MTR). Above that threshold, RevenueCat charges 1% of tracked revenue above the threshold, and no charges apply in months when you stay below $2,500. MTR is measured on gross revenue, before Apple's or Google's fee is deducted.
One detail worth knowing before you commit: webhooks are a Pro feature, not a free-tier one. If you plan to sync subscription events to your own backend, CRM, or analytics stack, that requirement shapes when you cross into paid usage.
Alternatives worth evaluating
The alternatives split into two buckets: native tools and managed subscription infrastructure. Comparing them by scope rather than by marketing language makes the choice easier.
Native tools work best for iOS-only apps with simple subscription models. No vendor fee applies, but you lose cross-platform abstraction, analytics dashboards, and remote paywall configuration.
Managed subscription infrastructure is worth comparing if you want receipt handling, subscription state tracking, and remote paywall control without building those systems yourself.
That comparison narrows the field quickly. If you need receipt handling and subscription state, compare full-stack tools. If you only want better paywalls, focus on whether you actually need the backend layer underneath them.
Integration realities people do not warn you about
The hard part is usually not the SDK code. The hard part is understanding the product model, surviving sandbox testing, and getting identity decisions right early. Integration mistakes create confusing bugs that look like billing failures, and most launch delays come from product mapping, sandbox quirks, and identity mistakes, not from writing SDK calls.
The mental model matters more than the code
RevenueCat's model has three layers:
- Products, defined in App Store Connect or Google Play Console
- Offerings, grouped in RevenueCat's dashboard
- Entitlements, which define what access the user receives
That model is simple once it is explicit. Map the full chain on paper before opening your IDE.
Sandbox testing takes longer than integration
Developer reports describe sandbox errors during setup and products that load in debug mode but fail in TestFlight. Sandbox timelines run on accelerated renewal cycles, which is Apple's design, not a bug.
Three practical steps reduce friction:
- Complete all App Store Connect financial and tax setup before any sandbox testing on physical hardware
- Set the StoreKit Configuration under Xcode Scheme Options to None for physical device testing
- Enable debug logs during development and use sandbox testing settings in RevenueCat's dashboard
These steps will not remove every issue, but they do cut down common setup mistakes.
Identity management decisions compound
Add RevenueCat's logIn and logOut methods from day one. Retrofitting identity management after launch creates duplicate subscriber records and inflated dashboard counts, with users reporting anonymous ID creation, restore behavior, and duplicate accounts around logout and restore flows.
RevenueCat with visual app builders
Integration gets harder when you are not writing native code. Tooling maturity varies across visual app builders, so support on paper does not always mean an easy setup in practice. Documented paths vary, and some setups may take longer to debug than native SDK work.
For builders using visual tools, check for a documented RevenueCat path before you commit to your billing architecture. Also confirm device-testing limits, preview limits, and app store compliance requirements early.
Making the call for your app
The decision is usually simple once you strip away the tooling noise. Use RevenueCat when subscription infrastructure is taking time away from product work. Skip it when native tools already cover your real needs.
For builders below $2,500 in monthly revenue, RevenueCat's free tier removes software cost from the equation. The real decision is whether you want to spend time on subscription infrastructure or on your product. If you are cross-platform, managed options are worth considering. If you are iOS-only with a simple model and technical confidence, native StoreKit 2 is viable. If you are pre-revenue, starting with the free tier keeps the cost question off the table until fees become meaningful.
Pick your monetization model, validate it with real users, and choose the subscription tooling that matches your current stage. You can always migrate later. Start by building the app itself, then wire up payments with the subscription layer that fits.
