AppActor is best understood as a purchase infrastructure layer, not a visual paywall builder or a generic frontend component kit.

​
What AppActor owns

  • store-facing purchase verification and reconciliation
  • customer access state and entitlement evaluation
  • offerings and package catalog delivery
  • purchase recovery flows such as restore, sync, retry, and queue drain
  • Remote Config APIs
  • Experiment assignment APIs
  • customer profile context, custom attributes, integration IDs, and attribution helpers

​
What your app still owns

  • the paywall UI itself
  • package selection UX
  • access gating in the product experience
  • account and session logic outside the purchase layer
  • dashboard-level analytics interpretation and operational playbooks

​
Product shape across SDKs

The native iOS and Android SDKs are the core implementation surfaces. Flutter and React Native are thin wrappers over those native plugins, which means:
  • platform-specific capabilities still matter
  • feature rollout order often starts in native code
  • some helpers throw or no-op on unsupported platforms
  • wrapper docs must explain native behavior instead of hiding it

​
Canonical flow

  1. Configure the SDK with your public AppActor key.
  2. Establish or reuse identity, optionally with a stable appUserId.
  3. Fetch offerings and packages from AppActor.
  4. Render your own paywall and purchase a package.
  5. Read customerInfo and entitlements to decide access.
  6. Use restore, sync, or queue-drain paths when you need recovery behavior.

​
Why this matters for docs

Competitor-grade docs in this space are strongest when they stay honest about system boundaries:
  • there is no hidden hosted paywall runtime in these repos
  • identity lifecycle affects restore, cache, and attribution semantics
  • offline and cached state can influence user-facing access decisions
  • purchase recovery paths are similar in name but different in behavior
The rest of the docs are organized around those boundaries.