purchases-android: RevenueCat's Android SDK for subscriptions and in-app purchases

What the SDK does

RevenueCat describes itself as a powerful, reliable and free to use in-app purchase server with cross-platform support, and the open-source framework provides a backend and a wrapper around StoreKit and Google Play Billing to make implementing in-app purchases and subscriptions easy.

The division of labour is the thing to understand first. The Android store, Google Play Billing, is a client library that can charge a card and hand you back a token, but it knows nothing about whether that token is valid, whether it has already been redeemed, or what the user is entitled to. That validation is server-side work, and it is the work that every app ends up building badly at some point.

The Purchases class is the client for the RevenueCat subscription and purchase tracking system. The README describes it as an open source framework that provides a wrapper around BillingClient and the RevenueCat backend to make implementing in-app subscriptions in Android easy, with receipt validation and status tracking included.

So the SDK sits between the Play Billing client and the RevenueCat server, and the app talks only to the SDK. The app never validates a receipt itself, and it never has to reason about what happens when a purchase is refunded, or a subscription lapses, or a user logs in on a second device.

The list of what you can do with it is worth reading in full, because it is broader than the purchase button. Fetch products, make purchases and check subscription status with the native SDKs. Host and configure products remotely from the dashboard. Analyse the most important metrics for your app business in one place. See customer transaction histories, chart lifetime value, and grant promotional subscriptions. Get notified of real-time events through webhooks. And send enriched purchase events to analytics and attribution tools through the integrations.

Those last two are the ones that separate a revenue SDK from a payment wrapper. Webhooks mean your backend learns about a renewal at the moment it happens, and the integrations mean the purchase data lands in your analytics stack enriched rather than raw.

The primary language is Kotlin, the licence is MIT, the default branch is main, and the homepage is the RevenueCat Android installation documentation. The recent releases are 10.28.1 from 2026-10-16, 10.28.0 from 2026-10-15 and 10.27.1 from 2026-10-13, and the last push was on 2026-10-20 with the project not archived. Three releases in a week is a fast cadence for a library that sits in the critical path of an app's revenue.

The feature table, and what stands out

The SDK features table has one column, headed RevenueCat, and it is a list of capabilities rather than a comparison.

Server-side receipt validation is first, and it is the foundation everything else rests on. Webhooks come next, described as enhanced server-to-server communication with events for purchases, renewals, cancellations and more.

Subscription status tracking is described in a way that names the real problem it solves: know whether a user is subscribed whether they are on iOS, Android or web. That is cross-platform entitlement, and it is the feature that makes a cross-platform app possible at all, because a user who subscribes on the web has to be recognised on the phone.

Analytics is described as automatic calculation of metrics like conversion, mrr and churn. The lowercase mrr is a small detail, but it points at what the platform is for. RevenueCat is not a payment processor, it is a subscription analytics and entitlement layer, and monthly recurring revenue is the metric the person buying this is measured on.

Then there are three entries that are about the surrounding service rather than the SDK. Online documentation up to date, integrations with over a dozen services to send purchase data where you need it, and well maintained with frequent releases. Great support with a help centre links to a Zendesk instance, which is a small signal about the scale of the operation behind it.

The migration section is the other thing the table of contents reveals. There are guides for migrating from v4.x.x to v5.x.x and from v5.x.x to v6.x.x, both in a migrations/ directory. Those are in the repository listing, and they matter, because a 10.x SDK has crossed several major versions, and the two documented breaking-change paths tell you what kinds of changes the project makes between majors. A library that ships migration guides for each of them is a library whose users are expected to be on an old version for a long time, which is exactly the case for a revenue SDK.

Requirements, and the API level split

The requirements section is short and has an important detail in the third line.

Java 8 or later and Kotlin 1.8.0 or later are the language floors. Then the minimum target: Android 6.0, which is API level 23, for the SDK as a whole. But Paywalls and Customer Center have a higher floor, Android 7.0, API level 24.

