Build With RevenueCat

Build a customized mobile subscription business with RevenueCat. We do the heavy lifting of normalizing subscribers from any source and maintain a single source of truth for subscription status, so you can get back to building your app.

RevenueCat is a powerful, secure, reliable, and free to use in-app purchase server with global support. All you need to get started is an API key.

Offerings Migration Guide

Migrating to Offerings from a legacy setup

In order to make it easier to control and present products to end users remotely from the RevenueCat dashboard, we've released a new product setup called Offerings. Offerings replaces our legacy setup and allows more flexibility in presenting products to customers.

Legacy offerings will still be available for existing apps, and both systems can be used simultaneously during migration. However, there will be a forced migration at some point in the future.

What's new?

There are a few major improvements over the legacy system.

1. No hardcoded strings

With new Offerings, you can now fully reference products without any hard coded strings. This will make your paywall code more robust and allow maximum configurability from the backend.

func fetchOffering() {
    Purchases.shared.offerings { (offerings, error) in
        guard let offering = offerings?.current else {
            print("No current offering configured")
        for package in offering.availablePackages {
            print("Product: \(package.product.localizedDescription)")
            print("Type: \(package.packageType)")
            print("Price: \(package.localizedPriceString)")

The above code sample fetches the offerings from the server, unpacks the current Offering, and prints out the available packages. There's no need to hardcode any strings, making remote configuration a breeze.

2. More configuration options

In the legacy system, an entitlement had many offerings, and each offering had one product per platform. Now, one offering can contain multiple different ways of purchasing. These new "ways of purchasing" are called packages. Packages are simply a group of equivalent products across iOS, Android, and Stripe.

Offerings can now have multiple ways to purchase (we call them Packages).

Offerings can now have multiple ways to purchase (we call them Packages).

What this means is that packages can easily be added and removed from Offerings which will update in your app immediately.

For example, want to try out a new 3-month subscription? No problem. Want to change your free trial duration from 3-days to 7-days? No problem. How about changing the order my products are displayed in? Easy.

3. Simplified entitlement access

Entitlements are now configured completely separately from Offerings since there is no reason that what a product unlocks should be related to how it is displayed.

For most apps that only have one entitlement, all products can be added to that entitlement. For apps that do have multiple entitlements, a single products can now unlock any number of entitlements.

Entitlements are now directly related to products.

Entitlements are now directly related to products.

Migration Guide

1. Check your entitlements

All of the entitlements from the legacy view should be brought over to the new Offerings system, ensuring that the correct products are added to the correct entitlement.

2. Create new Offerings and Packages

Add a standard offering and configure it with packages. See the Configuring Products guide for how to set them up.

3. Update to SDK version 3.x.

Change Purchases.entitlements to Purchases.offerings
To access the new offerings, you will need to migrate from the Purchases.entitlements method to the Purchases.offerings method. See the Displaying Products guide for how to use the new method.

Change makePurchase to purchasePackage
In order to correctly track the offering that was purchased, makePurchase has been replaced with purchasePackage that takes a new Package object instead of an SKProduct. See Making Purchases guide for more info.


Will this affect my existing entitlements and offerings?

For entitlements, no. Existing entitlements work with both systems, and we use a super-set of the two configurations when computing entitlement eligibility.

The existing offerings are still available in version 2.x of the SDK and can continue to be used and updated without affecting the existing system.


New Offerings


Level of access user is "entitled" to, unlocked by offerings.

Level of access user is "entitled" to, unlocked by products.


A single product per platform.

The selection of products that are offered to a user in the form of packages.



A group of products, one per platform, usually with the same characteristics such as duration and trial period.

Updated 2 months ago

Offerings Migration Guide

Migrating to Offerings from a legacy setup

Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.