Guideline 3.2.2: business practices Apple will not host

The paywall test

The single most informative pre-submission exercise for this guideline, and it takes four minutes:

Hand your phone to someone who has never used the app, and ask them to not buy it.

Watch. If they hesitate, tap the wrong thing, or ask you which button means no, you have your finding. A decline path that requires thought is the finding, regardless of what anyone intended.

Then ask them three questions:

1. How long is the trial and what happens at the end?
2. How much is it, and how often?
3. How would you cancel?

If they cannot answer all three from what they just saw, the disclosure is not doing its job. Guideline 3.1.2, subscription disclosure.

What is fine, and gets confused with this

• A hard paywall. Requiring payment for the whole app is a business model, not a dark pattern.
• An intro offer. Discounted first periods are a supported StoreKit feature.
• A real, genuinely expiring promotion, where the expiry is true.
• The system rating prompt, used within its limits.
• Highlighting the annual plan as better value, when it is.

The distinguishing question is always whether the user could describe what they agreed to. Persuasion is allowed. Confusion is the thing being prohibited.

The reviews half

Manipulating ratings and reviews sits inside this guideline, and it also sits inside consumer protection law in the US and elsewhere. Both apply, and the regulator's version does not care whether the app was approved.

Prohibited on both counts: buying reviews, incentivising them, review-swap schemes, fabricated testimonials, and review gating — routing users to a private feedback form and only sending the happy ones to the store prompt.

Ask everyone the same way, incentivise nobody. That single rule is compliant under both regimes and takes no engineering. Getting reviews without being annoying covers the same ground for a service business, and the rule is identical.

What a reviewer actually sees

They install the app, hit the paywall, and try to get past it. That is the sequence, and it means your paywall is one of the first three screens a reviewer forms an opinion from.

If they cannot dismiss it, if the terms are not visible without scrolling, if a link to Terms and Privacy is missing, or if the price is smaller than the marketing copy around it, that is what gets written up.

Frequently it is reported under 2.1 App Completeness or 3.1.2 rather than 3.2.2, which is why searching the guideline number does not find the answer.

The pre-submission pass

# scarcity and social-proof language in paywall and listing copy
grep -rniE 'limited time|expires in|only [0-9]+ left|hurry|last chance|[0-9,]+\+? (users|downloads|reviews)|rated #1' \
  src app fastlane/metadata 2>/dev/null | head -20

# countdown state that resets rather than persisting
grep -rniE 'countdown|timer|expires|deadline' src app --include=*.ts --include=*.tsx 2>/dev/null | head

# required disclosure elements present on the purchase screen
grep -rniE 'auto.?renew|cancel any time|terms of (use|service)|privacy policy' src app 2>/dev/null | head

Then do the four-minute human test above, which finds more than all three commands.

shipcheck reports unsubstantiated claim language in listing and in-app copy, and checks that the required subscription disclosure elements are present on the purchase screen. It cannot judge whether a design is manipulative, which is a human question, and it says so rather than implying otherwise. What it checks. · After a rejection.

Questions and answers