Review rules actually constrain interaction and copy

What it is

Store review writes “may this binary ship?” as a checklist a stranger can execute. Those rules bind button labels, where prices appear, when permission prompts fire, and whether a link may bypass in-store payment. They are not a legal appendix. They are a hard edge on interaction and copy. What gets blocked is not brand tone; it is a path a reviewer can actually walk. Call this review-constrained interaction: the team thinks it is designing an experience, and is simultaneously designing a reachable surface for a reviewer.

This is not the same as “will users complain after launch.” Complaints happen to products already on the shelf. Review happens before the binary is allowed onto the shelf. Overclaiming copy, prices buried one screen deeper, a button that names a one-time purchase while starting a recurring charge — in review, those fail as interaction first.

Why it happens

A reviewer receives a build, screenshots, and a checklist, not the product spec. Checklist items can only land on what can be seen and tapped: on-screen sentences, control labels, prices, system permission dialogs, whether a jump really leaves store payment. If the flow postpones the critical fact, hides it in Settings, or smuggles it under a vague verb, the checklist cannot be ticked and the build is rejected.

The constraint is real because the shipping channel is a single gate. Fail review, and a coherent flow never reaches devices. Design decisions therefore split into two piles: what the reviewer can reach, and what they cannot. Internals, server flags, and experiments are not evidence. Every reachable sentence and jump carries rule risk on the product’s behalf. Copy is a promise. So is a button. So is an empty state.

Where it stops holding

Internal packages, enterprise-signed apps, and purely web products do not pass this gate; other compliance regimes may still apply, but the mechanism is different. Live products that hot-update copy without a binary resubmit feel a weaker bind — do not assume every store allows that. Games, streaming, and children’s apps often carry extra checklists; consumer-utility experience does not transfer. Passing one store does not imply safety in another: the lists differ.

Applying it

• Treat payment, account, permission, outbound links, and user-generated content as primary reviewer paths, not “details in Settings.”
• For every speaking button and title, check that the literal words name the next real action; do not let “Get started” start a charge.
• Before submit, walk first launch on a device with no account, no purchase receipt, and all permissions off — screens only, no backend console.
• Verify by handing a person who has never read the spec the store’s public review notes and the core tasks. Any explanation that starts “actually the backend…” is a mismatch between the visible UI and the rules.

Related

• Same group: R4.07.2 Subscriptions, payments, and permissions are high-frequency rejection points · R4.07.3 Rule changes must enter the design update cycle
• Adjacent: R4.13 Store review constraints on interaction · R4.06 Platform convention vs brand consistency
• Search terms: review-constrained interaction · store review · App Store review