Testing Matrix
Do not ship based on one successful sandbox purchase.
Build setup checks
Before purchase testing:
- development build works on iOS and Android
- public SDK keys load correctly per platform
- app compiles with the chosen architecture
- at least one placement is active in Superwall
- products and entitlements exist in RevenueCat
- test users are ready in sandbox or test store as needed
Recommended environments
Early code validation
Use:
- development builds
- RevenueCat Test Store when appropriate
- mocked or internal analytics
Pre-release validation
Use:
- iOS sandbox or TestFlight test accounts
- Google Play internal testing or closed testing
- real purchase flows through store sandboxes
- backend logging if server notifications or webhooks matter
Scenario matrix
A. App startup
- cold start without auth
- cold start with known authenticated user
- cold start after reinstall
- full restart after changing Superwall placements or campaigns
Expected results:
- providers initialise once
- no duplicate purchase listeners
- no placement-not-found surprises after a restart
- entitlement sync runs once
B. Purchase flows
- successful purchase on iOS
- successful purchase on Android
- user-cancelled purchase
- network or store failure
- pending Android purchase
- purchase completes but entitlement is misconfigured
Expected results:
- success unlocks the correct entitlement
- cancellation is not shown as success
- pending does not falsely unlock premium access
- misconfigured entitlements are visible in logs and UI state
C. Restore flows
- explicit Restore Purchases button tapped by a guest user
- restore on a signed-in user
- restore after reinstall
- restore when transfer behaviour matters across two accounts
Expected results:
- restore is user-triggered
- entitlement state updates correctly
- account ownership behaviour matches the chosen RevenueCat restore policy
D. Identity transitions
- guest uses app, then logs in
- user A signs out to guest state
- user A switches directly to user B
- login-first app launches with custom ID from the start
Expected results:
- same ID is used in RevenueCat and Superwall
- direct account switch does not create unnecessary anonymous IDs
- support can inspect the active billing identity
E. Webhook and attribution checks
Only for projects that need them.
- make a fresh purchase after
identify() - inspect backend webhook or server-notification payload
- compare app identity, RevenueCat App User ID, and server-observed identifier
- repeat with Android if Play-side identifier passthrough matters
Expected results:
- backend identifiers match the intended user model
- UUID expectations are met on iOS
- historical purchases made before the identity fix are understood and documented
Release gate
Before sign-off, the project should be able to answer:
- which architecture is in use and why
- whether guest purchases are allowed
- which restore behaviour is configured in RevenueCat
- whether webhooks and server notifications rely on UUID billing IDs
- which entitlements unlock which features
- how support staff can find a user's App User ID