Sandbox/test environment configured for IAP testing
Why it matters
Shipping IAP with no sandbox configuration means the purchase flow has never actually run end-to-end without a real card charge. Any regression in product ID casing, entitlement mapping, receipt validation, or SDK key selection ships straight to production, where the first signal is a user support ticket or a drop in activation-to-subscription conversion. A .storekit file or an environment-split RevenueCat/Adapty/Qonversion key turns this into a local test that runs on every build instead of a launch-week fire.
Severity rationale
Low because sandbox gaps cause launch-time regressions rather than runtime failures for paying users in production.
Remediation
Add a StoreKit configuration file in Xcode (File → New → File → StoreKit Configuration File) that mirrors your App Store Connect products, and wire it into the Run scheme under Edit Scheme → Run → Options → StoreKit Configuration. Then split IAP SDK keys by build configuration so sandbox and production cannot cross-contaminate:
#if DEBUG
Purchases.logLevel = .debug
Purchases.configure(withAPIKey: "appl_sandbox_key_here")
#else
Purchases.configure(withAPIKey: "appl_production_key_here")
#endif
Provision sandbox Apple IDs under Users and Access → Sandbox Testers, and use android.test.purchased for early Play Billing smoke tests.
DetectionPro
The detection method for this pattern is part of AuditBuffet Pro.
The full method (what to look for, pass and fail conditions, and how results get reported) ships inside the App Store IAP & Subscriptions Audit. The pattern definition, severity rationale, and remediation remain openly licensed under CC-BY-4.0.
Taxons
History
- 2026-04-18·v1.0.0·Initial import from app-store-iap-subscriptions·automated