If you have just received an App Review rejection citing Guideline 3.1.1 because your AI chatbot app has a Subscribe button that opens a Stripe checkout in Safari, you are far from alone. Almost every wrapper around an LLM API hits this rule in some form, especially the ones assembled with Cursor or Claude Code that copy a web Stripe flow as if it were portable to iOS.
Short answer
AI chatbot apps almost always sell Digital Goods: premium GPT tiers, image generations, voice minutes, message credits. Apple requires StoreKit in-app purchase for all of those, per Guideline 3.1.1. The May 2025 court-ordered update added a steering option for US storefront apps to also include a button or link sending users to a web checkout, without an entitlement. In every other storefront, the same link is a rejection.
What you should know
- Digital Goods covers anything the app consumes after the payment. Credits, tokens, message quotas, premium models, image generations, voice minutes, removing watermarks, and template libraries all count.
- The US storefront change altered steering, not the in-app purchase requirement. You still need StoreKit if you want to actually sell from inside the app; the link only points users elsewhere.
- Non-US storefronts still require entitlements for external purchase links. The StoreKit External Purchase Link Entitlement is region-locked (Netherlands dating apps, EU/EEA under the DMA, Japan MSCA, South Korea).
- A Stripe-hosted checkout opened in Safari is the most common 3.1.1 trigger. Reviewers tap your Upgrade button, see a Stripe page, file the rejection within minutes.
- A passive Visit our site to upgrade screen also fails outside the US. Apple reads any in-app text that steers users to a web checkout as the same violation as a clickable link.
- Marking the app as free in App Store Connect does not exempt you. App Review checks the actual user flow, not the price tag on the listing.
- Open-source clones inherit the same rule. The fact that you built the app with Claude Code or copied a ChatGPT clone repo does not change how 3.1.1 applies.
What does Apple actually mean by Digital Goods in an AI chatbot context?
Anything paid for inside the app that the user then consumes inside the app is a Digital Good. For an AI chatbot, that includes the message quota, the GPT model toggle (for example switching from a smaller model to a frontier one), the prompt template library, the voice minutes, the image generation credits, and any Pro tier that gates features behind a subscription.
The Apple App Review Guidelines require in-app purchase for any feature gated behind a payment that happens within your app, listing subscriptions, in-game currencies, levels, premium content, and full-version access as the canonical examples. AI chatbot tiers map cleanly onto subscriptions and premium content.
The rule has been stable since at least 2020. Only the clauses around external links and steering changed in May 2025. Apple's documentation on the StoreKit External Purchase Link Entitlement confirms that the entitlement itself does not satisfy 3.1.1; it only permits an additional informational link alongside in-app purchase in approved regions.
A reviewer who taps your Upgrade to Pro button and sees anything other than a StoreKit purchase sheet (the system prompt with Face ID or Touch ID confirmation) writes a 3.1.1 rejection. The limit on this is that not every AI app sells Digital Goods. If your app is genuinely free with no in-app monetization, or if you only sell physical goods like a printed prompt book mailed to the user, 3.1.1 does not apply. A chatbot with credits, sessions, or any Pro tier is in scope.
Why does the May 2025 US storefront change not solve this for everyone?
The change Judge Yvonne Gonzalez Rogers ordered in Epic Games v. Apple removed the prohibition on steering, not the requirement to use in-app purchase. As 9to5Mac documented in May 2025, the updated Guideline 3.1.1(a) now permits US storefront apps to include buttons, links, or other calls to action toward external purchase methods, with no entitlement required and no Apple commission on the external sale.
That is a different thing from being free of StoreKit. The cleanest read of the current guideline text is that on the US storefront you may add the external link, alongside or instead of in-app purchase. For an app sold worldwide, the same link triggers a rejection on every storefront other than the US, because App Store Connect submits one binary to all selected storefronts at once.
The practical fix is either a runtime check that reads the user's storefront and hides the link outside the US, or removing the link entirely and committing to StoreKit globally. The runtime check uses the Storefront.current API from StoreKit 2, and the value to look for is USA. Anything else, hide the button.
How does App Review detect the external link in practice?
Reviewers run the app on a real device, tap the most monetization-adjacent buttons in the first two minutes, and inspect what happens. If a tap opens an external browser to a checkout page, the rejection is automatic. The reviewer screenshots the Stripe page or the Lemon Squeezy page, attaches it to the Resolution Center note, and cites 3.1.1.
Reviewers also read your app description, screenshots, and any onboarding text. A phrase like Visit our website to upgrade, or a QR code embedded in a Settings screen, is the same violation. The guideline text covers metadata as well as the in-app UI: in storefronts where the prohibition still applies, the rule covers buttons, external links, or other calls to action, and metadata is explicitly included.
In practice, App Review treats the metadata clause as separate from the entitlement-region rule. Reviewers will still flag clearly steering language in app descriptions even when the in-app behavior would now be permitted on the US storefront, because the listing is the same across storefronts. The safest pattern is to keep all steering text out of public metadata and constrain the link to a conditional UI block inside the app.
What does compliant in-app purchase look like for an AI app?
A compliant flow uses StoreKit 2, the modern SDK Apple introduced in iOS 15. You configure products in App Store Connect (Auto-Renewable Subscriptions, Consumables, or Non-Consumables), fetch them with Product.products(for:), present the purchase with product.purchase(), and validate the resulting transaction server-side with App Store Server Notifications V2 or the App Store Server API.
For an AI chatbot, the product shapes that fit the common monetization patterns are these:
| Product type | StoreKit shape | Example for an AI chatbot |
|---|---|---|
| Monthly Pro subscription | Auto-Renewable Subscription | Unlimited frontier-model access for 30 days |
| Yearly Pro subscription | Auto-Renewable Subscription with intro offer | Lower price for the first year |
| Message credit pack | Consumable | 100 chat messages, depletes as used |
| One-time feature access | Non-Consumable | Voice mode forever |
| Free trial then paid | Subscription with introductory offer | 7 days free, then weekly billing |
Each purchase issues a signed JWS transaction your server validates against Apple's public key, then increments the message quota or flips the user's tier in your database. The user never sees Stripe, never leaves the app.
The trade-off most builders feel is the 30 percent commission (15 percent after the first year of an auto-renewable subscription, and 15 percent across the board for participants in the Apple Small Business Program). That is the cost of selling Digital Goods inside an iOS app to a non-US storefront audience. Per OWASP MASVS, the relevant security control is MASVS-PLATFORM-1, which requires that the app use platform-provided purchase mechanisms when available so that receipt validation is verifiable end to end.
Can I keep my Stripe checkout and submit only to the US storefront?
You can, with the understanding that you give up most of the worldwide audience for now. As of the May 2025 update, a US storefront iOS app may include a Subscribe on web link that opens a Stripe checkout in Safari, with no entitlement and no Apple commission on the external sale. The disclosure sheet that Apple previously required is no longer mandatory on the US storefront, though some developers still include one for user trust.
The practical setup looks like this:
- Restrict the app's selected storefronts in App Store Connect to United States only at first.
- Implement the external link to a web checkout you operate.
- Keep your app description free of steering language to reduce reviewer scrutiny on the listing.
- Once approved, add other storefronts only if you also add a StoreKit purchase path, because the external link will not satisfy 3.1.1 outside the US.
A US-only launch makes sense for a niche AI tool aimed at US developers or creators. It does not make sense for a general-purpose consumer chatbot that needs an international audience from day one.
Is there a builder-specific pattern that gets rejected more often?
Yes. Apps assembled with vibe coding tools (Cursor, Claude Code, Windsurf) and no-code builders (FlutterFlow, Rork, Bubble) that follow a wrap an OpenAI API key with a Stripe paywall template fall into 3.1.1 almost every time. The template treats payments as a frontend concern, ports the web Stripe flow into a mobile webview or button, and never introduces StoreKit. PTKD.com (https://ptkd.com) has reviewed many of these builds in pre-submission scans and the same pattern repeats: a Settings screen that opens https://yourdomain.com/checkout in an in-app webview, or via UIApplication.shared.open, then takes the user to a hosted Stripe page.
The pattern that works in vibe-coded apps is wiring StoreKit through a managed SDK like RevenueCat or Adapty, which lets a developer who is not fluent in Swift configure products visually, handle receipt validation server-side, and treat the entitlement as the source of truth. The same approach also keeps the Android side cleaner, since Google Play has its own Billing equivalent of 3.1.1 enforced through the Play Console. The RevenueCat app-to-web guide is a useful reference on the regional entitlements and disclosure rules.
What to watch out for
A few honest limits on what this article can tell you:
- Apple does not publish a list of button labels that trigger the rejection. Subscribe, Upgrade, Get Pro, Go Premium have all been observed in rejection screenshots when paired with a flow that leaves the app, but the same words attached to a StoreKit sheet pass without comment.
- Server-side gating is not a workaround. Some developers assume that if the paywall is server-driven (the API rejects requests without a paid token), Apple cannot detect the violation. Reviewers test the actual UI; the server flow is irrelevant if the in-app purchase prompt opens a webview.
- A 3.1.1 fix does not absolve you of other rejections. Builders often patch the payment flow and get rejected again on the next round for a missing Privacy Manifest (ITMS-91053) or a missing Purpose String. Treat 3.1.1 as one of several gates.
- A myth worth rejecting: free apps do not need IAP. The rule keys on what the app sells, not the App Store price tag. A free app that gates features behind a payment still needs StoreKit, or, on the US storefront, the external link path.
Key takeaways
- AI chatbot apps almost always sell Digital Goods, so Guideline 3.1.1 applies and StoreKit is required for any storefront other than the US.
- The May 2025 court-ordered update added a steering option in the US, it did not remove the in-app purchase requirement for the rest of the world.
- A Stripe checkout opened from inside the app is the single most common 3.1.1 trigger for vibe-coded and no-code mobile builds.
- A five-gate pre-submission check (Permissions, SDKs, Storage, Network, Build) should include a payment-flow gate that verifies StoreKit is the only path to gated features outside the US storefront.
- For builders who want an automated read on the build before submission, PTKD.com (https://ptkd.com) is one of the platforms focused on pre-submission scans aligned with OWASP MASVS and App Review style policy checks for AI-coded and no-code apps.
