An honest, native-first review of RevenueCat for iOS: what it actually does over StoreKit, where it shines, and the real trade-offs around cost, vendor dependency, and the Apple tools it can't replace.
RevenueCat is a service plus an open-source SDK that sits on top of Apple's StoreKit to make in-app purchases and subscriptions easier to build and operate. Rather than replacing StoreKit, it wraps it: you still declare products in App Store Connect and rely on Apple's payment sheet, but RevenueCat's SDK handles the parts developers repeatedly get wrong, such as receipt validation, entitlement checking, subscription-status tracking, and syncing a user's purchases across devices and platforms. Its backend validates receipts server-side, so your app can ask a single question, "does this user have access?", and get a reliable answer. On top of that sits a dashboard with subscription analytics, cohort retention, and charts that App Store Connect's own reporting does not surface as cleanly. It also offers server-to-server webhooks and integrations that push subscription events into your own systems and third-party analytics tools. For a native Swift or SwiftUI app, RevenueCat is best understood as infrastructure that removes boilerplate and server work, not as an app builder and not as a StoreKit substitute. You are still shipping a fully native app; RevenueCat just owns the entitlement and analytics plumbing behind it.
In a typical native iOS project you configure auto-renewable subscriptions or non-consumable products in App Store Connect, then reference those exact product identifiers inside RevenueCat's dashboard, grouping them into offerings and mapping them to entitlements. The Purchases SDK, added through Swift Package Manager or CocoaPods, is initialized once with your public API key, usually at your App's launch. From then on you fetch offerings to display paywalls, call a purchase method that presents Apple's native payment sheet, and read a CustomerInfo object to see which entitlements are active. Because RevenueCat brokers the StoreKit transaction and validates the resulting receipt on its servers, you avoid hand-rolling receipt parsing or running your own validation backend. The workflow stays recognizably native: Xcode for building, StoreKit for the actual transaction, App Store Connect for product setup and pricing. RevenueCat simply becomes the entitlement authority and analytics layer your app queries. Nothing about the money flow changes: Apple still collects payment, takes its commission, and pays you out, exactly as it would if you called StoreKit directly. What you are outsourcing is the interpretation of purchases, not the transaction itself.
The strongest argument for RevenueCat is the elimination of server-side receipt validation, which is genuinely difficult to build correctly and keep secure. Getting refunds, billing retries, grace periods, upgrades, downgrades, and cross-platform restores right is a real engineering project, and RevenueCat handles those edge cases as a maintained product with a team that tracks Apple's frequent changes. Its entitlement abstraction is elegant: you check whether a user has "pro" access without caring which specific product or platform granted it, which pays off the moment you add Android or web. The analytics dashboard gives founders and product teams retention curves, trials, conversion, and MRR without wiring up their own data pipeline. The SDK is open source under a permissive license, so you can read exactly what runs in your app and audit its behavior. For solo developers and small teams shipping a subscription app, the time saved between a first paywall and a production-grade purchase flow is substantial, often the difference between weeks and days of work. RevenueCat also ships optional paywall tools and A/B testing, so product teams can iterate on pricing presentation from the dashboard rather than through app updates.
RevenueCat does not build, sign, or ship your app. You still need Xcode, an Apple Developer Program membership, and App Store Connect to create products, submit builds, and pass App Review, and RevenueCat cannot shorten Apple's review or replace any of that toolchain. It also introduces a backend dependency: your entitlement checks ultimately rely on RevenueCat's servers, so their availability becomes part of your critical path, though the SDK caches the last known CustomerInfo so a brief outage does not immediately lock out paying users, and Apple still processes the money regardless. Pricing scales with revenue, which means a successful app pays more over time, and past a threshold the paid tier is a recurring cost you would not owe if you validated receipts yourself. There is meaningful overlap with what StoreKit 2 now offers natively, including transaction verification and current-entitlement APIs, so heavier teams may reasonably decide the abstraction is not worth the dependency. Finally, adopting it is a lock-in decision that takes real effort to reverse, because your purchase logic, entitlement checks, and historical analytics all become coupled to RevenueCat's model and data.
RevenueCat uses a free tier plus revenue-based paid pricing, which is the detail that most shapes whether it fits your project. The free tier covers apps up to a monthly tracked-revenue threshold, which is generous enough that many indie apps and early-stage products pay nothing for a long time. Once your app crosses that threshold, you move onto a paid plan whose cost is tied to the revenue flowing through the system, so your bill grows as your subscription income grows. This aligns RevenueCat's incentives with yours, but it also means the tool becomes progressively more expensive precisely as it becomes more valuable, and a high-revenue app could pay a meaningful amount every month. That is the core trade-off to model honestly: you are renting infrastructure whose price rises with your success, versus building and maintaining validation yourself for a fixed engineering cost. Because pricing tiers and thresholds change over time, confirm the current numbers on RevenueCat's official pricing page before committing rather than trusting any figure quoted second-hand. Model your expected revenue against those tiers so the recurring cost is a deliberate decision rather than a surprise line item once you scale.
Since StoreKit 2 arrived, Apple's own framework verifies transactions with signed JWS payloads, exposes current entitlements through Transaction.currentEntitlements, and lets you observe updates through Transaction.updates without a separate server for many apps. This narrows RevenueCat's advantage for single-platform, Apple-only products, and a disciplined team comfortable with async StoreKit APIs can ship subscriptions without any third party. What RevenueCat still adds is cross-platform entitlement sync, a maintained analytics dashboard, server-to-server webhooks for lifecycle events, and handling of the long tail of billing edge cases you would otherwise own forever. It is worth being clear about what StoreKit 2 still does not give you for free: durable purchase history stored off-device, a customer-level view across platforms, and productized retention analytics. The honest calculus is about where you want to spend engineering effort: build and maintain your own validation and analytics, or rent a proven system and accept the dependency and cost. Neither answer is universally correct. Teams that value native control and minimal dependencies may prefer StoreKit 2 directly; teams optimizing for speed, cross-platform reach, and insight often prefer RevenueCat.
RevenueCat is an excellent fit for solo developers and small teams whose main goal is shipping a reliable subscription app quickly, especially anyone planning to expand beyond iOS to Android or web where cross-platform entitlements become a real headache. It also suits product-led teams who want retention and conversion analytics without building a data pipeline, and teams that want to experiment with paywalls and pricing without shipping a new binary for every change. It is a weaker fit for teams with strict no-third-party-dependency policies, apps where every recurring dollar of infrastructure cost matters at scale, or projects that are firmly single-platform and staffed with engineers happy to work directly against StoreKit 2. If your app has minimal purchase logic, such as a single one-time unlock rather than complex subscriptions, the abstraction may be more than you need and native StoreKit could be simpler. The right question is not whether RevenueCat is good, it clearly is, but whether the recurring cost and backend dependency are worth the boilerplate and server work it removes for your specific app and roadmap.
From a studio that builds one hundred percent native Swift and SwiftUI apps, RevenueCat earns a genuine recommendation with clear caveats. It is well engineered, its SDK is open source and pleasant to integrate, and it removes a class of server work that trips up even experienced developers. It does not compromise the native feel of your app, since Apple's payment sheet and StoreKit still do the actual work underneath and the user never sees a third party. The caveats are equally real: it is a paid dependency whose cost rises with your success, it puts a third party in your entitlement path, and it overlaps with capabilities StoreKit 2 now offers for free. Treat the decision as an architecture choice, not a default you reach for reflexively. If you value shipping speed, cross-platform reach, and analytics, adopt it deliberately and design your code so entitlement checks are centralized enough to swap later. If you value minimal dependencies and full native control, StoreKit 2 is a legitimate, no-cost alternative worth serious consideration. Both are defensible; the wrong move is choosing without weighing the trade-off.
No. You still create your subscription and IAP products in App Store Connect, build and submit your app with Xcode, and maintain an Apple Developer Program membership. RevenueCat references the products you configure in App Store Connect; it does not build, sign, or distribute your app.
It has a free tier that covers apps below a monthly tracked-revenue threshold, which is enough for many indie and early-stage apps to pay nothing. Above that threshold you move to revenue-based paid pricing, so your cost grows with your subscription income. Check the official pricing page for current thresholds.
Yes. RevenueCat wraps StoreKit rather than replacing it. Apple's StoreKit still presents the payment sheet and processes the transaction; RevenueCat validates the resulting receipt on its backend and exposes entitlement status through its SDK.
You can, but it takes effort. Because your entitlement checks and analytics depend on RevenueCat's SDK and backend, migrating to raw StoreKit 2 or another provider means rewriting purchase and entitlement logic and re-establishing subscription state. Treat adoption as a deliberate architecture decision.
It depends on your needs. StoreKit 2 now verifies transactions and exposes entitlements natively with no third party and no cost. RevenueCat adds cross-platform sync, analytics, webhooks, and edge-case handling. Single-platform teams may prefer StoreKit 2; teams optimizing for speed and cross-platform reach often prefer RevenueCat.