Guideline 3.1.1 — in-app purchase
The line is what the money buys, not how the money moves.
Digital goods and functionality inside your app must go through in-app purchase. A subscription that unlocks features, a premium tier, extra credits, removing ads: all StoreKit.
Real-world services and physical goods rendered outside the app do not. A booking app collecting payment for a clean, a detail, a haircut or a delivery is selling something that happens in the world, and Apple's rules do not require in-app purchase for it. Stripe is fine there.
The confusion is only ever in apps that do both, which is most marketplace and field-service apps. Rigsheet is a clean example: customers pay for a detailing job through Stripe, which is correct, and the operator's own $19/month subscription to Rigsheet must go through in-app purchase, which is also correct. Same app, two payment paths, two different rules.
Which side of the line
| What the user is buying | In-app purchase? |
|---|---|
| A premium tier of your app | Yes |
| Credits, generations, unlocks inside the app | Yes |
| Removing ads | Yes |
| Digital content consumed in the app | Yes |
| A physical product shipped to them | No |
| A real-world service performed by a person | No |
| A booking for an appointment | No |
| Membership of a physical gym | No |
The test that resolves most cases: is the thing being bought consumed inside the app? If yes, StoreKit.
Where teams get it wrong
A subscription sold on the website and unlocked in the app. This is the classic 3.1.1 rejection. If the entitlement unlocks in-app functionality, the purchase route matters, and rules on external purchase links have shifted and vary by storefront. Treat in-app purchase as the safe path for your own subscription and check the current guideline text before relying on anything else.
A "manage billing" link that leads to a checkout. Linking to account management is a different thing from linking to a purchase flow, and the difference is what a reviewer will look at.
Mixed screens. A pricing screen showing both the operator's subscription and customer payment options in one list invites the reviewer to conclude the subscription can be bought outside StoreKit. Separate the flows visibly.
Hard-coded prices. Not 3.1.1 itself, but the adjacent 3.1.2 problem and one of the most common React Native mistakes. Prices vary by storefront and change; read the localised price from StoreKit and display that. Guideline 3.1.2 in detail.
The React Native specifics
Use a StoreKit wrapper for the app subscription — RevenueCat, react-native-iap, or Expo's in-app purchase module. Read products, prices and entitlement state from it rather than from your own backend's idea of what the user bought.
Keep the Stripe SDK's surface for service payments only. If both SDKs are in the bundle, the reviewer will see both, so the flows need to be legible from the UI without an explanation.
Say it in review notes. One sentence removes the whole question:
"Customers pay for the physical detailing service via Stripe (a real-world service rendered offline). The operator's own subscription to the app is an in-app purchase via StoreKit."
A reviewer who has to work that out for themselves may work it out wrongly. Review notes that work.
Restore, and the thing reviewers actually test
Any app selling a subscription needs a restore purchases path, and its absence is a routine rejection. Test it properly: second device, fresh install, sandbox account that already owns the entitlement. It is the step everyone skips and the one reviewers actually perform.
What a pre-submission check catches
Whether a StoreKit or wrapper library is present at all when the app describes a subscription. Whether prices are hard-coded rather than read from the store. Whether a restore path exists. Whether the paywall screen links to terms of use and a privacy policy, and whether those URLs resolve. Whether the App Store description advertises a trial the code does not implement.
Deterministic, local, and findable before a build. What it cannot tell you is whether a reviewer will read your mixed payment flows as clean, because that is judgement. shipcheck runs the first set and says so about the second. What it checks.
Payment rules change, and they vary by storefront and jurisdiction. Every claim here links to Apple's own documentation. Read the current guideline text before making a payments decision, and take advice if real money depends on the answer.
Questions and answers
What is App Store Guideline 3.1.1?
The in-app purchase rule. Apps unlocking features or functionality within the app must use Apple's in-app purchase system. It is the guideline behind rejections for external payment links, alternative payment processors for digital content, and subscriptions taken outside StoreKit.
Does Stripe violate App Store rules?
Not for real-world services. Apple's rules do not require in-app purchase for goods and services consumed outside the app, so a booking app collecting payment for a physical service via Stripe is fine. Your own app subscription is a digital good and must go through in-app purchase.
Can an app take payment for a real-world service without IAP?
Yes. Physical goods and real-world services rendered outside the app are outside the in-app purchase requirement. A cleaning business app charging a customer for a clean is not selling digital content.
What happens if an app mixes both?
It is common and permitted, provided the split is clean. Keep the app's own subscription on in-app purchase, keep customer-facing service payments clearly tied to the offline service, and do not let the two flows share a screen in a way that suggests the subscription can be bought outside StoreKit.
Can I link to my website to subscribe?
Rules on external purchase links have changed and vary by storefront. Treat in-app purchase as the safe path for your own subscription, and check the current guideline text and any storefront-specific entitlement before relying on an external link.
shipcheck. “Guideline 3.1.1 — in-app purchase.” Baker Ventures LLC, September 6, 2026. https://shipcheck.bakerventuresstudio.com/rejections/guideline-3-1-1-in-app-purchase/