Guideline 3.1.2 Rejection: How to Fix Your Subscription Paywall for App Review

A Guideline 3.1.2 rejection means App Review looked at your auto-renewable subscription and found it does not meet Apple's Subscriptions rule. Apple files 3.1.2 in the Business chapter, right after 3.1.1 (In-App Purchase), and it has three lettered clauses: 3.1.2(a) Permissible uses, 3.1.2(b) Upgrades and Downgrades, and 3.1.2(c) Subscription Information. The rejection you get names the clause, and for a typical indie app built with Expo and RevenueCat it is (c) far more often than the other two. 3.1.2(c) says that before asking a customer to subscribe you should clearly describe what the user gets for the price, and that you must communicate the requirements in Schedule 2 of the Apple Developer Program License Agreement. In plain terms: your paywall is missing a required disclosure, or your listing is missing a required link.

This is a different failure from 3.1.1. A 3.1.1 rejection means you unlocked something without in-app purchase at all. A 3.1.2 rejection means you are using in-app purchase correctly and the subscription itself is wired, but the screen that sells it does not say enough, says it in the wrong proportion, or is missing a way back in for existing subscribers. That is why it is so common on a first submission: the RevenueCat integration works in sandbox, the purchase completes, and the builder never checks the screen against the disclosure list because nothing crashed. If your rejection cites 3.1.1 instead, [the Guideline 3.1.1 rejection post](/blog/app-store-rejection-guideline-3-1-1) covers that case.

The lettered clause in your rejection tells you where the fix lives. Read it before you touch anything.

Two of these are rare for a first app. 3.1.2(a) usually only bites when a builder ships a subscription shorter than a week, gates paid content behind a share-to-unlock step, or lets a subscription silently stop working on a second device because entitlements are stored locally instead of tied to the account. 3.1.2(b) shows up when monthly and annual are created as two separate subscription groups instead of two products in one group, so a user can end up paying for both. The rest of this post is about 3.1.2(c), because that is where nearly every indie rejection lands.

Inside App Store Launch Club we run every subscription screen against a list we call the Paywall Seven. It is nothing more than Apple's own disclosure requirements, taken from Guideline 3.1.2(c), Schedule 2 of the developer agreement, and Apple's published subscription guidance, arranged in the order a reviewer reads a screen. If all seven are on the paywall and in the listing, 3.1.2(c) has nothing to cite.

Open your paywall on a device and read it as a reviewer would, top to bottom, with the Paywall Seven next to you. Most rejected screens fail on three or four items at once because they were designed for conversion first and audited never. The fix is usually layout and copy, not billing logic, which is why it belongs in the same pass as [the paywall screen that converts](/blog/paywall-screen-that-converts): the disclosures Apple requires are also the ones that make a buyer trust the button.

Once the screen is corrected, run the purchase and the restore path in sandbox before you build. [How to test in-app purchases in sandbox mode](/blog/how-to-test-in-app-purchases-in-sandbox-mode) covers the sandbox account setup, and [how to set up in-app subscriptions](/blog/how-to-set-up-in-app-subscriptions) has the product and offering wiring if anything upstream of the screen is off.

Apple states that both your app and your App Store metadata must include links to your Terms of Use and Privacy Policy. Builders routinely cover the app and forget the listing, and the reviewer cites 3.1.2 with a line about missing metadata. The Privacy Policy has a dedicated URL field in App Store Connect under App Information. Terms of Use does not have its own dedicated field for most apps, so the standard practice is to put a working Terms of Use link in the app description. If you supply a custom license agreement instead of Apple's standard EULA, that goes in the License Agreement section of App Information, and it must still be reachable from inside the app.

If your rejection cites (a), check the product and the behavior, not the screen. Confirm the subscription duration you created in App Store Connect is at least a week (Schedule 2 lists weekly, monthly, bi-monthly, tri-monthly, semi-annual, and annual as the allowed cadences). Confirm the entitlement is tied to the user's store account or your own account system so it works on their other devices, which is exactly what RevenueCat's customer identity handles when you use it. Remove any step between paying and getting the content: no follow-us gate, no invite-three-friends unlock, no check-in streak required to keep access.

If your rejection cites (b), open Subscriptions in App Store Connect and make sure every tier of the same service lives in one subscription group, ranked by service level, so the store handles upgrade, downgrade, and crossgrade for you. Two groups for monthly and annual of the same thing is the classic mistake because a user can hold both at once. On the paywall, show the tiers as mutually exclusive options and never present the same plan twice with different labels.

The disclosure audit is mechanical enough that Claude Code, running from the desktop app against your Expo project, does the whole pass in one go. Paste the Paywall Seven into the prompt and ask it to check your paywall component against each item, flag every string that is hard-coded instead of read from the product, and confirm the restore and link handlers actually exist and are wired.

If you want the broader submission checklist around this, [how to pass Apple App Review](/blog/how-to-pass-apple-app-review) covers the rest of the review, and [the subscription pricing guide](/guides/how-to-price-your-app-subscription) helps you decide the tiers before you lay them out.

A Guideline 3.1.2 rejection is Apple's Subscriptions rule, and for indie apps it is almost always 3.1.2(c): the paywall or the listing is missing a required disclosure. Run the screen against the Paywall Seven - name, length, what is included, full renewal price as the most prominent price, trial length with post-trial price, a restore or sign-in path, and working Terms of Use and Privacy Policy links in the app and in App Store Connect. Fix the layout so the billed amount leads, pull every string from the store product, and put the two links in both places. 3.1.2(a) is about the subscription itself (at least seven days, works on all devices, no extra tasks), and 3.1.2(b) is one subscription group per service so nobody pays twice.

Every item on that list is something a member of App Store Launch Club has been rejected for at least once, which is how the list got written. Members post a screenshot of their paywall before they submit and someone who has already taken the 3.1.2 round trip reads it against the seven in minutes. Join at applaunchclub.co for $9 a month and get your subscription screen checked before App Review does it for you.