Write App Review Notes that shorten clarification loops
Good Review Notes are not a sales pitch. They are a test route: what account to use, where to tap, what should happen, and what dependencies the reviewer should not have to infer.
Write Review Notes as a short verification script for features that are gated, paid, location-specific, hardware-dependent, role-based, or easy to miss. Apple owns the review process; AppReviewReady interpretation is that Review Notes should remove ambiguity without asking for special treatment.
Use notes to remove friction, not to argue policy
App Store Connect lets developers provide review information when submitting an app. The practical purpose is to help the reviewer reach the relevant experience. Notes should not bury Apple in background narrative or claims that the app is compliant without showing how to verify it.
Start by listing every feature the reviewer might not naturally find: role dashboards, paid content, hidden admin flows, region-specific screens, hardware pairing, seeded sample data, deep links, UGC controls, or account deletion. Each item gets a route, expected result, and dependency.
Name dependencies before they become questions
- Accounts: username, role, seeded data, 2FA handling, and whether credentials are in the designated fields.
- Commerce: product path, sandbox-safe purchase expectation, restore route, and entitlement result.
- Hardware: device, accessory, simulator alternative, or demo mode when physical testing is impractical.
- Location: allowed test locations, seeded locations, or why a feature is not regionally visible.
- Safety: report, block, filter, contact, and moderation confirmation paths for UGC products.
Write in numbered, observable steps
A reviewer should be able to follow the note without domain knowledge. Use action verbs, visible labels, and expected outcomes. Replace 'check the premium workflow' with 'Sign in, open Settings, tap Upgrade, choose Monthly, then verify the Pro badge appears on the Profile tab.'
AppReviewReady interpretation: keep the note short enough to use under time pressure. Put credentials in the proper App Review Information fields, not in a general message. Put policy reasoning in a response only when Apple asks for it.
Preflight the note exactly as written
- Copy the note into a clean test run and follow only those instructions.
- Use the supplied reviewer account, not an internal admin account with extra privileges.
- Confirm every named button, tab, seeded object, URL, product, and expected result exists in the submitted build.
- Remove outdated references to old screenshots, old product names, or features cut from the release.
- Ask a tester unfamiliar with the app to complete the route and mark any ambiguous step.
Use a compact dependency-first template
Do not include secrets in the wrong field, and do not ask the reviewer to contact support to unlock an ordinary user journey. If the reviewer cannot complete the route from the submitted app and provided information, fix the product path before relying on notes.
Review Notes: Purpose of notes: [feature or dependency] Account: Credentials are in App Review Information; role is [role] Setup needed: [none / seeded data / location / hardware / subscription] Steps: 1. [tap] 2. [tap] 3. [tap] Expected result: [observable state] If asked for permission: [allow/deny and expected behavior] Support contact for review questions: [monitored contact]
Primary references checked for this guide
Policy statements above are grounded in the linked Apple documentation. Operational recommendations are AppReviewReady's interpretation and should be tested against your app and the current guideline text.
Check the note against the build
Verify credentials, metadata, purchases, and hidden routes before review.
Open the tool