That split is worth pausing on, because it is the kind of detail that determines whether a feature works on the devices you actually have in your install base. If you use the paywall or the customer centre and you still support API 23, you have a problem that only shows up on those devices, and the failure mode is a missing screen rather than an error message.

The customer centre deserves a note of its own even though the README does not expand on it. It is the self-service screen a subscriber uses to change plan, cancel, restore purchases and see their billing history. For a subscription app, it is a significant piece of surface area, and having it in the SDK with a slightly higher API floor tells you it is a first-class feature rather than an afterthought.

The paywall is the other one, and the codelab section explains how it works. The second codelab, on Android In-App Purchases and Paywalls, covers integrating the SDK into your project, implementing in-app purchases, learning how to distinguish between paying and non-paying users, and building a paywall screen, which is based on a server-driven UI approach.

Server-driven paywalls are the interesting design decision. The paywall layout, copy and offerings come from the RevenueCat dashboard rather than from your app, so you can change a price or rewrite a paywall screen without shipping an app update. That is a genuine benefit for anyone who has had to wait for a review cycle to fix a typo in a pricing screen, and it is also a dependency: the paywall's appearance is not in your repository, which means the design lives in two places.

The full SDK reference is hosted at sdk.revenuecat.com, and the Quickstart Guide is on docs.revenuecat.com, which is also where the installation instructions referenced by the homepage field live.

The codelabs, and the sample apps in the repository

The codelab section is the pedagogical part of the README, and it is split into two codelabs that build on each other.

The first is the RevenueCat Google Play Integration, which covers properly configuring products on Google Play, setting up the RevenueCat dashboard and connecting it to your Google Play products, understanding Product, Offering, Package and Entitlement, and creating paywalls using the Paywall Editor.

The four concepts in that third bullet are the vocabulary of the whole system, and it is worth pausing on each of them. A Product is what you sell, a single thing with a price and an identifier in the store. A Package groups one or more Products into something a customer buys, for example a monthly subscription with a trial and a discounted introductory offer. An Offering is a set of Packages that you present to a customer, and it is the unit that a paywall shows. And an Entitlement is the thing the customer actually gains access to, which is the bridge between what was paid for and what your app grants.

The separation of Package and Entitlement is the part that pays off. Because entitlements are the grant and not the product, one product can grant several entitlements and one entitlement can be granted by several products, which is what makes lifetime purchases, promotional grants and cross-platform subscriptions composable rather than a special case.

The second codelab, on Android In-App Purchases and Paywalls, is the implementation half, and it ends with the paywall screen built on the server-driven approach.

Then there is the sample app, MagicWeather, in the examples/ directory, which you can view or build and which is described as something to open in a different Android Studio window. That instruction tells you it is a full standalone project rather than a snippet, which is the right way to learn an SDK with a configuration step in the dashboard.

The repository listing shows how many samples there are, and their names map onto the feature surface. MagicWeather, MagicWeatherCompose and a vanilla-ad-tracker-sample and admob-sample, so the advertising and attribution side has examples. A custom-entitlement-computation-sample, so the entitlement model can be extended. A paywall-tester and a purchase-tester, so the two core flows can be tried in isolation. A checkpointtester and an rcttester, and a web-purchase-redemption-sample, which covers the case of a purchase made on the web being redeemed on Android. That last one is the cross-platform entitlement feature in a test app.

The repository layout, and what the module names reveal

The top-level listing is large and reveals how the project is put together.

The core module is purchases/, and there is a bom/ directory, which is a Gradle bill of materials, the usual way to publish a set of libraries with a single version coordinate so a consumer can align versions across modules. The build itself is build.gradle.kts with build-logic/ for convention plugins, settings.gradle.kts, gradle.properties and the gradle wrapper.

Then the feature directories, and these are the interesting ones. There is a ui/ directory and a feature/ directory, which together are the Compose paywall and customer centre implementation, and a detekt-rules/ directory, which means the project ships its own static analysis rules. Custom lint rules for a revenue SDK make sense, because the errors you want to catch are domain errors, like using an entitlement before it has loaded, rather than style.

