Does Apple Force You to Use In-App Purchase? Guideline 3.1.1 for Web-Based Apps (2026)

Last updated: July 2026

Apple's Guideline 3.1.1 generally requires native iOS apps selling digital goods to use In-App Purchase (IAP). But web-based apps — true PWAs running in Safari — are exempt. Hybrid apps with a native shell are not. The 2024–2026 rule changes created new external purchase link options, but only under specific conditions.

You've built something. Users love it. Then App Review drops a 3.1.1 rejection, and suddenly you're reading a policy document written by lawyers trying to reason about software categories that didn't exist when the App Store launched. This post explains exactly what the rule covers, what changed between 2024 and 2026, and who is genuinely exempt — particularly if your app lives somewhere on the spectrum between "pure native" and "it's basically a website."

What Is Apple's Guideline 3.1.1?

Apple's Guideline 3.1.1 is the App Store rule that requires apps to use Apple's In-App Purchase system — and pay Apple's 15–30% commission — whenever they sell digital content, subscriptions, or unlock features inside an iOS or iPadOS app. It is one of the most enforced and most misunderstood rules in the App Store.

The Core Rule in Plain English

In simple terms: if your iOS app offers something digital for sale and a user can buy it from within the app, that transaction must go through Apple's IAP system. No Stripe. No PayPal. No rolling your own checkout. IAP or nothing.

A few important distinctions that trip developers up:

• Selling vs. displaying. Showing content is fine. Charging for access to it inside the app is the trigger.
• IAP is mandatory, not optional. Apple actively rejects apps that route around it for covered transactions. This isn't a best practice — it's a hard requirement.
• The commission is 30% for most developers, 15% for those in the Small Business Program (apps earning under $1M annually in the prior year).

Apple's guidelines state that apps must use IAP for "digital content, functionality, or services" — check developer.apple.com for the current exact wording, as the language has been updated in recent years.

What Counts as a "Digital Good or Service"?

Here's where things get concrete. The rule isn't about how your app is built — it's about what you're selling.

Must use IAP:

• Subscription access to premium features
• Unlocking content inside the app (articles, levels, tools, filters)
• Virtual currency, tokens, or credits
• Digital media consumed inside the app — ebooks, video, music
• Consumable and non-consumable in-app items

IAP not required:

• Physical goods shipped to the user (e-commerce)
• Real-world services: Uber rides, food delivery, freelance bookings
• Business-to-business enterprise software invoiced externally
• Free apps with no monetization
• Donations to registered nonprofits

Quick reference: Does this require IAP?

The "maybe" row is where most of the complexity lives — and it points directly to the web-app question.

Who Does Guideline 3.1.1 Actually Apply To?

Guideline 3.1.1 applies to any app distributed through the Apple App Store that sells digital goods or services. Exemptions exist for physical goods sellers, real-world service providers, reader apps with approved entitlements, and — crucially — true web apps that never enter the App Store at all.

Apps That Must Use IAP

• Native iOS / iPadOS apps selling any digital good
• Subscription SaaS tools, content platforms, and membership apps
• Apps with virtual economies or premium unlock gates
• Cross-platform apps (React Native, Flutter) where the iOS version offers in-app purchases

The rendering engine is irrelevant here. If it's in the App Store and sells digital goods, IAP applies.

Apps That Are Exempt

Four clean categories:

1. Physical goods and services — e-commerce, restaurant ordering, ride-hailing apps where value is delivered in the real world
2. Enterprise / B2B apps — software invoiced outside the app with no in-app purchasing at all
3. Free apps with no IAP — no monetization, no requirement
4. Approved entitlement holders — Reader App entitlement, External Purchase Link entitlement (more on these below)

The Reader App Exception

The Reader App exemption gets its own section because it's frequently misapplied.

A "reader app" under Apple's rules is an app whose primary purpose is consuming content that the user purchased or subscribed to somewhere else. Think: a magazine app where you manage your subscription on the publisher's website. The categories Apple recognizes: magazines, newspapers, books, audio, video, music, and cloud storage.

What the Reader App entitlement allows: a single external link to your own website for account creation or subscription management.

What it does not allow: showing the external price inside the app, comparing prices side-by-side with IAP options, or directing users to an external purchase page mid-funnel. It's an account management link, not a sales funnel.

