Guideline 3.1.1: When Apple Requires In-App Purchase

Sell digital goods the wrong way and 3.1.1 sends you back

Guideline 3.1.1 is the payments rule, and it rejects more apps than most teams expect: sell digital goods through anything but Apple's In-App Purchase and the build comes back. The rule shifted with external-link entitlements and the EU's Digital Markets Act, so what is allowed now depends on what you sell and where you ship. The payment plumbing, though, is visible in your binary — which makes the risk catchable early.

What does Guideline 3.1.1 still require?

The core rule is unchanged: if your app unlocks features, content, or digital goods used inside the app, that purchase generally has to go through Apple's In-App Purchase. You cannot route users to a web checkout to buy digital content. What changed is the edges:

Scenario	Payment path
Digital goods used in the app	Apple In-App Purchase (StoreKit)
Physical goods / services consumed outside the app	Any payment method
External purchase link (US, post-Epic)	Allowed with the entitlement + disclosure
Alternative payment in the EU (DMA)	Allowed with the entitlement
Reader app account management	External Link Account entitlement

The exceptions are real, but each one is conditional. Assuming you qualify is how teams get rejected.

Which signals in the binary raise a 3.1.1 flag?

Whether 3.1.1 applies depends on what you sell — a product and legal judgment, not something a scan decides. But the technical signals that commonly trigger a 3.1.1 review are detectable in the build:

• A third-party payment SDK (Stripe, Braintree, PayPal, Adyen) linked into an app that also delivers digital content.
• External checkout URLs reachable from the binary, with no matching entitlement present.
• Digital-goods signals (subscriptions, coins, unlocks) with no StoreKit usage at all.
• An EU/US external-payment flow shipped without the entitlement that authorizes it.

A scan flags the contradiction — "you ship a web-payment SDK and digital-purchase language but no StoreKit and no external-link entitlement" — and you confirm whether your model actually requires IAP.

AppCompliance surfaces the payment SDKs in your binary and the StoreKit and entitlement signals next to them, and can gate the check in CI. It tells you what the binary does; you decide whether your business model puts you inside 3.1.1.

Summary

• Decide honestly whether what you sell is digital goods used in the app or physical/external.
• If IAP applies, StoreKit is actually wired in for those purchases.
• Any external payment link is backed by the correct US or EU entitlement, with disclosure.
• Reader-app or alternative-payment entitlements match the regions you ship to.
• Get the category right first; the binary will tell you whether the plumbing matches it.