Guideline 3.1.1 rejection: In-App Purchase
How the rejection usually reads: "Your app offers in-app purchases but does not include a mechanism to restore them" / "the app directs users to external purchasing mechanisms"
Why it happens
The two mechanical 3.1.1 rejections are a missing Restore Purchases path (required for any non-consumable or subscription) and links to Stripe, PayPal or your website for buying digital content. Both are visible in the binary: the restore call and the words "Restore Purchases" for the first, checkout URLs for the second. Paywall wording (price, period, terms) is the reviewer's call and belongs in your screenshots and listing.
What can be checked before you submit
2 of RejectProof’s checks map to Guideline 3.1.1. Each one reads your .ipa — no upload — and reports the evidence with a fix.
- In-app purchases without a "Restore Purchases" path
PB-14 · guideline 3.1.1 · probable
Add a "Restore Purchases" button to your settings or paywall screen — Apple requires it in every app with IAP. RevenueCat: add a button that calls Purchases.shared.restorePurchases(). Swift/StoreKit: AppStore.sync() or SKPaymentQueue.default().restoreCompletedTransactions().
- Possible external payment link for digital content
PB-15 · guideline 3.1.1 · warning
If you sell digital content or services you must use Apple's in-app purchase system; linking out to an external checkout is one of the most common rejection reasons. If you sell physical goods or services, this does not apply to you.
What a scan cannot tell you
Static checks read the build; they do not run it. Whether a reviewer likes your design, agrees with your content, or considers the app “sufficiently different” is their call. Fix the mechanical layer first so the human review is about your product, not about a missing plist key.