Familiar examples: Kindle, Spotify, and Netflix have historically operated under variations of this model, though their specific approaches have evolved as the rules changed. Apple expanded this entitlement globally in 2022. To apply, check the current form in App Store Connect — the process and fields change periodically, so verify the current requirements rather than relying on any third-party summary including this one.

Web-Based Apps: The Category That Confuses Everyone

Here's the taxonomy Apple actually uses, which differs from how most developers think about it:

• A website accessed in Safari — not an App Store app, not subject to 3.1.1
• A PWA added to the Home Screen via Safari — still not an App Store app, still not subject to 3.1.1
• A webview-wrapped native app submitted to the App Store — absolutely subject to 3.1.1

The wrapping, not the rendering, is what matters. The next section goes deeper.

What Changed in 2025–2026

Between 2024 and 2026, three forces reshaped Apple's IAP rules: a US federal court order from the Epic v. Apple case, the EU's Digital Markets Act enforcement, and Apple's own rule updates in response. Developers now have more options than before — but the rules differ significantly by geography and app type.

The Epic v. Apple Court Order

Epic sued Apple in 2021 over App Store billing practices. The court didn't hand Epic everything it wanted, but it did require Apple to allow developers to include an external purchase link in US App Store apps.

Apple's compliance took the form of the StoreKit External Purchase Link Entitlement — a formal application process that grants eligible apps permission to include one link to an external purchase page.

The initial compliance was contentious: Apple required a 27% commission on external purchases made through that link, which critics argued defeated the purpose. That commission requirement underwent further scrutiny in 2025. As of publication, verify the current commission terms at developer.apple.com — this has been one of the faster-moving elements of the policy landscape.

The key point for developers: the Epic ruling changed the link rule, not the IAP mandate itself. Apple's core requirement that digital goods be sold through IAP remains; the ruling just created a narrow, entitlement-gated path to also offer an external option.

The EU Digital Markets Act

DMA enforcement for iOS began in March 2024 after the EU designated Apple as a gatekeeper platform. For developers, the practical effect is significant:

• Alternative app marketplaces are now allowed in the EU — third-party stores can distribute iOS apps
• Alternative payment methods are permitted inside apps distributed in the EU
• Web distribution of iOS apps (notarized by Apple, EU-only) creates a different compliance path than the App Store

Apple introduced the Core Technology Fee (CTF) as part of its DMA compliance framework — a per-install fee applied to apps using alternative distribution. The CTF has been controversial and its terms have evolved; check the current structure at developer.apple.com before planning around it.

The practical result: a developer serving both US and EU users may need two entirely different billing architectures for the same app. That complexity is now a routine part of global App Store compliance.

Timeline: Key Events Affecting Guideline 3.1.1

Does Apple Actually Force Web-Based Apps to Use In-App Purchase?

The direct answer: it depends entirely on how your "web-based app" is distributed. A true web app that users access through Safari without an App Store listing is completely outside Apple's billing jurisdiction. The moment you wrap that web experience in a native shell and submit it to the App Store, Guideline 3.1.1 applies.

True PWAs Running in Safari: No IAP Required

A Progressive Web App accessed via Safari is not an App Store app. Apple has no jurisdiction over its billing. Users can subscribe, pay, and purchase through any payment processor you choose — Stripe, PayPal, your own checkout, anything.

The tradeoffs are real though. PWA capabilities on iOS remain more restricted than native apps: push notifications have limitations, background processing is constrained, and hardware access is narrower. If those limitations don't block your use case, going PWA is a legitimate way to sidestep the IAP question entirely — and many developers have done exactly that. See our [PWA capabilities on iOS guide] for a full breakdown of what's available.

Webview-Based "Hybrid" Apps: The Gray Zone

A native iOS app whose primary UI is a WKWebView loading content from your server is still a native iOS App Store app. Apple's position is unambiguous: if the app is in the App Store and sells digital goods, IAP applies — regardless of whether the UI is rendered from a webview.

Guideline 4.2 is often cited alongside 3.1.1 here. Apple can reject apps that are "simply websites bundled in an app container" for minimum functionality reasons — and then also reject them for 3.1.1 violations if they charge for digital goods through the webview.

A practical example: an app that loads app.yoursite.com full-screen in a webview but charges for subscriptions through a Stripe checkout embedded in that web content. That's a 3.1.1 violation. The fact that the subscription page lives on your server doesn't move it outside App Store jurisdiction.

The misconception to kill: "it's just a website, so IAP doesn't apply." Not if it's in the App Store.

React Native and Flutter: Same Rules Apply

