Trusted Entitlements

Trusted entitlements protect your access checks from tampered or stale client-side state. AppActor SDKs expose verification data on CustomerInfo and offerings so your app can decide how strict each access path should be.

Verification states

State	Meaning	Typical handling
`verified`	Server response signature verified successfully.	Grant access when the entitlement is active.
`verifiedOnDevice`	Entitlements were derived from trusted local store state while offline.	Grant temporary access for UX, then refresh when online.
`notRequested`	Verification was not performed or data came from a transitional unsigned cache.	Fine for low-risk UI; refresh for sensitive access.
`failed`	Signature verification failed.	Do not grant sensitive access; refresh or show support path.

Verification data does not protect you unless your code checks it. hasActiveEntitlement("premium") answers access state; verification tells you how much to trust that snapshot.

Basic UI gating

For normal UI surfaces, active entitlement checks are enough:

let info = try await AppActor.shared.getCustomerInfo()
let canSeePremiumTab = info.hasActiveEntitlement("premium")

val info = AppActor.shared.getCustomerInfo()
val canSeePremiumTab = info.hasActiveEntitlement("premium")

final info = await AppActor.instance.getCustomerInfo();
final canSeePremiumTab = info.hasActiveEntitlement('premium');

const info = await AppActor.instance.getCustomerInfo();
const canSeePremiumTab = info.hasActiveEntitlement('premium');

High-trust gating

For expensive content, backend-controlled resources, or abuse-prone actions, require both active access and trusted verification.

let info = try await AppActor.shared.getCustomerInfo()

let canUnlock = info.hasActiveEntitlement("premium") &&
    info.verification.isVerified &&
    !info.isComputedOffline

if canUnlock {
    unlockServerBackedFeature()
} else {
    showRefreshOrSignInPrompt()
}

val info = AppActor.shared.getCustomerInfo()

val canUnlock = info.hasActiveEntitlement("premium") &&
    info.verification.isVerified &&
    !info.isComputedOffline

if (canUnlock) {
    unlockServerBackedFeature()
} else {
    showRefreshOrSignInPrompt()
}

final info = await AppActor.instance.getCustomerInfo();

final canUnlock = info.hasActiveEntitlement('premium') &&
    info.verification.isVerified &&
    !info.isComputedOffline;

if (canUnlock) {
  unlockServerBackedFeature();
} else {
  showRefreshOrSignInPrompt();
}

const info = await AppActor.instance.getCustomerInfo();

const canUnlock =
  info.hasActiveEntitlement('premium') &&
  (info.verification === AppActorVerificationResult.Verified ||
    info.verification === AppActorVerificationResult.VerifiedOnDevice) &&
  !info.isComputedOffline;

if (canUnlock) {
  unlockServerBackedFeature();
} else {
  showRefreshOrSignInPrompt();
}

Offline decision path

When the network is unavailable, SDKs may expose offline-computed access from trusted local store state.

let offlineKeys = await AppActor.shared.activeEntitlementKeysOffline()
if offlineKeys.contains("premium") {
    showPremiumTemporarily()
}

val offlineKeys = AppActor.shared.activeEntitlementKeysOffline()
if ("premium" in offlineKeys) {
    showPremiumTemporarily()
}

final offlineKeys = await AppActor.instance.activeEntitlementKeysOffline();
if (offlineKeys.contains('premium')) {
  showPremiumTemporarily();
}

const offlineKeys = await AppActor.instance.activeEntitlementKeysOffline();
if (offlineKeys.has('premium')) {
  showPremiumTemporarily();
}

Treat offline access as resilience, not fresh billing truth. Refresh with getCustomerInfo() when the app returns online.

Fail-open versus fail-closed

Pick the policy per feature:

Feature type	Suggested policy
Cosmetic premium UI	Fail open from active entitlement if cached/offline.
Downloaded content already on device	Fail open briefly, then refresh.
Expensive server-side generation	Fail closed unless server confirms access.
Admin/support-only action	Fail closed on `notRequested`, `failed`, or offline-computed state.
Consumable credit grant	Fail closed until backend receipt acceptance is visible.

Mapping failure to watch

Offline entitlement derivation depends on cached product-to-entitlement mappings from offerings. If a product is not attached to premium, a purchase may complete but your access check will not unlock premium. Use this debug order:

Fetch offerings successfully.
Confirm productEntitlements contains the store product.
Confirm the product maps to premium.
Purchase the package.
Refresh customer info.
Check hasActiveEntitlement("premium") and verification.

If the feature is served from your backend, enforce access with Server-side Access Checks, not only from the mobile app.

Overview

Get Started

Testing and Go Live

Features

Remote Config

Experiments

Platform Resources

AI-Ready

Trusted Entitlements

Verification states

Basic UI gating

High-trust gating

Offline decision path

Fail-open versus fail-closed

Mapping failure to watch

​Verification states

​Basic UI gating

​High-trust gating

​Offline decision path

​Fail-open versus fail-closed

​Mapping failure to watch

Verification states

Basic UI gating

High-trust gating

Offline decision path

Fail-open versus fail-closed

Mapping failure to watch