Writing App Review notes that work
Review notes are the only place you get to answer a question before it is asked. A reviewer has a few minutes, no context, and no way to know that your background-location declaration exists for a feature three screens deep.
Write them as operational instructions for one person, not as marketing. Four things belong in them: working demo credentials, how to reach anything not obvious from the first screen, a one-line justification for each sensitive permission or background mode, and an explanation of anything a reviewer could reasonably misread.
Keep it short. Notes that are cheap to read get read.
The template
DEMO ACCOUNT
Email: [email protected]
Password: ********
(verified working on <date>)
WHERE TO FIND THE MAIN FEATURES
1. Sign in with the account above.
2. Tap "Start" on the home screen to begin a session.
3. The [feature] is under Profile → [tab]; it needs at least one saved
session to display, and the demo account already has three.
PERMISSIONS
Location "Always": the app detects drive sessions automatically while
closed. Without it the core feature does not function. The app remains
usable if the permission is declined — sessions can be started manually
from the home screen.
Camera: used only in Profile → Add photo.
THINGS THAT MIGHT LOOK WRONG BUT ARE NOT
- The second tab is empty until a session completes. Tap "Start", wait
~10 seconds, then "Stop" to populate it.
- Prices display in the storefront currency; the demo account is US.
CONTACT
<name>, <email>, available <hours/timezone>That is the whole thing. Under a page.
The four that cause avoidable rejections
1. A demo account that does not work. Expired, rate-limited, password rotated, or gated behind an SMS code the reviewer cannot receive. This is a Guideline 2.1 rejection and it is entirely self-inflicted.
Check it the morning you submit, from a device that is not yours, in a private session. And if your login requires a one-time code, provide a path that does not — a bypass account, a fixed test code, whatever your architecture allows. A reviewer who cannot get in has not seen your app.
2. A feature the reviewer cannot find. If the thing that justifies your permissions, or the thing that makes your app more than a website under Guideline 4.2, is three taps deep behind an empty state, say where it is. Reviewers do not explore.
3. A permission with no visible reason. Every sensitive permission and every background mode should have one line saying which user-facing feature needs it. This is the cheapest rejection prevention available. Guideline 2.5.4 specifically addresses declaring the location background mode without a legitimate persistent-location feature, and a reviewer who cannot see the feature will assume it is not there. Detail.
4. Empty states that look broken. A fresh account showing an empty screen reads as a bug. Either seed the demo account with data — better — or say what to do to populate it.
What to leave out
Marketing copy. The reviewer is not a customer. "Revolutionise your workflow" wastes the only attention you have.
A feature list. They can see the app. Tell them how to reach things, not what they are.
Apologies and pre-emptive defences. "We know this might look like…" invites the scrutiny you are trying to avoid. State what the feature is and why the permission is needed, flatly.
Guideline arguments. If you disagree with a rejection, that conversation belongs in the Resolution Center after the fact, not in the notes before it.
After a rejection, the notes change job
A resubmission's notes should say, plainly, what changed and where. Cite the clause you were rejected under, state the fix, name the screen or the file.
RESUBMISSION — previously rejected under Guideline 5.1.1(v)
Added in-app account deletion: Profile → Settings → Delete account.
Deletion removes the account and associated data, with an in-app
confirmation step. Build 47.A silent resubmission gives the reviewer no reason to look at it differently. A specific one attached to the submission does. /shipcheck:reply drafts this against the clause you were actually cited under.
Automate the check, not the notes
Notes are a human artefact and should stay one. What can be automated is verifying that the claims in them are true: that every permission string in the shipped Info.plist corresponds to a real code path, that every UIBackgroundModes entry has a matching capability, that the app degrades rather than breaks when a permission is declined.
Those are static, local, deterministic checks — and they are what shipcheck runs before you build, inside the Claude Code session you already have open. What it checks.
Questions and answers
What should I put in App Store review notes?
Working demo credentials, how to reach any feature that is not obvious from the first screen, a one-line justification for each sensitive permission or background mode, and an explanation of anything a reviewer might reasonably misread. Keep it short and specific.
Do App Review notes actually get read?
They are attached to the submission and available to the reviewer. Treat them as the one place you get to pre-empt a question rather than as a guaranteed read - which means the notes should be short enough that reading them is cheap.
Do I need a demo account for App Review?
If any part of your app is behind a login, yes. Guideline 2.1 covers app completeness, and a login a reviewer cannot get past means the app cannot be fully reviewed. A broken or expired demo account is one of the most common and most self-inflicted rejections there is.
What should I not put in review notes?
Marketing copy, a feature list, apologies, or arguments about guidelines. The notes are operational instructions for one person trying to evaluate your app in a few minutes.
Where do I add review notes?
In App Store Connect, in the App Review Information section of the version you are submitting, alongside the demo account fields and contact details.
shipcheck. “Writing App Review notes that work.” Baker Ventures LLC, September 6, 2026. https://shipcheck.bakerventuresstudio.com/guides/review-notes-that-work/