Flutter Data, Purchases, and Cache - AppActor

Flutter exposes most of the core purchase surface as straightforward Future methods.

Read surfaces

Use these methods regularly:

getOfferings()
getCustomerInfo()
activeEntitlementKeysOffline()
getCachedOfferings()
getCachedRemoteConfigs()
getCachedCustomerInfo()
canMakePurchases() when you specifically care about Android store readiness
getStorefront() for Android storefront state
getStoreCapabilities() for Android store capability checks

final offerings = await AppActor.instance.getOfferings();
final info = await AppActor.instance.getCustomerInfo();
final hasPremium = info.hasActiveEntitlement('premium');

Fallback offerings

If you bundle an offline fallback payload:

await AppActor.instance.setFallbackOfferings(jsonBytes);

Use this for first-launch resilience, not as a replacement for the real server catalog.

Purchase and recovery methods

Flutter keeps the wrapper parity surface explicit:

purchasePackage(...)
restorePurchases(syncWithAppStore: ...)
syncPurchases()
quietSyncPurchases() as a deprecated alias of syncPurchases()
drainReceiptQueueAndRefreshCustomer()

On iOS, the store-introspection helpers intentionally fall back to placeholder behavior:

canMakePurchases() returns true
getStorefront() returns null
getStoreCapabilities() returns an empty set

Treat those as wrapper compatibility defaults, not authoritative iOS storefront state.

Purchase options worth noticing

purchasePackage(...) can carry:

offeringId
oldPurchaseToken
replacementMode
quantity
placement

Those options matter most when you need direct control over replacement or attribution context on the wrapper side.