iOS Customer State and Offerings

Most host apps use two read surfaces over and over:

offerings for paywall rendering
customer info for access decisions

Offerings

let offerings = try await AppActor.shared.offerings(fetchPolicy: .freshIfStale)
let current = offerings.current
let annual = current?.annual

Key points:

offerings(fetchPolicy:) is the canonical catalog read
cachedOfferings returns the last resolved in-memory snapshot without forcing network work
setFallbackOfferings(from:) and setFallbackOfferings(jsonData:) let you bundle a first-launch offline fallback

Use fetch policy intentionally:

.freshIfStale waits for fresh data when cache is stale or missing
.returnCachedThenRefresh returns suitable cache now and refreshes in the background
.cacheOnly is for explicit cache-only flows and can fail if there is no usable local snapshot

Customer info

let info = try await AppActor.shared.getCustomerInfo()
let entitlementKeys = info.activeEntitlementKeys
let hasPremium = info.hasActiveEntitlement("premium")

getCustomerInfo() always aims for authoritative server state first, but it can fall back to offline-derived entitlement state when the failure is transient.

Offline reads

activeEntitlementKeysOffline() is the fast local fallback when you only need keys.

it uses local StoreKit state plus cached product-to-entitlement mapping
it is useful for temporary offline gating
it is not a replacement for authoritative sync when the network is available

Data model notes

AppActorCustomerInfo carries more than a simple boolean entitlement map:

entitlements
subscriptions
non-subscriptions
token and consumable balance context
management URL
verification status
isComputedOffline so you can tell when the snapshot was derived locally

If your access rules become complex, treat verification and isComputedOffline as first-class signals instead of only checking a single entitlement bit.

​Offerings

​Customer info

​Offline reads

​Data model notes

Offerings

Customer info

Offline reads

Data model notes