Subscription Management
Entitlements & Products
Define your products once, map them to entitlements, and check access with one call — server-synced and correct on cold launch.
The question your app asks a hundred times a day is the simplest one in the business: does this user get the paid features or not? Answering it well is where subscription apps quietly lose hours — reconciling StoreKit and Play Billing receipts, deciding what "Pro" means, handling the user who bought annual on iPhone and opened the iPad, and praying the access check is right on a cold launch with no network. Entitlements and products on Superwall turn that mess into two clean concepts. You list the products you sell, group them under entitlements that represent access, and then ask a single question anywhere in your code: is this entitlement active?
Products you define once, entitlements that decide access
A product is the thing a user buys — a specific App Store, Google Play, custom-billing, or Stripe SKU. You add it in the dashboard with its identifier, price, trial, and period, and from then on you reference it by name in the paywall editor as products.primary, products.secondary, and so on.
An entitlement is the access that product unlocks. Entitlements represent the features a user is entitled to — a single "pro" tier if your app has one level of service, or several tiers if you sell more than one. You attach one or more entitlements to each product, and that mapping is what your app actually gates on. This is the part that matters most:
Subscription status is determined by entitlements. If a product is purchased but linked to no entitlement, that user's status is inactive — so every paid product needs at least one entitlement attached.
Tiers are just groupings. Monthly, annual, and lifetime SKUs can all grant the same
proentitlement, so your access check never cares which plan someone bought.You don't have to overthink it. With one level of service you can use the default
proentitlement and create nothing else.
Server-synced, so the answer is always right
Superwall keeps entitlement state on its own servers, synchronized from App Store Server Notifications and Google's Real-Time Developer Notifications rather than from a receipt your app has to validate on every launch. The practical difference shows up in all the places client-side receipt checking tends to break:
Cold launch is correct with no round-trip. Entitlement state is resolved server-side, so the user isn't briefly locked out of features they paid for while a receipt validates.
Refunds, grace periods, and billing retries propagate fast. Because state is driven by store notifications, a refund or expiration flips access as the store reports it, instead of waiting on your app's next receipt check.
The hard edge cases are handled platform-side. Family sharing, grandfathered pricing, pause and hold, upgrades and downgrades with proration, and cross-platform reconciliation are managed for you.
One access check, everywhere in your app
Once your products map to entitlements, gating a feature is one call. On iOS you read the active entitlements on the device via Superwall.shared.entitlements; the same model exists across the SDKs. You check whether the entitlement a feature requires is active and branch — no receipt parsing, no per-platform purchase logic in your view code. Because entitlements abstract over the specific SKU, adding a new price point or a lifetime option later is a dashboard change, not a refactor of every if that guards a feature.
The same model powers your paywalls and your billing
Products aren't just an infrastructure detail — they're what your paywalls render. The products you define are the ones you drop onto a paywall in the editor and reference with Liquid, so prices, trial copy, and the selected-plan state all read from the same source of truth your access checks use. That means you can swap which products a paywall shows, test a new price, or restructure your tiers without your entitlement logic ever changing — the gate stays the same while the offer in front of it moves.
Why teams run it as their subscription source of truth
The entitlement layer is the foundation teams want under everything else: reliable access state, standardized across the App Store, Play Store, and Stripe, that they don't have to babysit. It's also why migrations land here. Teams coming from an in-house StoreKit or Play Billing setup can route store notifications through Superwall, adopt the entitlement model, and retire their receipt-validation code incrementally — no rearchitecture, just a more dependable answer to the one question their app keeps asking.
Get started
Add your first products and entitlements from the Adding Products guide, wire your paywall to them with the products docs, and check access in code with the entitlements reference. Then create a free Superwall account — Superwall charges only on the revenue its paywalls generate, so the entitlement and product layer itself is yours to build on for free.
Read the Adding Products guide