A React Native or Flutter app is treated as a native app by Apple — the underlying rendering engine doesn't change the guideline scope. If it's submitted to the App Store and offers in-app purchases, IAP is required.

Apple reviewers also actively look for inconsistencies: apps that offer features or subscriptions on the web but restrict or omit them inside the app raise flags. The "back door" problem — keeping a purchase flow accessible through the webview's navigation while routing iOS users through IAP — is something review teams specifically test for.

The One Legitimate Workaround: Don't Charge In-App

There is a clean, Apple-sanctioned path that many SaaS tools and B2B platforms use: complete the entire purchase journey on your website before the user ever opens the app.

If a user subscribes and pays on your website, then installs your app to access what they've already paid for, IAP may not be required. The app is delivering a service, not selling one.

The critical caveat: the app must not solicit or prompt the user to upgrade or subscribe inside the app. Any in-app prompt that leads toward a purchase — even something as subtle as "upgrade your plan" with a button — can trigger 3.1.1. "Freemium unlocked by external subscription" is a valid architecture if implemented carefully: the app detects the user's subscription status, unlocks features accordingly, and never surfaces a purchase path within the app itself.

Step-by-Step: Does Your App Need In-App Purchase?

Use this six-step process to determine whether your app must implement Apple's In-App Purchase system, whether you qualify for an exemption, and what your compliant billing architecture should look like.

Step 1: Identify your distribution model.

• App Store → 3.1.1 applies; continue
• True PWA / Safari web app → 3.1.1 does not apply; you're done
• EU alternative marketplace → Different rules apply; see the DMA section above
• Enterprise app distributed via MDM → Generally exempt from App Store guidelines

Step 2: Map every monetization event in your app.

List every way your app generates revenue. For each one: is the transaction triggered inside the app or outside (web, phone, in-person)? If a digital item is offered for sale through your iOS app, IAP is almost certainly required.

Step 3: Check whether you qualify for an exemption.

• Physical goods or real-world services → Exempt
• Reader app (consuming pre-purchased content) → Apply for Reader App entitlement
• Enterprise / B2B invoiced externally → Likely exempt; document this clearly
• All purchase flows originate on the web and app only delivers → Potentially exempt (see the workaround section above)

Step 4: Assess your users' geography.

• US users: External Purchase Link Entitlement available, with specific UI and commission requirements
• EU users: DMA-compliant alternative billing available, with specific disclosure requirements
• Rest of world: Standard 3.1.1 rules apply

If you serve all three regions, build a compliance matrix. A single global billing architecture may not satisfy both the US and EU regimes simultaneously.

Step 5: Apply for the right entitlement, if applicable.

Reader App Entitlement: apply through App Store Connect. Include your app description, content type, and why it qualifies as a reader app. Review typically takes 2–4 weeks. Check the current form for required fields — these change and third-party guides go stale.

External Purchase Link Entitlement (US): your app must already be live. Apple provides the required disclaimer language for the external link button — use it verbatim.

EU alternative billing: work through your alternative marketplace or Apple's DMA compliance tools.

Step 6: Implement a compliant purchase flow.

• IAP: use StoreKit 2 — see our [StoreKit 2 implementation guide]
• External link: one button, Apple-approved wording, required disclosure screen before user exits the app, no price comparisons
• Reader App exemption: link to account management only, not a purchase page
• Web-only billing: ensure the in-app experience never surfaces pricing or upgrade prompts

QA it as a reviewer would: create an account, navigate through the app, and browse any in-app webviews for non-IAP billing flows before you submit.

Using External Payment Links in 2026: What's Actually Allowed

As of 2024, US App Store developers can include a single external payment link in their apps under the StoreKit External Purchase Link Entitlement. EU developers have broader options under DMA-compliant alternative billing. Both paths come with strict requirements Apple enforces through app review.

The StoreKit External Purchase Link Entitlement (US)

What it permits: one link or button in the app that sends users to your external website to complete a purchase.

What Apple requires:

• Specific button language — check the current entitlement documentation for the approved wording; Apple has specified exact phrasing (e.g., "Go to [Developer Name] website") and this should not be paraphrased
• Specific placement requirements
• A mandatory Apple disclosure screen informing users they're leaving the App Store's protections before the link activates

What you cannot do:

• Compare prices between your external option and IAP
• Mention savings relative to IAP pricing
• Show the external price inside the app

