purchases-ios: RevenueCat's StoreKit wrapper and what it adds to Apple's own API

This repository is the client half of a hosted service

The README opens by describing RevenueCat as a powerful, reliable and free to use in-app purchase server with cross-platform support, and it then describes a backend plus a wrapper around StoreKit and Google Play Billing. Only one of those two things is in this repository. `purchases-ios` is the Swift SDK. The server, the dashboard, the product configuration and the analytics live in the hosted product at revenuecat.com, which is also the homepage listed for the project.

That split is the single most important thing to understand before evaluating the project. You are not adopting a self-hosted purchase system. You are adding a client library that talks to someone else's servers, and every architectural consequence follows from that. Entitlements, product configuration, customer history, promotional grants and webhooks are all features of the service, delivered through this SDK.

The README is clear that the SDK is written entirely in Swift and remains compatible with Objective-C, which matters for apps with an existing Objective-C layer. The framework is distributed as `RevenueCat.framework`, with a separate `RevenueCatUI` podspec in the tree for the purchase-facing UI components, so the interface layer can be adopted independently of the purchase logic.

What the wrapper adds over StoreKit

StoreKit already lets an app fetch products, make a purchase and read the current entitlement. The SDK's argument is about everything after that, and its feature list is organised around exactly those gaps.

Cross-platform entitlement status is the headline. The README says you can know whether a user is subscribed whether they are on iOS, Android or web. That is not something StoreKit can answer, because StoreKit only knows about Apple's store, and an app with an Android build and a web frontend has three separate purchase records that somebody has to reconcile.

Webhooks are the second. The README describes them as enhanced server to server communication with events for purchases, renewals, cancellations and more. StoreKit 2 does deliver real-time events on device, but a device that is offline, deleted or never opened cannot report a renewal, so a server that only learns about purchases from the app will eventually miss money. Moving that responsibility to the service is the reason many teams adopt this kind of wrapper at all.

The third area is remote product configuration. Products can be hosted and configured from the dashboard rather than baked into the app binary, which lets you change pricing, gate a plan or introduce an offer without shipping a build. That is a genuine operational benefit and also a genuine trade, since the app's behaviour now depends on a network response.

Rounding it out are analytics computed server side, including conversion, MRR and churn, customer transaction history with lifetime value charts, the ability to grant promotional subscriptions, and integrations that forward enriched purchase events to other analytics and attribution tools.

Requirements, platforms and installation routes

The requirements are concrete and stated as a table: Xcode 15.0 or newer, iOS 13.0+, tvOS 13.0+, macOS 10.15+, watchOS 6.2+ and visionOS 1.0+. The visionOS target is the recent addition and the one to watch, since it is the only entry that implies a platform with no meaningful installed base yet.

Distribution is supported four ways, and the badges at the top of the README name them: Swift Package Manager, CocoaPods, Carthage and the plain framework. The repository confirms this at the file level with `Package.swift`, a `[email protected]` variant for older toolchains, `RevenueCat.podspec`, `RevenueCatUI.podspec` and `RevenueCat.xcodeproj` alongside a workspace file.

One practical recommendation in the README is worth acting on. When integrating through Swift Package Manager, it suggests adding the project's SPM mirror repository at `github.com/RevenueCat/purchases-ios-spm` for faster download and integration times. That is a build-time optimisation rather than a feature, and it only makes sense for a team integrating on a fresh checkout where the default resolution is slow.

The `Package.resolved` file in the tree means the repository itself pins its transitive dependencies, and the `.version` file at the root suggests a single place where the SDK version is recorded, which is consistent with a release process that ships several builds a week.

Upgrading across three major versions

The README carries two migration guides, one for v3 to v4 and one for v4 to v5, which is a reasonable indication of how much churn the API has seen. Version 5 arrived with a dedicated migration document hosted separately from the main docs, and given the rate of releases that is a pattern you should expect to repeat rather than a one-off.

