Choosing a Monetization Model

There are four ways to sell content through the SDK. They differ on three things that matter to your app: how many store products you have to manage, whether the store can restore purchases for you, and whether you need your own backend and user accounts.

Answer three questions and the table points you to a model.

Answer these first

1. Do you have user accounts / login in the app? (Needed to remember purchases across reinstalls when the store can't.)
2. Do you add new content items often? (Weekly drops vs. a stable catalogue.)
3. Do you need per-item pricing — or would recurring revenue suit you better?

Start here

The token model is the only one that demands your own backend. If you don't have user accounts, treat it as off the table — see the warning under Content token.

The four models

Per-item unlock

One nonconsumable store product per content item.

• Store products: one per item.
• Restore: native — call getOwnedProducts({ sync: true }); the store remembers each purchase for free.
• Backend / accounts: none required.
• Pick when: your catalogue is stable or grows slowly and you want per-item pricing and individual ownership.
• Avoid when: you add items constantly — creating and getting a product reviewed for every single item becomes a chore (though it never requires an app release; see the recipe).

Bundles are a variant: a single nonconsumable that unlocks a group of items at one price.

All-access unlock

A single nonconsumable store product that unlocks every content item, present and future.

• Store products: one, ever.
• Restore: native — getOwnedProducts({ sync: true }).
• Backend / accounts: none required.
• Pick when: "buy everything, forever" is an acceptable offer and you want the simplest possible setup. New items light up automatically for everyone who bought.
• Avoid when: you need to sell items individually or price them differently.

Content token

A consumable store product the user buys and then redeems for any one content item. One product (or a few price tiers) can back an unlimited catalogue.

• Store products: one, or a handful of price tiers.
• Restore: none. The store never restores consumables.
• Backend / accounts: required. You must keep your own record of what each user owns, keyed to a user account, or purchases vanish on reinstall or a new device.
• Pick when: you add items constantly and already run user accounts + a backend, so adding an item never touches App Store Connect or Google Play.
• Avoid when: you have no login. Without an account to tie ownership to, a reinstall wipes the user's purchases and you can't restore them.

All-access subscription

A subscription store product granting access to all content items while the subscription is active.

• Store products: one (or a few tiers/periods).
• Restore: native — getActiveSubscriptions() / restorePurchases().
• Backend / accounts: optional. The store reports active status; a backend only helps if you want server-authoritative gating.
• Pick when: you want recurring revenue and "access while subscribed" fits the content.
• Avoid when: users expect to own a one-off purchase forever.

At a glance

Next

Ready to build? Sell themes or one-off content walks through per-item unlock end-to-end, then shows the token upgrade path.

See also

• Set Up In-App Purchases
• In-App Purchase API Reference