- Products belong to stores and payment rails; entitlements belong to your app.
- Multiple products can unlock one entitlement like
pro. - Access logic becomes far simpler when the app checks entitlements, not SKU names.
Definitions used in this guide
The SKU a customer purchases on Apple, Google Play, or Stripe, such as ios_monthly_pro.
The app capability unlocked by one or more products, such as pro.
The billing system that processes the payment, such as the App Store, Google Play, or Stripe.
What does what is an entitlement app subscriptions mean in plain English?
In app subscriptions, an entitlement is the durable access state your product code cares about. A monthly plan, annual plan, promo upgrade, or web checkout can all be different products, but they may grant the same entitlement.
An entitlement is the access your app grants after a customer buys a qualifying product. Products are what users purchase. Entitlements are what your app unlocks.
| Concept | Example | Who owns it |
|---|---|---|
| Product | ios_monthly_pro | Apple, Google Play, or Stripe |
| Entitlement | pro | Your app and access policy |
| Check in code | isEntitled("pro") | Your client or server logic |
Why does this matter for paid apps?
If you tie app logic directly to store product IDs, every packaging or pricing change leaks into your codebase. Entitlements absorb that change. The app only needs to know whether pro is active, expired, in grace period, or unavailable.
This becomes even more important once the same feature can be purchased on iOS, Android, and web. The store changes. The access promise should not.
What model should developers use instead?
Treat entitlements as a product layer you own. Create stable keys like pro, team, or plus, then attach the relevant Apple, Google Play, and Stripe products behind them.
That approach lets one customer buy ios_monthly_pro today and stripe_yearly_pro tomorrow without forcing your feature flags or paywall logic to change names.
- Define entitlements around access, not around billing cadence.
- Map every qualifying product to the entitlement.
- Check the entitlement in app code everywhere access matters.
What do teams usually get wrong?
Most entitlement confusion comes from collapsing billing identifiers and access identifiers into the same thing.
- Checking raw product IDs throughout the app instead of one entitlement key.
- Creating separate entitlements for monthly and annual versions of the same premium access.
- Forgetting to attach new products to the entitlement when pricing changes.
Frequently asked questions
Can one entitlement have many products attached?
Yes. That is one of the main reasons entitlements exist. Several products can unlock the same premium access level.
Should an entitlement name match the store SKU?
Usually no. The entitlement should match the access promise, not the billing identifier used by the store.
Where should entitlement checks happen?
Anywhere access matters: in your app UI, in premium feature gates, and often on the server when an API should only be reachable by paying users.
Does Crossdeck work across iOS, Android, and web?
Yes. Crossdeck is designed around one customer timeline across Apple, Google Play, Stripe, and web or mobile product events, so the same entitlement and revenue model can travel across surfaces.
What should I do after reading this guide?
Use the CTA in this article to start free or go straight into read products and entitlements docs so you can turn the concept into a verified implementation.
Take this into the product
Define a clean entitlement key first, then map products from Apple, Google Play, and Stripe to that access layer.