StoreKit sandbox testing checklist
Sandbox testing is valuable only when each test state maps to a production entitlement rule.
Create a sandbox-to-production entitlement map before relying on StoreKit tests. Apple documents testing in-app purchases with sandbox and StoreKit transactions. AppReviewReady interpretation: sandbox QA should prove how the app and server will unlock, revoke, restore, and explain access.
Prepare sandbox accounts and products
Create test accounts that represent new buyer, returning buyer, expired subscriber, refunded user, family member, and wrong-region user. Map each account to one product and one expected entitlement state.
Do not use sandbox success as proof unless the same server path, product IDs, and entitlement logic will be used for production.
Test every revenue state
- Initial purchase, restore, upgrade, downgrade, renewal, expiration, billing retry, grace, refund, revoke, and failed transaction.
- Device switch, account switch, reinstall, deleted app account, and offline launch.
- Server delay, duplicate transaction, missing notification, and stale cached entitlement.
- Localized price display and paywall copy.
- Support explanation for users whose access changed unexpectedly.
Compare app and server truth
The app should not unlock from a local flag while the server denies access, or vice versa. Define which system is authoritative and how conflicts are resolved.
AppReviewReady interpretation: most StoreKit support pain comes from inconsistent entitlement truth, not from the purchase sheet itself.
Turn sandbox results into review evidence
- Record product IDs, sandbox accounts, and expected states.
- Confirm the reviewer can see paid value without production payment confusion.
- Retest after product, price, subscription group, or server changes.
- Keep support macros aligned with each tested state.
- Archive failures that require App Store Connect configuration changes.
Sandbox parity matrix
The matrix turns sandbox testing into launch evidence instead of a collection of screenshots.
After launch, compare real support issues with missing sandbox cases. Add any untested state to the next release gate.
Keep sandbox tests separate from production analytics. Test purchases, accelerated renewals, and artificial states should not leak into revenue dashboards or growth decisions.
When a StoreKit issue is fixed, rerun the whole affected entitlement path rather than only the failed purchase. A restore, refund, or device switch can still break after the happy path succeeds.
For teams with client apps, keep reusable sandbox scenarios. StoreKit bugs repeat across products when the same server pattern is copied.
When a sandbox account behaves unexpectedly, reset the test case rather than rewriting the product rule from one confusing result. Sandbox testing is a model of production, not production itself.
Document which accelerated sandbox timing maps to which production lifecycle. Support and product owners often misread sandbox renewals unless the mapping is written down.
If sandbox and production products differ, stop and fix configuration first. Parallel product names invite false confidence.
Keep a failed-case library. It speeds future checkout investigations.
Sandbox test: Product/state: [name] Account: [type] Expected app access: [result] Expected server access: [result] Notification/API dependency: [yes/no] Support message: [copy] Production rule: [mapping]
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Check StoreKit sandbox coverage
Review sandbox accounts, purchase states, server parity, and support evidence before launch.
Open the tool