Entitlements are the access levels your app understands. They let you change products, prices, trials, store offers, and packages without rewriting premium-access logic in every client. Most apps start with one entitlement:
Use more only when the product truly has different access tiers, such as pro, teams, maps_europe, or credits_pack.

Why entitlements matter

Without entitlements, app code tends to become product-ID logic:
With entitlements, app code stays stable:
That is the whole point. Your dashboard owns product mapping; your app owns access behavior.

Attach products to entitlements

Every product that should unlock premium must be attached to the entitlement. If the product is not attached, purchase can finish while access remains locked.

Dashboard creation checklist

When you create the first entitlement, keep it boring and stable:
  1. Name it for humans, such as Premium.
  2. Set the app-facing key to premium.
  3. Attach every monthly, annual, lifetime, or winback product that should unlock that access.
  4. Do not encode store IDs, prices, or platform names into the entitlement key.
  5. Document what screens/features the entitlement unlocks so support and engineering use the same language.
The key is what appears in CustomerInfo and what your app checks with hasActiveEntitlement("premium").

Check the entitlement

Status and access

The SDK helper hasActiveEntitlement(...) is the normal path. Use raw status only when you are building support tooling or backend-specific policy.

Product-to-entitlement failure mode

The most common issue is this:
  1. Offering loads.
  2. Package renders.
  3. Purchase succeeds.
  4. premium does not unlock.
When that happens, check whether the purchased product is attached to premium. AppActor cannot unlock an entitlement that the catalog never mapped.
After defining entitlements, continue with Products and Packages and Offerings.