The codegen/ directory is where the API surface is generated, and api-tester/ is where the generated API is tested. That pairing is the shape of a project that keeps a large public API in step with a generator.

Then the testing infrastructure. integration-tests/ for the real thing, baselineprofile/ for Android baseline profiles, maestro/ for UI flow testing, and test-apps/ for apps used as fixtures. A Gemfile, a Gemfile.lock and a Dangerfile sit alongside, and Danger is the pull request review bot, which usually means a Ruby project on the side. fastlane/ is there for release automation to the Play Store, and there is a RELEASING.md documenting it.

The most telling entries are the small ones. There is .aiexclude, a file that appears to tell an AI tool what not to touch. There is AGENTS.md and CLAUDE.md, and a .cursor/ directory, so the project expects to be worked on with coding assistants. There is a .sdkmanrc and a mise.toml with a mise.lock, so the JDK version is pinned by two different tools, and a .version file. There is renovate.json for automated dependency updates.

Two more directories are worth naming. upstream/ appears to hold a checkout of some upstream project, and there is a .gitmodules, so it is a git submodule. And migrations/ holds the v5 and v6 migration guides the README links to.

Taken together, this is the layout of a commercially maintained SDK with a large, mostly automated release process, which is what you would expect from something sitting in the revenue path of thousands of apps.

How to evaluate it, and the questions to ask first

There are five questions, and the first is about the dependency you are signing up for.

Do you want a hosted service in the middle of your revenue path? RevenueCat is not just an SDK. The SDK is open source and MIT licensed, and it is the part you could read, but the receipt validation, the product configuration, the paywall hosting, the webhooks and the analytics all live in RevenueCat's backend. That is a deliberate trade, since a hosted validation service is what makes the SDK small, but it means your subscription state depends on somebody else's availability, and your paywall content is stored in their dashboard rather than your repository.

Second, the migration history. The SDK is at 10.x and the repository carries guides from v4 to v5 and from v5 to v6. If you are starting fresh, you are on the current API and this does not matter. If you are integrating into an existing app that has been on an older version, read the guides first, because the changes that break apps are usually in the entitlement and customer info models, which is where a subscription app's logic lives.

Third, the API level floor for the features you want. The SDK needs API 23, but the paywall and customer centre need API 24. Check your own minSdk and your install base before you plan to use them.

Fourth, the language floor and your build. Kotlin 1.8.0 and Java 8 are the minimums, and this is a Gradle project with convention plugins in build-logic, so it fits into an existing Gradle setup rather than fighting it. If your app is not on Gradle or not on Kotlin, the integration is more work than the README's quickstart suggests.

Fifth, the sample apps. With a dozen of them covering the paywall, the purchase flow, custom entitlement computation, advertising and attribution, and web purchase redemption, the fastest way to evaluate is to build the one closest to your case rather than reading the SDK reference. The checkouttester and rcttester are the two whose names are least self-explanatory, and they are the ones to look at when you want to see the raw behaviour rather than the polished path.

What you get in exchange is a production-grade in-app purchase implementation with server-side validation, cross-platform entitlements, paywalls you can change without an app release, and webhooks that keep your backend in step with reality. For most apps that is a large amount of work removed. The cost is the hosted dependency, and for an app with meaningful subscription revenue, that is a trade most teams are glad to make.

Editorial conclusion

Adopt purchases-android if you are building an Android app with in-app purchases or subscriptions and want server-side receipt validation, cross-platform entitlements and paywalls you can change without shipping an app release, rather than implementing all of that against Google Play Billing yourself. Do not adopt it as a standalone library, because the validation, the product configuration and the paywall hosting all live in RevenueCat's backend, so your subscription state depends on a third-party service being available. Before you commit, check that your minSdk is 24 rather than 23 if you plan to use the paywall or the customer centre, read the v5 and v6 migration guides if you are integrating into an app that has been on an older SDK, and build the sample app closest to your case first, since the dozen examples in the repository cover the flows far better than the SDK reference does.

Frequently asked questions

Official sources

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