Types of In-App Purchases

Entitlements, offerings, and products, OH MY!

Sharif Moustafa

Between entitlements, offerings, and products, RevenueCat can support several different business models. To get you started, below are some typical business models and how you can implement them with RevenueCat along with a more complex example that combines most of the concepts we discuss. If you're just starting out with in-app purchases, there are great introductions at Apple's and Google's developer sites. If you want to get familiar with RevenueCat first, take a look at our documentation. We support both iOS and Android along with several cross-platform frameworks.

Subscription only

Subscription products bill your users on a recurring basis. Although relatively new on mobile platforms, more and more apps are choosing a subscription-based business model to create the steady stream of revenue needed for continued development. Moreover, subscriptions are well supported on the App Store and Play Store. Whether you want to offer an all-access pass to your app's content, provide a premium upgrade for your power users, or something else, you can do it with RevenueCat.

To implement a subscription based business model, you would add your products to entitlements to track a user's subscription status and offerings to present and purchase the products. If you aren't familiar with entitlements and offerings, we have a great introduction in our documentation.

โ€

Standardize your product offerings by using packages to group together similar subscriptions of different durations.

One-time purchases with non-consumable products

Non-consumable products allow your users to make a one-time purchase in exchange for permanent access to digital goods. Some examples of non-consumable products are providing lifetime access to a subscription in return for a large, one-time payment and offering game-packs with exclusive characters and levels. In this world of increasingly popular subscriptions, is there a place for non-consumable products anymore? Of course!

Even though more developers are opting for subscriptions, it's important to choose the business model that best suits your app and audience. It could be that subscriptions don't fit your product or your users are complaining about subscription fatigue. In these cases, non-consumable products can be used to great effect.

โ€

Many subscription apps provide a lifetime option for users who prefer one-time purchases over recurring subscriptions.

โ€

Apple provides non-consumable products as part of their offering of in-app purchase products while Google makes no distinction, simply calling them managed in-app products. Learn more about each on Apple's and [Google's](While Apple provides a distinct non-consumable product category, Google provides only managed in-app products as of version 3 of the In-app Billing API. The default behavior of managed in-app products is to function like non-consumable products.) in-app purchase documentation.

Non-consumable products work similarly to subscriptions but without needing to track expiration dates, renewals, or cancellations. Similarly to subscriptions, you would attach each of your products to an entitlement and present and purchase them with offerings so that you can take full advantage of the dynamic functionalities of offerings.

Consumable products

Consumable products are often used to sell digital goods that can be used up and repurchased multiple times. They are common in games, such as more lives or tokens, but can also be used in other apps that have some type of refillable credit, such as purchasing minutes for VOIP service.

While Apple provides a distinct consumable product category, Google provides only managed in-app products that you have to consume in your app as of version 3 of the In-app Billing API. The default behavior of managed in-app products is to function like non-consumable products until you consume them.

Learn more about each on Apple's and [Google's](While Apple provides a distinct non-consumable product category, Google provides only managed in-app products as of version 3 of the In-app Billing API. The default behavior of managed in-app products is to function like non-consumable products.) in-app purchase documentation.

Because consumable products are, by definition, ephemeral, RevenueCat does not track the usage of a product, but rather the purchase of a product. For example, if you have a product that grants extra lives in a game, RevenueCat will process and record the purchase of the product, but it is up to you to keep track of how many lives are used. This could be done on device, but a better solution would be to track usage on your servers so that you can restore unused portions of the product and sync the usage state across devices.

Since RevenueCat only tracks purchases, if you add a consumable product to an entitlement, RevenueCat will report the entitlement as unlocked even after just one purchase! Therefore, it's better not to add consumable products to entitlements. Instead use offerings to display and purchase consumable products and keep track of a user's usage yourself. That way you retain the flexibility of offerings and RevenueCat's powerful revenue reporting features even when you're not using entitlements.

Complex example

Now that you know how you can model your business model in RevenueCat, let's walk through a non-trivial example! Let's say we have a game called FlappyCat, where you tap on the screen to keep our titular character floating above obstacles. Our users love it, but they wish there was more customization available. After discussing it with our design and product teams, we decide we want to offer one-off purchases of themes for our casual players and an all-access pass to all customization options for our more ardent fan base.

The all-access pass will also grant some additional customization features, such as custom avatars and a selection of exclusive soundtracks. Finally, we want to be able to offer the all-access pass at a reduced price on national holidays, like Christmas.

โ€

Keep that cat flying! Source.

โ€

Before we start implementing our model in RevenueCat, let's break down the requirements.

  • Users will purchase themes and keep them for life, which means those should be non-consumable products.
  • The all-access pass provides access to all of FlappyCat's customization features, but will be revoked if a user cancels their subscription, so this will be provided as an auto-renewing subscription.
  • Products can only have one price at a time, so to simplify sale pricing, we should have an additional sale-price subscription product for the all-access pass.

Now that we have a clear understanding of how our products will work, it's easy to see how they will be configured in RevenueCat. Let's start with the entitlements:

  • There's a one-to-one relationship between themes and their corresponding products, so each of these products would go in their own entitlements.
  • The all-access pass has its own products that unlocks all themes and grants access to additional features, so its products should go in a separate "all-access" entitlement.

โ€

Each theme is in its own entitlement and the two all-access products are in a different entitlement.

โ€

Entitlements are all set up! Do we even need offerings? Yes! Even though offerings aren't required for purchasing products and unlocking content, they can help by simplifying paywalls and providing a way to offer sales. Let's see how this would look:

  • Every theme should be displayed in one gallery to facilitate a "shopping" experience. That means they should all be in one offering to make it easy to display and purchase them in code.
  • The all-access pass should also be shown in the same gallery to make it quick for a user to purchase once they see all of those gorgeous themes! So the all-access pass should also be part of the same offering.

When it comes to the sale-price all-access pass, there are two ways to do this. We could make a second offering that contains all of the themes and the sale-price all-access pass, or we could separate the all-access products into their own offerings and display one depending on our sale schedule. There's no right answer here; each has its own advantages.

The former takes more time to configure in RevenueCat but allows us to dynamically change the current offering with a switch in the dashboard. Conversely, the latter option takes less time to configure in RevenueCat, but prevents us from using the current offering feature.

โ€

One way to set up offerings is to make one with the standard all-access pass and another with the sale-price all-access pass. Running a sale requires just one button press to make the sale offering current.

Make it your own

This blog post discussed a few different business models, but what if you want to use multiple business models or put a twist on one of them? At RevenueCat, we say go for it! This is meant to be a starting point for your revenue model. Many apps combine several of these business models.

If your app uses a different pattern than the ones discussed here, weโ€™d love to hear about it in our discussion boards or email. As always, we are available to help you in any way we can, so donโ€™t be shy about reaching out.

For more updates, tip, and tricks follow us on Twitter!

โ€