- Products can change with pricing, packaging, or platform.
- Entitlements should stay stable and human-readable.
- The cleanest access layer checks entitlements everywhere, not products directly.
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 products vs entitlements subscriptions mean in plain English?
The easiest way to understand the difference is this: products describe how the store sells, while entitlements describe what the customer can use. A yearly web plan and a monthly App Store plan can both grant the same entitlement.
Products are the specific items customers buy. Entitlements are the access rules your app enforces after purchase. Keep them separate and access management becomes much simpler.
| Store product | Entitlement unlocked | Why the split helps |
|---|---|---|
ios_monthly_pro | pro | Monthly and annual products can share one access key. |
ios_yearly_pro | pro | Price changes do not force code changes. |
stripe_team | team | Web checkout can unlock the same feature set as mobile. |
Why does this matter for paid apps?
Separating the two lets marketing run promotions, billing teams test packaging, and product teams launch new platforms without rewriting premium checks everywhere.
For subscription apps, that flexibility is operationally important. The more pricing experiments or platform surfaces you add, the more painful SKU-coupled code becomes.
What model should developers use instead?
Model access with stable entitlement keys, then let many products point to those keys. That creates a single place to reason about premium access, grace period rules, and future plan migrations.
A user who purchases stripe_monthly_pro on the web and later restores access inside the iOS app should still resolve to pro. The app should not care which billing system delivered it.
- Create products per store and billing cadence.
- Create entitlements per access promise.
- Use customer identity to attach those together across rails.
What do teams usually get wrong?
Teams usually create complexity when they let catalog structure leak directly into feature-gating logic.
- Creating one feature flag per product ID.
- Using billing cadence names like monthly or annual as if they were access levels.
- Forgetting that web and mobile users may still be the same customer.
Frequently asked questions
Can multiple products unlock multiple entitlements?
Yes. The mapping can be many-to-many. The key is keeping the access model intentional instead of accidental.
What should I name an entitlement?
Name it after the access promise, such as pro, team, or lifetime, not after the store SKU.
Does this apply to one-time purchases too?
Yes. Non-consumable purchases can also unlock entitlements; the pattern is not limited to auto-renewing subscriptions.
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
Use the entitlement docs to design the stable access layer first, then attach products from every rail behind it.