Commission question: Apple's position on whether commissions apply to purchases made via this external link has been actively litigated and updated. Verify the current commission terms at developer.apple.com before building your economics around this path.

EU Alternative Billing Under the DMA

Apps distributed in the EU App Store or via notarized alternative marketplaces can offer alternative payment methods. Apple's DMA compliance framework offers two paths: a "linking out" solution (similar in concept to the US external link) and an "alternative payment provider" solution that allows in-app alternative billing.

EU users must be shown specific disclosure language about their DMA rights. The Core Technology Fee applies in certain alternative distribution scenarios — check the current terms, as they've been revised since the initial 2024 rollout.

How to Add an External Link Without Getting Rejected

Common rejection triggers under this entitlement:

• Button wording doesn't match Apple's required language exactly
• Placement violates Apple's UI guidelines for the entitlement
• The destination page promotes alternatives to IAP or compares prices
• The app wasn't live before applying for the entitlement

Test with TestFlight before submission and screen-record the entire purchase flow. If you're appealing a rejection, that recording is useful context for the review team.

6 Mistakes That Lead to 3.1.1 Rejections

Most App Store rejections under Guideline 3.1.1 aren't from intentional rule-breaking — they're from six recurring misconceptions about what the rule covers, who is exempt, and how Apple's reviewers actually test for violations.

Mistake 1: Assuming "web-based" automatically means IAP-free.
Submitting a webview app to the App Store with Stripe billing, assuming web tech means web rules. The fix: either go full PWA with no App Store listing, or implement StoreKit for in-app transactions. Those are the two clean options.

Mistake 2: Hiding the pricing page rather than removing it.
Keeping a /pricing or /upgrade page accessible from within the app's webview. Apple's reviewers browse in-app webviews and will find it. The fix: gate the pricing page behind a check that detects the iOS in-app context and either blocks it or replaces it with an IAP flow.

Mistake 3: Misclassifying a digital service as physical.
Labeling a digital subscription as a "service" to claim the physical goods exemption. The line blurs for coaching apps, digital art commissions, and live consulting via app. Apple's test is practical: if the primary value is delivered digitally inside the app, it's digital — regardless of what you call it.

Mistake 4: Using the Reader App entitlement for non-reader apps.
Applying for the Reader App entitlement for apps that generate content rather than consume pre-purchased content. Apple rejects productivity tools, utilities, games, and content-creation apps trying to use this path. If your app helps users make things rather than consume things they purchased elsewhere, this exemption doesn't apply.

Mistake 5: Ignoring the geography compliance split.
Building one IAP implementation for all regions while EU users have different rights under DMA. The risk: EU users encountering a US-only IAP flow that conflicts with DMA obligations. Implement region detection and route EU users to the DMA-compliant flow.

Mistake 6: Not auditing after the 2025 rule changes.
Developers who built IAP flows in 2022–2023 may have external link language, disclosure screens, or EU billing flows that don't match current requirements. Set a calendar reminder to review the App Store Review Guidelines every January and after every WWDC.

FAQs: What Developers Are Actually Asking

Key Takeaways

1. Distribution determines jurisdiction. True web apps (Safari/PWA) are outside Apple's billing rules. App Store apps are not — regardless of what rendering technology is underneath.

2. The 2024–2026 changes created options, not escape routes. The Epic ruling and DMA gave developers external link rights, but Apple's core IAP mandate for digital goods sold through the App Store remains.

3. Geography now matters for compliance. US and EU users require different billing architectures if you're leveraging external payment options.

4. Exemptions are narrow and application-based. Reader App, External Purchase Link, and enterprise exemptions must be applied for and can be revoked. Don't assume you qualify — verify it.

5. Apple reviewers test for violations. They browse in-app webviews, test purchase flows, and check for pricing pages. "Hidden" web billing is not compliant billing.

Your 2026 Compliance Checklist

☐ Determined whether your app is subject to 3.1.1 (App Store vs. web distribution)
☐ Mapped every monetization event and classified digital vs. physical
☐ Confirmed whether an exemption applies (and applied for the entitlement if so)
☐ Built region-aware billing flows (US IAP, EU DMA, rest-of-world IAP)
☐ Reviewed App Store Guidelines post-WWDC 2025 and updated flows accordingly
☐ QA'd the purchase experience as Apple's reviewers would see it
☐ Set a recurring reminder to audit guidelines annually

Need help navigating App Store compliance or building a billing architecture that works across regions? [CTA — link to landing page, consultation, tool, or resource]