You wrote App Review notes for your last three submissions. Each rejection still cites Guideline 2.1 — “please provide additional information about feature X” or “the demo account credentials did not work” — even though you swear the answer was in there. Different reviewers ask variants of the same question across submissions. You start to wonder whether they’re even reading the notes.
They are reading them. The problem is that the App Review Information field renders as a wall of plain text inside an internal Apple tool that reviewers skim for less than 60 seconds. If your notes mix marketing pitch with reviewer instructions, bury credentials in paragraph three, or describe a flow in prose instead of numbered steps, the answer technically exists but the reviewer can’t extract it in time. Rewrite the notes as a scannable form, not a letter.
Common causes
Ordered by hit rate. The first three account for most repeat rejections.
1. Notes start with marketing copy instead of credentials
You open with “Welcome to Acme! Our app helps you do X with AI” — the same paragraph that’s in your description. The reviewer’s eye glazes over before they reach the demo account in paragraph four.
How to spot it: Open App Store Connect → App Information → App Review Information. If the first 200 characters do not contain a username and password or the literal string “DEMO ACCOUNT:”, you have this problem.
2. Credentials are present but malformed
You wrote “Username: test@acme.com / Password: see below” with the actual password in another paragraph; or you used smart quotes that copy-paste broken; or you wrote “any password works” (which is true in dev but not staging). Reviewer’s first login attempt fails.
How to spot it: Copy the credentials block from your notes into a plaintext editor. If you see curly quotes, em-dashes, non-breaking spaces, or the password isn’t on the same line as the username, fix the formatting.
3. Feature paths are described in prose, not numbered steps
You wrote “To test the photo editor, go to the home tab and find the new button we added on the top right which opens a modal where you can pick an image and then…” — three commas in, the reviewer has lost the trail. They tap something, it’s not the right thing, and they reject.
How to spot it: Read your notes out loud. If any sentence describes more than one click, it should be a numbered list.
4. Region / device / role gating is mentioned vaguely or not at all
The feature requires US region + iPhone 15 Pro + an admin role. You wrote “please ensure you have a compatible device”. Reviewer used the default test setup, hit an empty screen, and rejected.
How to spot it: Search your notes for the exact strings “region,” “iPhone,” “iPad,” “admin,” “Pro.” If they’re absent but your feature needs any of these, that’s the gap.
5. Notes weren’t updated between submissions
Your v2.3 notes still describe the v1.0 user journey. The reviewer follows your steps, lands on a different screen than you described, and either gives up or asks what changed.
How to spot it: Diff your current notes against the previous version’s commit in your repo (if you store them) or the previous submission’s App Store Connect snapshot. If they’re identical but the build changed materially, you missed an update.
6. Notes apologize, beg, or include irrelevant context
“We know it’s been a tough cycle and would really appreciate it if…” — softens the reviewer but tells them nothing. “Our cofounder built this in a weekend” — irrelevant. Reviewer’s time is spent extracting facts; sentimental framing pushes facts further down.
How to spot it: Highlight every sentence in your notes that does not answer a question a reviewer would ask. If more than 20% of the text is highlighted, cut it.
Information to collect
- The most recent reviewer rejection text in full.
- The previous version’s notes for comparison.
- A cold-install reproduction of the user journey for the cited feature.
- All gating conditions (region, device, role) that affect the feature.
- A working demo account with documented credentials.
Shortest path to fix
Step 1: Use the canonical reviewer-notes template
Replace the entire App Review Information field with this structure. Paste, then fill in each block. Anything optional, delete.
DEMO ACCOUNT
URL or app path: (in-app, tap "Sign In" on launch)
Email: apple-review-2026@yourdomain.com
Password: ReviewPass-Spring2026!
No 2FA. Pre-seeded with sample data.
WHAT CHANGED IN THIS VERSION
- New "AI Photo Editor" tab (bottom navigation, second from left).
- Subscription paywall moved from launch to feature gate.
- Removed location permission prompt.
HOW TO TEST AI PHOTO EDITOR
1. Sign in with the demo account above.
2. Tap "Editor" in bottom navigation.
3. Tap "+" to import a sample image (pre-loaded in Photos).
4. Tap "Enhance" — wait 5 seconds for AI processing.
5. Expected: enhanced image preview with before/after slider.
HOW TO TEST PAYWALL
1. After signing out, sign up with any new email.
2. Try to access "AI Photo Editor" — paywall appears.
3. Use sandbox account apple-iap-sandbox@yourdomain.com to test purchase.
4. Subscriptions auto-renew; cancel via Settings to retest.
REGION & DEVICE
- App is region-locked to US/CA/UK. Demo account is pre-set to US.
- AI Photo Editor requires iPhone 12 or newer (Neural Engine).
- iPad version uses the same flow; landscape only.
CONTACT
Email: dev@yourdomain.com (PT timezone, 9am-6pm)
Step 2: Audit every screen you mention
Open your dev build on a fresh simulator and walk the exact path you described. Every “tap,” “scroll,” and “wait” in your notes must correspond to a visible action. If you wrote “tap Settings” but Settings is hidden under a menu, fix the notes or fix the UI.
Step 3: Strip marketing language
Search your notes for any of these words and delete the surrounding sentence: welcome, excited, please, kindly, appreciate, hope, exciting, innovative, revolutionary. Reviewers do not need to feel welcomed; they need to find the button.
Step 4: Lock notes in version control
Create or update REVIEW.md in your repo. The next release’s App Review notes start from this file. Every submission, diff against the last submission to catch stale instructions.
# In your repo
cp REVIEW.md REVIEW.previous.md
# Edit REVIEW.md for the new release
diff REVIEW.previous.md REVIEW.md
Paste from REVIEW.md into App Store Connect; reviewers see the same text you reviewed.
Step 5: Have a non-developer cold-test
Find someone on the team who didn’t build the feature. Hand them only the rewritten notes and a freshly-installed device. If they can reach the cited feature in 5 minutes, the reviewer probably can too. If they can’t, edit until they can.
Step 6: Resubmit (notes-only, no new build)
In App Store Connect → App Store tab → tap the build → Submit for Review. Notes-only updates don’t require re-archiving.
How to confirm the fix
- Your notes pass the “60-second skim” test: a stranger can find demo credentials and a feature walkthrough by skimming the first half-screen.
- The next submission either passes or gets a different rejection than before — same rejection twice means the rewrite missed.
- Resolution Center replies from reviewers acknowledge the new information instead of repeating earlier questions.
- Your non-developer tester completed the cited path on the first try.
If it still fails
- Reply in Resolution Center quoting the exact lines in your notes that address the reviewer’s question.
- Add a 30-second QuickTime screen recording of the cited feature path; upload via the Resolution Center attachment field.
- Request a phone call from App Review (in App Store Connect → Resolution Center → “Request a Call”) and walk through the path live.
- Escalate via the Contact App Review form, asking for a fresh reviewer if the same one rejected twice for the same gap.
Prevention
- Maintain
REVIEW.mdin your repo as the single source of truth; every submission copies from this file. - Add a release-checklist item: “diff REVIEW.md vs previous submission; non-dev tester walks notes.”
- Save each submission’s notes as a tagged file (
REVIEW-v2.3.md) so you can roll back or audit later. - Keep notes under 1500 characters; if you can’t fit it, your app is too complex to test in 30 minutes — restructure.
- Never include screenshots in App Review notes; Apple’s review tool does not display them reliably. Use unambiguous text and field names instead.