Guideline 3.1.1 rejections: In-App Purchase

Guideline 3.1.1 is the rejection for an app that sells digital goods or subscriptions without Apple's in-app purchase, which for a SaaS app usually means an "Upgrade" button, a pricing page, or a link to buy on the web that native users can see. The fix is a decision, then a deploy: either the app is a companion to a paid web tool and shows no purchasing at all, or it sells through in-app purchase.

#What Apple says

From the App Store Review Guidelines:

If you want to unlock features or functionality within 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. Apps may not use their own mechanisms to unlock content or functionality, such as license keys, augmented reality markers, QR codes, cryptocurrencies and cryptocurrency wallets, etc.

#What the rejection says

In substance: the app accesses digital content or services purchased outside the app, or includes a link, button, or text directing users to purchase outside the app, and must use in-app purchase for that. The reviewer found a price, an upgrade prompt, a "manage subscription" link to your site, or a plan name with a cost next to it.

#Why it happens to Rails apps

The web app sells on the web. The upgrade banner, the pricing page in the footer, the "Your trial ends in 3 days, upgrade now" flash, and the billing settings page all render inside the native app unless something hides them. One visible price is enough.

#The fix

Payments on the App Store is the decision. In short:

1. Choose the path. Most SaaS apps take the companion path under guideline 3.1.3(f): a free app that serves existing customers of a paid web tool, with no purchasing inside the app and no calls to action to purchase elsewhere. The alternative is selling inside the app through in-app purchases.
2. On the companion path, remove every purchase signal for native users. Upgrade buttons, prices, plan comparisons, trial countdowns, "billing" links, and the pricing page. Wrap them in unless native_app? or give them native-hidden. Account settings can show the current plan name; it cannot show a price or a way to change it.
3. On the in-app purchase path, sell through the paywall. The purchase runs through Apple's StoreKit and your Rails app records it. Then the web price and the App Store price can both exist, each on its own side.
4. Check the signed-out screens too. A sign-up page that mentions "free 14-day trial, then $29/month" is a price.
5. Deploy and reply. The pages come from your site, so the fix needs no new build. Say which path the app takes and that no purchasing remains in it.

#When the reviewer is wrong

If the app is a companion to a paid web service and shows no purchasing:

Thank you for the review. The app is a free companion to our web service under guideline 3.1.3(f): it provides access for existing customers and includes no in-app purchasing and no calls to action to purchase elsewhere. The account screen shows the plan name only, with no price and no way to change it. If a specific screen appeared to offer a purchase, could you point us to it? We'd appreciate a second look.

If the reviewer cites a US link-out, note that the US carve-out only applies to the United States storefront and that Ruby Native cannot yet limit a link to US users; payments has the current state.

From Joe: TODO one line on what actually got an app through 3.1.1.