Write App Review Notes as a reproducible test path: state what needs explanation, provide the required access and setup, list the exact navigation steps, and name the expected result. The reviewer should not have to infer which account, screen, purchase state, or hardware dependency makes the feature work.
Review Notes are private instructions for Apple. They are not release notes, a marketing pitch, or the place to argue that the app deserves approval. If you are still assembling the whole release, start with the first iOS App Store submission guide.
The short version
- Explain only what is not obvious from a normal launch.
- Use exact labels and numbered steps.
- Include prerequisites before the reviewer reaches the blocked screen.
- Retest the note on the selected build from a clean state.
Start with the reviewer’s question
A useful note answers: “How can I inspect the submitted feature under review conditions?” Begin with the part that a reviewer cannot discover safely on their own.
Typical reasons to add notes include:
- login or a role-specific account;
- a feature behind onboarding, location, or seeded data;
- a subscription or in-app purchase state;
- hardware, a QR code, or another device;
- background behavior that needs a trigger;
- an entitlement or regulated workflow;
- a feature controlled by a production flag;
- a non-obvious route to account deletion.
If the app is straightforward and needs no special access, keep the note short. More text is not automatically more helpful. The objective is to remove ambiguity at the point where it would stop review.
Apple’s platform version information reference says App Review Information is not visible to customers and can be edited. It documents the review contact, Notes, and demo-account sign-in fields used for a version.
Use a five-part note structure
The most reliable structure is context, access, setup, steps, and expected result. Put each item on its own line.
1. Context
Name the feature and why it needs instructions. One sentence is enough.
The team workspace export is available only to an owner account with seeded project data.
Do not add product history unless it changes the test. “We spent six months building this” gives the reviewer no action.
2. Access
Provide credentials in the dedicated sign-in fields when possible. In Notes, identify the account role and any extra accounts required.
Use the demo account in App Review Information. It is configured as a workspace owner with an active test entitlement.
If single sign-on is required, explain the working review route. Avoid authentication that depends on a code sent to your personal phone or inbox.
3. Setup
List conditions that must exist before step one: region, permission state, hardware, sample code, network, or test data.
Use the attached sample QR code. Camera permission is requested after you select Scan Code.
A prerequisite written after the steps is effectively hidden. Put it before navigation.
4. Numbered navigation
Use the exact labels in the submitted build:
- Sign in with the supplied owner account.
- Select Projects in the tab bar.
- Open Review Sample.
- Select the overflow menu, then Export.
- Choose PDF.
“Go to settings and test export” is too vague when the app contains several settings screens or export types.
5. Expected result
End with observable evidence:
A preview appears with the seeded project title, followed by the iOS share sheet.
This lets the reviewer distinguish a correct state from a spinner, empty page, or silent failure.
Keep credentials and the environment usable
Review Notes cannot rescue a broken account. Apple’s App Review Guidelines ask for full access, including an active demo account or fully featured demo mode for account-based features. The guidance also calls out required hardware or resources, such as a sample QR code.
Before submission, test the review account on a second device or clean simulator state that is not already authenticated. Confirm:
- the password works exactly as entered;
- the account does not expire;
- no forced reset interrupts the flow;
- multi-factor authentication is handled without your live intervention;
- the expected role and data are present;
- production services accept the account;
- rate limits or bot protection do not block a new device.
The dedicated App Review demo-account guide covers account state, authentication blocks, seeded data, and service availability. Notes and access should be tested together.
Write for the selected build
Draft notes only after the route is stable, then verify them again against the exact build selected in App Store Connect. Labels, tab order, seed data, and feature flags can change between uploads.
Use this review method:
- Give the note to someone who did not build the feature.
- Start from a clean installation.
- Allow them to follow only the written instructions.
- Record every place they have to ask a question.
- Fix the note or the app path, then repeat.
If the written route requires a paragraph to explain each tap, the interface or account state may be the real problem. Notes should clarify non-obvious review conditions, not compensate for a workflow that does not function.
Cover purchases without making claims
For subscriptions or in-app purchases, identify the product and route the reviewer should inspect. Explain any preconfigured entitlement on the demo account and where restore is available.
Avoid promising that a purchase “will always work.” Instead, describe the test state and expected interface. If a subscription product is being submitted with the app, ensure it is complete and included in the intended draft submission.
A concise purchase note might say:
The demo account starts without an entitlement. Open Settings → Upgrade, select Monthly, and use the App Review purchase environment. After the transaction, the Upgrade row changes to Manage Subscription. Restore is on the same screen.
Only include a path you have tested on the submitted build.
Explain sensitive or unusual dependencies carefully
Location, health, finance, kids, hardware, and regulated features may need additional evidence or professional review. State the operational facts without presenting legal conclusions you cannot support.
For example, name the test region and where the app displays a disclaimer. Do not write “This feature is fully compliant with every law.” Apple decides its review outcome, and legal compliance may require qualified advice.
If documentation is needed, keep the essential test facts in Notes. If you reference a document or video, make it accessible without an access request, name it precisely, and explain what it demonstrates. Do not point to a large internal deck and expect the reviewer to find one page.
Avoid the notes that create more work
These patterns fail because they transfer uncertainty to the reviewer:
| Weak note | Better direction |
|---|---|
| “Everything is self-explanatory.” | Name the normal starting path or leave the note concise |
| “Please approve urgently.” | Use Apple’s support process for a genuine timing request |
| “Login: test/test.” | Put credentials in sign-in fields and identify account state |
| “Premium works.” | Give the exact path and expected entitlement result |
| “See documentation.” | Name the resource, relevant section, and reason |
| A copy of release notes | Explain private setup and navigation instead |
Apple’s App Review Guidelines explicitly ask for detailed explanations of non-obvious features and in-app purchases in App Review notes. Specificity is part of submission completeness; it is not a guarantee of approval.
FAQ about App Review Notes
Are App Review Notes public?
No. They are part of App Review Information and are not shown to customers on the App Store.
Should I paste the demo password into Notes?
Use the dedicated sign-in fields for the primary demo account. Use Notes to explain its role, state, and any additional accounts or authentication steps.
Can I edit Notes after submitting?
Apple’s reference says App Review Information can be edited, but the useful action depends on the current status and what Apple is already reviewing. If instructions materially change, make sure the reviewer receives a coherent update through App Store Connect.
How long can the Notes field be?
Apple’s current platform version reference states that Notes can contain up to 4,000 bytes. Treat that as a ceiling, not a target.
Should Review Notes include release notes?
No. Customer-facing What’s New text belongs on the product page. Review Notes should contain private test instructions and dependencies.
Conclusion
A strong review note is a small test case. It names the state, grants access, gives exact steps, and ends with an observable result.
Write the route, hand it to someone unfamiliar with the feature, and rerun it on the selected build. Any question they need to ask is a gap the reviewer may face too.