IAP review information and screenshot checklist
An in-app purchase can be configured correctly and still stall review if the reviewer cannot understand or reach the paid value.
Treat every in-app purchase record as its own review packet. Apple documents creating and submitting in-app purchases in App Store Connect. AppReviewReady interpretation: product metadata, review screenshots, app state, paywall copy, and entitlement behavior should tell the same story before the app build is submitted.
Complete the product record
Start with the product record rather than the paywall. Confirm product type, reference name, product ID, display name, description, price, availability, review screenshot, and any localization needed for the storefronts where the purchase appears.
Do not leave internal names, placeholder descriptions, or test-only prices in the record. Reviewers compare the App Store Connect record with the app surface, and mismatched language makes the purchase look unfinished.
AppReviewReady interpretation: the product record is also an SEO and revenue asset because it defines the commercial promise that support, paywall copy, and entitlement code must honor.
Capture the right screenshot
- Show the actual in-app purchase surface, not a marketing graphic.
- Include the product name, price context, and what the user receives.
- Avoid unrelated debug controls, sandbox labels, or private account data.
- Use a current build state that matches the submitted binary.
- Refresh screenshots after paywall, entitlement, or localization changes.
Map review dependencies
Some purchases depend on login, subscription status, server configuration, product availability, regional pricing, or a feature flag. Write down exactly what the reviewer must do to reach the purchase and what state the demo account should have.
If the purchase is hidden behind an onboarding event, user-generated content, trial state, or account age, either supply a reviewer path or create a review-safe way to reach the same surface. Hidden commerce is a common source of avoidable review delay.
Separate Apple policy from operations: Apple controls App Review and App Store Connect submission requirements; AppReviewReady recommends the dependency map so a team can diagnose whether a problem is product configuration, app logic, or reviewer access.
Prove runtime behavior
- Install the submitted build on a clean device.
- Load products from App Store Connect rather than hardcoded fixtures.
- Complete purchase, cancel, restore, refund-like, and offline states where relevant.
- Verify entitlement state appears in UI, server, support, and analytics records.
- Update Review Notes when the purchase path needs account or server preparation.
IAP review packet
The packet prevents last-minute confusion when app review and IAP review happen together. It also makes support stronger after launch because the same record explains what the customer bought and where it should appear.
Use the packet as a release gate. If the screenshot, paywall, product record, and runtime behavior cannot be reconciled in one page, the purchase is not ready for review even if the code compiles.
After approval, compare product-level revenue and support tickets with the packet. A product that passes review but generates confusion may need clearer naming, better restore handling, or a different campaign route rather than another code change.
IAP review packet: Product ID: [id] Type: [type] Screenshot updated: [date] App path: [steps] Demo account state: [state] Entitlement proof: [signal] Owner: [team]
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 IAP review readiness
Review product records, screenshots, app paths, and entitlement proof before submission.
Open the tool