The release cadence is the other thing the numbers tell you. Three releases in a week: `5.90.1` on 2026-09-17, `5.90.2` on 2026-09-18, and `5.91.0` on 2026-09-23, which is also the date of the last push. Patch releases one day apart are the normal shape of a project responding to production issues, and a minor release on the same day as the last push suggests the tags follow the commits closely.

For an SDK in your app's dependency graph, that has a straightforward implication. Pin the version rather than tracking a range, read the changelog for anything that touches entitlement logic before you take it, and remember that a subscription bug reports itself as users quietly losing access to paid features rather than as a crash. `CHANGELOG.latest.md` sits next to `CHANGELOG.md` in the tree, which is the file to check first.

Sample apps and the tooling behind the SDK

The README points at two starting points, `MagicWeather` and `MagicWeatherSwiftUI`, and the tree contains seven more under `Examples/`, which tells you how seriously the project takes integration examples. `PurchaseTester` is the one aimed at testing purchases properly, `LegacySwiftExample` covers the older non-SwiftUI path, `VanillaAdTrackingSample` deals with attribution, and `SampleCat` appears to be a deliberately small reference app. There is also `rc-maestro`, which points at end to end UI testing with the Maestro framework.

The tooling is unusually broad for a client SDK. Tuist and a `Tuist.swift` configuration sit alongside `fastlane/` and a `Gemfile`, so the project generates and builds its Xcode projects rather than maintaining them by hand. `renovate.json` handles dependency updates, `.swiftlint.yml` and `swiftlint-baseline.json` handle linting with a baseline for existing violations, `Dangerfile` handles pull request review automation, `codecov.yml` handles coverage, and `ci_scripts/` holds release automation. `Package.resolved` and `mise.toml` pin the toolchain.

Two directories suggest the scope of what the SDK covers. `LocalReceiptParsing` indicates local handling of purchase receipts, and `CustomEntitlementComputation` with its own example project indicates support for computing entitlements on device from raw purchase data rather than only accepting them from the server.

There is also `BackendIntegrationTests`, which is a reminder that this SDK is tested against a backend contract and not just in isolation, and `AdapterSDKs/` for the platform adapters.

When StoreKit alone is the better answer

The straightforward case for not using this SDK is a single-platform subscription app with no server component. StoreKit 2 is Apple's own API, it handles transactions and verification, and it requires no third-party network dependency in the purchase path. Adding a hosted service between your app and Apple's store introduces a component that can be slow, unavailable or expensive, and none of that buys you anything if the only thing you need is the one entitlement on the one platform.

The second case is a philosophical one about where purchase logic should live. With this SDK, the authoritative answer to whether a user may use a paid feature arrives from a server. That is the right design for cross-platform products and for fraud prevention, and it is the wrong design for an app that wants to work offline and treat local state as sufficient. There is no way to get the benefits without accepting that dependency.

The third is team cost. Product configuration moves to a dashboard, entitlement rules move to the service, and a revenue-affecting behaviour that used to be a code review question becomes a configuration question. That is a genuine operational advantage for many teams and a genuine loss of control for others.

Licensing is MIT, which is permissive and imposes nothing on a closed-source commercial app. The commercial relationship is with the service, not the code, and the README describes signing up for the service as the way to get started.

Editorial conclusion

purchases-ios pays for itself when you sell on more than one Apple platform or have a backend that needs reliable purchase events, because the hard parts it removes are entitlement reconciliation and server to server notification handling. If you ship a single-platform app with one subscription and no server, StoreKit 2 gives you the same purchase with none of the network dependency. Before integrating, decide two things: whether the products are configured centrally in the RevenueCat dashboard rather than bundled in your app, because that changes your release process, and which of the sample apps to start from, since MagicWeather and MagicWeatherSwiftUI cover the two common paths. The SDK moves fast, with three releases in the week before the last push on 2026-09-23, so pin the version and read the migration guide before upgrading across a major.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. RevenueCat/purchases-ios on GitHub