AppActor SDKs expose cached and offline-friendly reads so your app can behave sensibly when the network is unreliable.

What can be cached

Depending on platform, the SDK can expose:
  • cached offerings
  • cached remote configs
  • cached customer info
  • offline entitlement keys
  • fallback offerings bundled with the app

How to use it

Use cached state for fast UI and resilience. Use fresh reads when you need to confirm current access, recover purchases, or debug account state.

Important distinction

Cached state can keep the app usable, but it is not the same as fresh server-confirmed state. If support, account recovery, or billing correctness matters, trigger the explicit refresh or recovery path.

Read precedence

When the app asks for customer state, think in this order:
  1. Fresh server response with trusted verification.
  2. Signed cache or 304-validated state when the server confirms nothing changed.
  3. Transient stale cache if the network is temporarily unavailable.
  4. Offline-derived entitlement keys from trusted local store state.
  5. No access if none of the above can prove an active entitlement.
Use the lower levels for UX continuity. Use the top levels for support, backend access, or high-value unlocks.

Safe offline pattern

For strict access, combine offline state with Trusted Entitlements and Server-side Access Checks.