purchases-flutter: in-app subscriptions for Flutter with RevenueCat

One client for two store APIs

purchases_flutter is a client for the RevenueCat subscription and purchase tracking system, and it is published on the Dart package registry as purchases_flutter.

What it wraps is stated plainly: the library provides a wrapper around StoreKit, Google Play Billing, and the RevenueCat backend, so that implementing in-app subscriptions in Flutter is easy, with receipt validation and status tracking included.

That third element is the one that changes the shape of the problem. A native app that sells a subscription on both the Apple App Store and Google Play has two completely different purchase flows, two receipt formats, two renewal semantics, and two error surfaces, and the subscription state has to be reconciled across them. The plugin does that reconciliation, which means the application talks to one interface and does not branch on the platform.

The platforms are iOS, macOS, and Android, and the Apple platforms go through StoreKit while Android goes through Google Play Billing. The macOS support is worth noting, because a subscription that was only ever shipped on phones is now a desktop purchase as well, and the state has to survive on a platform with a different update cadence.

The project is MIT licensed, the site is revenuecat.com, and the last push was on 2026-10-20. The releases are frequent, with 10.17.0 on 2026-10-19, 10.16.0 on 2026-10-14, and a 9.16.2 on 2026-10-09, which shows the two version lines moving at once, the current line and a maintenance line for the previous major.

Server side validation, and why it is the point

The feature table in the README has a column for the plugin and a column for RevenueCat itself, which is a useful way to see what the library does and what the service does.

The first row is server-side receipt validation, and it is marked as belonging to RevenueCat rather than to the plugin. That is the design in one line. The client sends the receipt to the service, the service validates it with the store, and the client is told what the customer actually owns.

The alternative is doing it in the app, and the reasons not to are worth stating because they are the reasons this kind of library exists. A receipt validated on the device is a receipt the customer can modify. A subscription status known only on the device is a status the customer controls. And a refund or a family sharing revocation is only visible to the server, so an app that trusts its own local state will keep granting features that were paid for and then taken away.

The second row is the webhooks, and the README describes them as enhanced server-to-server communication with events for purchases, renewals, cancellations, and more.

That row is the other half of the story, and it is the half a developer forgets. A purchase is not a single event. It renews monthly, it can be cancelled, it can expire, it can be refunded, it can be upgraded or downgraded, and it can be transferred through family sharing. If the server only learns about a purchase when the app tells it, then the server's view is only as fresh as the last time the app was opened. The webhooks are what make the server's view correct even when nobody opens the app, which is exactly what a subscription service needs in order to send access, revoke it, and reconcile revenue.

The webhooks and the server-side validation are two halves of one design, and the plugin is the client for both.

Status tracking, analytics, and the metrics that come with them

The next two rows are about what the service does with the data once it has it.

Subscription status tracking is described as knowing whether a user is subscribed, whether they are on iOS or on Android. The platform neutrality is the point, since the same entitlement has to be representable across both stores, and the state a Flutter application asks about is a single answer rather than two store specific answers.

Analytics is described as the automatic calculation of metrics like conversion, MRR, and churn. Those three are worth pausing on, because each of them is a definition rather than a number. Conversion is the ratio of people who reach a paywall to people who pay, MRR is the normalised monthly revenue of the subscriber base, and churn is the rate at which subscribers leave. A service that receives every purchase and renewal event can compute them consistently, because it sees the whole population rather than the sample that a single app reports.

The remaining rows are the operational ones. There is online documentation and an SDK reference that is described as up to date, and over a dozen integrations that make it easy to send purchase data where it is needed, which in practice means into the analytics, engagement, and marketing tools an app team already uses. The project is described as well maintained with frequent releases, and the support is a help centre.

The README also links the full documentation site for the Flutter flavour of the product, and the SDK reference is on the package registry, which is where the API documentation for the plugin itself lives.

The repository is a plugin with an ecosystem around it

The top level of the repository shows a project that is more than one package.

There is the plugin itself, with the lib directory and the platform folders for android, ios, and macos, and a pubspec manifest. There is a separate package directory for the user interface components, purchases_ui_flutter, which is the paywall and the subscription management screen that a Flutter app embeds rather than builds.

Then there are the things that make the project maintainable. There is an end to end test directory and a test directory, and an api_tester directory, which is the tool for exercising the backend API and the plugin's own interface against it. There is a revenuecat_examples directory with more than the single example application in the example folder, and a migrations directory, which is the record of schema and configuration changes over the years and is a useful thing to read if you are upgrading a long lived app.

The tooling around it is thorough. There is a CircleCI directory and a GitHub directory, a fastlane directory for the store releases, a Dangerfile for the pull request checks, a Ruby Gemfile with a lock file, and a mise configuration with a lock file for the toolchain versions, along with an sdkmanrc file, which is another way of pinning the same thing for developers who use that tool. There is a renovate configuration for the dependency updates, and an analysis options file for the Dart analyser.

The release process has its own documentation, with a releasing document, a versions document, a changelog, and a separate changelog for the latest release, plus a version file at the root that the build reads.

And there are two agent instruction files, one for one assistant and one for another, alongside the development and contributing guides, which tells you that the project has decided how it wants automated contributions to arrive.

Requirements, installation, and the version lines

Installation is the ordinary Flutter plugin arrangement, by adding the package as a dependency in the pubspec manifest, and the README links to the Flutter documentation for that step.

The requirements are stated in one line, and they are the floor rather than a recommendation. The plugin requires Xcode 14.0 or newer, and the minimum targets are iOS 13.0 and Android SDK 21, which is Android 5.0.

Those numbers are worth comparing against the release line, because the version history in the repository shows two lines moving at once. The current line was at 10.17.0 in October 2026, and a 9.16.2 was published the same month, which is the pattern of a project that keeps the previous major alive for the apps that have not migrated.

For an app team, the practical question is which line to pin. The current line is the one that gets the new store features, since the plugin is where a new subscription capability in either store first appears. The previous line is the one that will keep working without a migration, and the migrations directory in the repository is the place to look before moving between them.

The other thing to check before the first release is the webhooks. The client side of a purchase can be implemented in an afternoon with the plugin and the documentation, and it will work, because the client asks the service what the customer owns. The server side is what a launch usually forgets, and until the webhook is configured and verified against the dashboard, the entitlement state in the service is incomplete.

Editorial conclusion

purchases_flutter fits a Flutter team selling a subscription on both stores who does not want to implement receipt validation twice, who wants the entitlement logic in one place, and who is prepared to let a third party sit between the app and the store. It does not fit an app that must handle purchases entirely on device with no backend involvement, and it does not fit a team that cannot depend on a hosted service in the purchase path. Verify first that the minimum operating system and toolchain versions match, Xcode 14 and iOS 13 or Android SDK 21, that the entitlement model in the dashboard matches the way the app grants features, and that the webhooks are configured before the first release, because the server side state is what the client later asks about.

Frequently asked questions

Official sources

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