Devoria
Guideline 3.1.1: When In-App Purchase Is Required
By Mehdi Azizi
Published , 9 min
Guideline 3.1.1: any digital content or feature unlocked in your app must use Apple's in-app purchase. Exceptions, EU and US rules, and fixes.
Guideline 3.1.1 requires Apple's in-app purchase as soon as your app unlocks digital content or a digital feature: a subscription, the full version, in-game currency, premium content. A 3.1.1 rejection means Apple found another way in to that content: payment on your website, a license key, a homemade code, a button to a payment page. The fix goes through in-app purchase, unless your case falls under an exception or a regional rule.
I publish my own iOS apps, and the ones with a subscription sell it through Apple's in-app purchase. I've never had a 3.1.1 rejection, and I won't pretend otherwise. This guide is based on the official text, in its June 8, 2026 version read on October 15, 2026, and on the regional terms published by Apple. The related subscription case, with two real rejections, is in the guide on guideline 3.1.2.
What does guideline 3.1.1 say?
3.1.1, "In-App Purchase," opens section 3.1 "Payments" of the App Review Guidelines. That's where the email subject comes from: "Guideline 3.1.1 - Business - Payments - In-App Purchase." Its first sentence says it all: to unlock features in your app, "you must use in-app purchase." Apple lists subscriptions, in-game currencies, game levels, premium content and the full version.
The next sentence targets workarounds. An app can't use its own mechanism to unlock content: Apple names license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets.
The same rule adds obligations people often forget:
- credits and currencies bought with in-app purchase don't expire, and any restorable purchase has a restore mechanism;
- a paid chest or draw ("loot box") shows the odds of getting each type of item before purchase;
- a digital gift card, voucher or coupon sold in the app goes through in-app purchase; a physical card sent by mail can use another method;
- an app without a subscription can offer a time-limited trial, as a free in-app purchase named "XX-day Trial," which states before it starts its duration, what will be lost and what you'll have to pay;
- tips to the developer are allowed, through in-app purchase.
Situations that trigger a 3.1.1 rejection
| What the app does | Why Apple rejects it | The fix |
|---|---|---|
| Unlocks content bought on your website | No equivalent in-app purchase | Sell it through in-app purchase too |
| Shows "Pay on our website" | Points to another payment | Remove the button, unless exempt |
| Asks for a license key or homemade code | Forbidden unlock mechanism | Apple's offer codes |
| Unlocks with cryptocurrency | Forbidden unlock mechanism | In-app purchase |
| Sells credits that expire | 3.1.1 obligation | Permanent credits and restore |
| Sells a loot box without odds | Odds not shown | Odds visible before purchase |
The first row is the most misunderstood. In a rejection posted on Apple's forums, the message says the app "accesses digital content purchased outside the app," "but that content isn't available to purchase using in-app purchase." Apple isn't objecting to you having a website that sells: it objects that the app doesn't offer the same purchase through Apple.
To offer free access or a discount, Apple has its own system: offer codes. According to the StoreKit documentation, they work for all in-app purchase types: subscriptions, consumables and non-consumables. You create them in App Store Connect, and users redeem them in the App Store or in your app.
Exceptions: when in-app purchase isn't required
Rule 3.1.3 lists the apps that can use another payment method. Here's the grid I use to figure out where a project fits.
| Your case | In-app purchase required? | Rule |
|---|---|---|
| Subscription, full version, digital content | Yes | 3.1.1 |
| Physical product, service consumed outside the app | No, another method is mandatory | 3.1.3(e) |
| Live one-on-one class or consultation | No | 3.1.3(d) |
| Live group class | Yes | 3.1.3(d) |
| News, books, music, video bought elsewhere | Not to access them | 3.1.3(a) |
| Multiplatform service bought on your website | Access allowed if also sold in-app | 3.1.3(b) |
| Tool sold to a company for its employees | No | 3.1.3(c) |
| Free companion app to a web tool, no purchases | No | 3.1.3(f) |
Two limits. An app that benefits from an exception can't, inside the app, push users to another payment method, except on the US storefront and in cases Apple provides for. On the other hand, Apple specifies that "Developers can send communications outside of the app": you can contact your users outside the app, by email for example.
Rules by region in October 2026
This is where the texts change fast. What follows reflects Apple's texts as read on October 15, 2026: reread them before you code an external payment.
| Region | What's allowed on top of in-app purchase |
|---|---|
| United States | Buttons and links to another payment, no entitlement |
| European Union | Alternative in-app payment and out-of-app offers, with rules |
| Japan, Brazil, South Korea | Their own programs, entitlement on request |
| Other countries | No button, link or call to action to another payment |
United States
Rule 3.1.1(a) states that entitlements "are not required for developers to include buttons, external links, or other calls to action in their United States storefront apps." So on the US storefront, a button to your website is allowed. Your binary is the same everywhere: if you add that button, the app has to know which storefront the user is on. StoreKit gives you that with Storefront.
European Union
New terms have applied since October 1, 2026, according to Apple's page on payment options in the EU. You can stick with in-app purchase alone and change nothing. You can also offer a payment provider in the app, or offers outside the app, on your website for example. Apple then requires, among other things:
- the "StoreKit External Purchases or Offers" entitlement and, for a link or payment in the app, the system disclosure sheet;
- in-app purchase at least as visible as the other option when both are on screen;
- no mention of these payments on your App Store product page;
- parental controls for minors, and no out-of-app offers under 13, or older depending on the country;
- the same choice across all EU storefronts for 12 months.
Fees apply depending on the option you choose. Read their section on the same page before deciding.
Other countries
Everywhere else, the rule stays strict: "apps and their metadata may not include buttons, external links, or other calls to action" to another payment method. The word "metadata" matters: a description saying "cheaper on our website" falls under the rule too. Some countries, including Japan, Brazil and South Korea, have their own programs, listed in the External Purchase documentation.
Fixing a 3.1.1 rejection and replying to Apple
- Find the way in. The message names the content or screen at fault: content bought elsewhere, a button, a code, a link.
- Close it or duplicate it. Either you remove the button or code, or you sell the same content through in-app purchase.
- Only claim an exception if it's real. Cite the 3.1.3 subsection and explain in two sentences why your case fits.
- Give the reviewer something to test. A demo account and the path to the paywall, in the review notes, as I explain in the guide on guideline 2.1.
You reply in the App Review section of App Store Connect, following the procedure to reply to App Review. Here's a template for the most common case, content bought on the website. It's an example: replace the build, product and flow with yours.
Hello,
Thank you for your review.
Issue: the app gave access to premium content purchased on our
website, without offering the same purchase in the app.
Fix in build X:
- Premium access is now available as an auto-renewable
subscription through in-app purchase, on the paywall.
- The "Subscribe on our website" button has been removed.
- A "Restore Purchases" button is available on the paywall.
How to verify: launch the app and open any premium screen.
The paywall shows the in-app purchase options.
Best regards,
The button and the paywall live in the code: you need a new build. If you're still convinced your case is an exception, Apple also lets you appeal to the App Review Board.
Adding in-app purchase without rewriting everything
For a beginner, the simplest path is to create the products in App Store Connect, then connect them to the app with RevenueCat: the recipe is in RevenueCat: setting up an in-app subscription. If you're torn between the two models, read subscription or one-time purchase. If you're building with a no-code tool, check that it handles in-app purchase: it's one of the points in build an app without coding.
As soon as your in-app purchase is a subscription, 3.1.2 kicks in too: billed amount up front, duration, renewal, links. The most common screen mistakes are in iOS paywall: 7 beginner mistakes.
The 3.1.1 checklist before submission
- Everything that unlocks in the app (feature, content, level, currency) is bought through in-app purchase.
- No button, link or text points to an external payment, except on the US storefront or with a regional program you've been granted.
- Your product page description mentions no other payment method.
- Content sold on your website is also for sale through in-app purchase in the app.
- No license key, QR code, homemade code or crypto unlocks anything.
- To give access, you use Apple's offer codes.
- Purchased credits don't expire, and a "Restore Purchases" button works.
- Every paid loot box or draw shows its odds before purchase.
- A physical product or a service outside the app goes through Apple Pay or a card, not in-app purchase.
- Your review notes say where to find the purchases and, if you claim an exception, which one.
Check your app before sending it
If your app was just rejected under 3.1.1, the Apple Review Kit helps you find the cited rule, what it asks for, and an example fix and reply. Its tester notes cover in-app purchase. For a human eye, book an hour with me: we read Apple's message and look for the way in it spotted. The full process is on the app rejected by Apple page, and setting up purchases on the iOS in-app subscription page.
If you're preparing your first release, take your free diagnostic: it puts the steps in order and sends you my Apple anti-rejection checklist. To build a mobile app that sells through in-app purchase from day one, the iOS Kit starts from code where the paywall and subscriptions are already in place.
Nobody can guarantee Apple will accept your app. What I can do is help you pick the right payment method before you write the code.
Frequently asked questions
What does "Guideline 3.1.1 - Business - Payments - In-App Purchase" mean?
It's the full title of the in-app purchase rule in Apple's message. It means your app gives access to digital content or a feature through a path other than in-app purchase: payment on a website, a code, a license key or a link to a payment page.
Can I add a link to my website so users pay less?
On the US storefront, yes: the rule allows buttons and links without an entitlement. In the European Union, it's possible with Apple's entitlement and its terms. Elsewhere, unless there's a regional program, neither the app nor its product page can point to another payment method.
Can I unlock my app with a promo code?
Not with a homemade code: 3.1.1 forbids an app's own unlock mechanisms, like license keys. Use Apple's offer codes, created in App Store Connect. They work for subscriptions and for other in-app purchase types.
Do I need in-app purchase to sell a physical product or a service?
No. A physical product or a service consumed outside the app, like a delivered meal or a ride, must go through another payment method, Apple Pay or a bank card. A live one-on-one class can skip it too, but not a live group class.
Can a customer who subscribed on my website log in to the app?
Yes for a multiplatform service, as long as the same access is also for sale through in-app purchase in the app. That's rule 3.1.3(b). Without that in-app offer, you're back to the classic 3.1.1 rejection: content bought elsewhere that can't be bought through Apple.
Is RevenueCat enough to comply with 3.1.1?
RevenueCat is built on Apple's in-app purchase, so it doesn't create a 3.1.1 problem. But it won't remove an external payment button or a homemade code your app might contain. You still have to check compliance screen by screen, and on your product page.
