Guideline 3.1.1 Rejection: How to Fix an In-App Purchase Violation

A Guideline 3.1.1 rejection means App Review found a way for a user to unlock content or functionality in your app that does not go through Apple's in-app purchase system. Apple's rule is direct: if you want to unlock features or functionality inside your app, by way of example subscriptions, in-game currencies, game levels, access to premium content, or unlocking a full version, you must use in-app purchase, and apps may not use their own mechanisms to unlock content instead, such as license keys, augmented reality markers, QR codes, cryptocurrencies, or cryptocurrency wallets. The fix is to route that unlock through a real StoreKit in-app purchase product, not to explain why your workaround is different.

Apple's text for 3.1.1 lists what has to go through in-app purchase and what is explicitly off-limits as a workaround. Apps may use in-app purchase currencies to let customers tip a developer or content provider. Any credits or in-game currencies purchased via in-app purchase may not expire, and restorable purchases need a working restore mechanism. Gifting is allowed for items eligible for in-app purchase, but a gift may only be refunded to the original purchaser, not exchanged. Apps offering loot boxes or other randomized virtual items must disclose the odds of receiving each item type before purchase. Digital gift cards, certificates, vouchers, and coupons redeemable for digital goods or services can only be sold through in-app purchase, though physical gift cards sold in an app and mailed to the customer can use other payment methods.

Apple does allow a specific, opt-in path to link out to another purchase method, but it requires an entitlement, not just a good reason. Under 3.1.1(a), developers can apply for a StoreKit External Purchase Link Entitlement to include a link in their app to a website they own or maintain responsibility for, where a user can buy digital content or services outside in-app purchase. That entitlement is limited to specific storefronts and regions, and it comes with real restrictions: it can inform users where and how to buy the item and that the price may be lower elsewhere, but outside the covered storefronts, apps and their metadata still cannot include buttons, external links, or other calls to action pointing at other purchasing mechanisms. Apple's text is explicit that misleading marketing, scams, or fraud tied to the entitlement gets the app removed from the store and can get the developer removed from the Apple Developer Program.

Almost every 3.1.1 rejection on a fast-shipped Expo app traces back to one of a handful of shortcuts, usually taken to avoid setting up StoreKit products in App Store Connect before the first submission.

None of these are subtle once App Review looks for them. The reviewer's test is simple: does anything in this app unlock a feature through a payment that did not go through Apple. If the answer is yes anywhere in the app, the whole submission gets the 3.1.1 rejection, even if every other paywall in the app correctly uses in-app purchase.

Guideline 3.1.3 lists app types that may use purchase methods other than in-app purchase, and two of them get cited in Resolution Center arguments far more often than they actually apply. Read Apple's exact scope before you build a rejection response around either one.

3.1.3 also states plainly that apps covered by these exceptions still cannot, within the app, encourage users toward a purchasing method other than in-app purchase, outside of the United States storefront and the specific 3.1.1(a) and 3.1.3(a) entitlement cases. Developers can email or message their existing users outside the app about other ways to pay; they cannot build that pitch into the app's UI.

If your real goal was to let someone try the app before paying, without building a login system or a backend to track a promo code, Apple already has a sanctioned path for that. A non-subscription app can set up a Non-Consumable in-app purchase item at Price Tier 0 named with the "XX-day Trial" convention, then gate the full unlock behind purchasing the real paid product once the trial period ends. The app has to clearly show the trial's duration, name what becomes inaccessible afterward, and disclose any downstream charges before the trial starts. It is more setup than a hardcoded flag, but it is a real StoreKit product, so it never puts you anywhere near a 3.1.1 rejection.

Work through the app screen by screen looking for anything that changes what the user can access after money moves, not just the screens you think of as "the paywall."

Treat this like any other App Review message: state exactly what changed, in terms of the specific mechanism the reviewer found, not a general promise to "fix payments."

The general pattern for structuring any Resolution Center reply, including what belongs in App Review Information versus the reply itself, is covered in [Guideline 2.1 Information Needed](/blog/guideline-2-1-information-needed-rejection). If the paywall screen itself also needs work once the mechanism is fixed, [paywall screen that converts](/blog/paywall-screen-that-converts) covers the layout and copy that clears review and converts.