An iOS subscription paywall should identify the subscription, show the billing period and localized price clearly, explain what the user receives, link to the Terms of Use and Privacy Policy, and expose restore for restorable purchases.
Review the screen as a purchase contract and a test surface. The displayed product data, legal links, purchase action, and entitlement result must all agree with App Store Connect.
The workflow below was checked against App Review Guidelines and Auto-renewable subscription information on 4 August 2026. The first source controls the rule or workflow; the second supports the article-specific implementation boundary.
The short version
- Show the product or plan name.
- Show the full charge and billing period near the purchase action.
- Explain the paid entitlement without vague “premium” language.
- Provide working Terms of Use and Privacy Policy links.
- Provide a visible restore path for restorable products.
The iOS subscription and in-app purchase review guide maps the complete paid-release chain. This page narrows that chain to the information and controls visible on the paywall, so you can audit the screen without repeating product submission or entitlement setup.
Show the actual offer clearly
Display the plan name, billing duration, localized store price, and the amount that will be charged. If you also show a monthly equivalent for an annual plan, keep the annual commitment at least as clear. Pull the price and period from the store product wherever possible to reduce mismatches.
Explain what changes after purchase
Name the features, content, or service the entitlement unlocks. Avoid a list of broad adjectives. A reviewer should be able to complete the purchase and verify the result in the next screen. Keep free and paid states consistent with the App Store description.
Make policy links functional
Use a real Terms of Use document and a real Privacy Policy. If you rely on Apple’s standard EULA, link to the current Apple document where appropriate for your setup. Test both URLs from the built app. This guide covers review presentation, not whether your legal text is sufficient for your business.
Place restore where users can find it
Restorable products need an understandable recovery path. Add Restore Purchases near the paywall footer or purchase management area, call the correct store mechanism, and show the result. The label alone is not enough.
Audit remote paywalls after release changes
A remote paywall can change independently from the binary, which is useful but risky. Capture the exact configuration reviewed with the build, verify links and product mappings, and ensure the fallback screen remains compliant if remote content fails to load.
Run the first checks in order
Work through these checks without changing two layers at once. A clean sequence makes the next decision defensible:
- Show the product or plan name.
- Show the full charge and billing period near the purchase action.
- Explain the paid entitlement without vague “premium” language.
- Provide working Terms of Use and Privacy Policy links.
- Provide a visible restore path for restorable products.
- Use live StoreKit data and test every tap on device.
When a check fails, stop and record it. Fixing App Store Connect, the binary, and a third-party dashboard simultaneously destroys the evidence that tells you which change mattered.
Choose the next action
| What you find | Next action | New build? |
|---|---|---|
| Product or submission metadata is incomplete | Complete the item and add it to the intended draft submission | Usually no, unless the binary also changes |
| The submitted build has the wrong identifier, key, UI, or purchase logic | Correct the app, test the archive, and upload another build | Yes |
| The setup is correct but the reviewer could not reach the flow | Improve Review Notes and provide reproducible evidence | Usually no |
| Apple’s message conflicts with the tested configuration | Ask for precise clarification and identify the build and product IDs | No, until a defect is identified |
Do not appeal a reproducible defect. Do not upload a replacement binary when the only issue is a missing item in a draft you can still edit. The rejection message, current statuses, and your controlled test should choose the branch.
Failure patterns to look for
- A monthly equivalent is more prominent than the actual annual charge.
- Price or period is hardcoded and no longer matches the store.
- Terms links are decorative text or open a dead page.
- Restore exists only as background logic.
Use those paywall patterns to inspect your own screen, not to infer rejection frequency. The AppRejectKit corpus supplies the prompts; Apple’s current disclosure and subscription rules decide whether the resulting screen is acceptable.
Write App Review Notes as a test script
Give the reviewer a path they can follow without interpreting your product. Include the exact app version, build number, product identifiers, any demo credentials, the taps from launch to the paywall, and the result expected after purchase or restore.
Keep the note factual. Say what you tested and where the control appears. Do not promise that the environment will behave identically for every account or imply that a recording replaces a working submitted flow.
A useful structure is:
- Build and product identifiers.
- Entry path from launch.
- Account or state required.
- Purchase or restore action.
- Visible result after the transaction.
What not to change blindly
Avoid recreating products, rotating identifiers, or changing purchase types before you know which object failed. Those changes can create new metadata and entitlement work while leaving the original cause untouched.
Also avoid copying an App Store Connect path from an undated tutorial. Apple changes labels and submission workflows. Use the official help page linked in this article, then describe the labels you actually see in your own account.
Verification note: Rule-sensitive claims in this article were checked against the linked Apple documentation on 4 August 2026. Apple can change App Store Connect labels and review requirements, so recheck the sources before publication or a later resubmission.
FAQ about iOS paywall requirements
Does this always require a new build?
No. A code, UI, identifier, or release-configuration change requires another binary. Product metadata, submission assembly, or a clearer reply may not. Base the decision on the failed layer.
Can a successful sandbox test guarantee App Review approval?
No. It proves a controlled purchase path worked in the environment and build you tested. App Review also evaluates product rules, disclosures, access, metadata, and the submitted item set.
Should I delete and recreate the product?
Only after you have evidence that the product record itself is unusable and Apple’s support path cannot resolve it. Recreating a product changes identifiers and can add more configuration work.
What evidence should I send to App Review?
Identify the app version, build number, product IDs, exact test path, account state, and visible result. A short recording can support the explanation, but the submitted flow still needs to work.
Conclusion
Review the screen as a purchase contract and a test surface. The displayed product data, legal links, purchase action, and entitlement result must all agree with App Store Connect.
Take the smallest action supported by the item statuses and a test of the exact build. Keep the evidence with your reply so the next review starts from facts rather than another guess.
Sources and references
- App Review Guidelines: accessed 4 August 2026.
- Auto-renewable subscription information: accessed 4 August 2026.
- Apple Standard EULA: accessed 4 August 2026.
- StoreKit AppStore.sync(): accessed 4 August 2026.