Guideline 3.1.1: In-App Purchase

3.1.1 is the guideline behind most payment rejections. The message:

Guideline 3.1.1 - Business - Payments - In-App Purchase

Your app unlocks or enables additional functionality with mechanisms
other than the App Store.

Specifically, your app includes a link to an external website where
users can purchase a subscription.

The rule in one line

Digital content and features consumed inside the app must be sold through in-app purchase. Physical goods and real-world services must not.

Both halves get people. Using IAP for a physical product is a rejection just as surely as not using it for a digital one.

What you're selling	Payment method
Premium features, filters, levels, an ad-free mode	In-app purchase
Subscriptions to digital content	In-app purchase
Digital currency, credits spent in the app	In-app purchase
Physical goods shipped to the user	Your own payment flow — not IAP
Real-world services (rides, food delivery, a consultation)	Your own payment flow
Person-to-person, one-off services	Your own payment flow

What counts as "other mechanisms"

The rejection above usually isn't about the payment sheet — it's about a link. Historically Apple's anti-steering rules meant that inside an app covered by 3.1.1 you could not:

• Show a button or link to a web page where the same content is cheaper
• Say "subscribe on our website to save 30%"
• Show a price that isn't the in-app purchase price
• Email users, using an address collected in the app, to sell them the same content outside it

This area changed in the US. Following the April 2025 contempt ruling in Epic v. Apple, Apple was required to allow US-storefront apps to link out to external purchase flows without commission and without the previous entitlement and scare-sheet requirements. It is a US-storefront change, it has been under continued appeal, and the operative rules have moved more than once. Before you build a link-out flow, read the current text of 3.1.1 and 3.1.3 rather than any blog post — including this one.

Outside the US, assume the classic anti-steering position still applies unless you've confirmed otherwise for that storefront.

The exceptions worth knowing

• Reader apps (3.1.3(a)) — apps whose only function is consuming content bought elsewhere: magazines, books, audio, video, cloud storage. They may let users access previously-purchased content without offering IAP, and can apply for the External Link Account entitlement.
• Multiplatform services (3.1.3(b)) — content bought on another platform can be used in your iOS app. You just can't sell it there without IAP.
• Enterprise and B2B (3.1.3(e)) — free apps for businesses where the service is sold outside the app.
• Free apps — an app with no paid digital content has nothing to route through IAP. Free trials are handled through StoreKit's introductory offers, not a homemade timer plus a web checkout.

Getting the submission itself right

Beyond the policy question, most 3.1.1 rejections have a mundane cause:

• The product isn't submitted. In-app purchases have their own review state. An IAP left in Ready to Submit while the version goes out means the reviewer taps your purchase button and nothing happens — which also collects you a 2.1 rejection.
• No restore path. Any non-consumable or subscription needs a visible Restore Purchases action. Its absence is a standalone rejection.
• The reviewer can't reach the paywall. Tell them how, in the review notes: which screen, which tap, what a sandbox purchase does.
• Subscription disclosure. A subscription paywall must state the length, the price per period, and what's included, and link your terms and privacy policy — in the app, not only in App Store Connect.

Catching it before you submit

AuditStore detects StoreKit in your sources — SKPaymentQueue, SKProduct, Product.products, Transaction.currentEntitlements, AppStore.sync — and when it finds any of them, emits guideline-iap: a Recommended row telling you 3.1.1 applies to this build, with the checks to run through before submitting. Compliance can't be proven from a token scan, so it prompts verification rather than claiming a pass — but it means you never submit a StoreKit app having forgotten the question exists.

If you ship subscriptions, the Subscriptions checks audit the App Store Connect side: groups, pricing, and localizations.

Related

• Subscriptions checks
• Review Guidelines checks
• Guideline 2.1: App Completeness — where an unsubmitted IAP lands you