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. Two things break most often. First, you typed the demo login into the free-text Notes box instead of the dedicated Sign-In Required username and password fields, so the reviewer’s automated/first-pass login never sees it. Second, the Notes field renders as a wall of plain text (4000-byte limit, as of June 2026) inside an internal Apple tool that reviewers skim in well under a minute. 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.
Fastest fix: Put the working demo username and password in the Sign-In Required fields (App Store Connect, on the version page). Then rewrite the Notes field as a scannable form — credentials restated at the top, “what changed,” then numbered test steps with the exact tab/button names. Resubmit notes-only; no new build needed.
Where the fields actually live (June 2026)
App Store Connect splits review information into three distinct boxes. Putting the right content in each is half the fix.
| Field (exact label) | What goes here | Common mistake |
|---|---|---|
| Contact Information | Name, email, phone of someone who answers fast | Left as the org default; nobody monitors it |
| Sign-In Required | Demo account Username and Password (toggle on if your app needs login) | Credentials typed into Notes instead, or toggle left off |
| Notes | Up to 4000 bytes of plain text: what changed, step-by-step test paths, gating, configs | Marketing copy, prose flows, stale instructions |
| Attachment | Optional file: screen recording (.mp4), authorization docs (.pdf) | Believing attachments “don’t display” — they do |
The Sign-In Required demo account must not expire, and if you use single sign-on (Sign in with Apple, Google, etc.) you must still supply a working demo login for it. Extra accounts go in Notes.
Common causes
Ordered by hit rate. The first three account for most repeat rejections.
1. Credentials are in the Notes wall, not the Sign-In Required fields
You pasted “Username: … / Password: …” into the free-text Notes box and never turned on the Sign-In Required toggle. Reviewers expect a login in that structured field; when it’s empty they may bounce the build under Guideline 2.1 before reading prose.
How to spot it: Open App Store Connect → your app → the version → App Review Information. If Sign-In Required is off (or its Username/Password are blank) but your app shows a login screen, this is your problem.
2. The demo account is empty or expired
Reviewers can’t evaluate a social feed with no posts, a notes app with no notes, or an account whose trial lapsed. As of June 2026 Apple’s own guidance is explicit: if your app needs content to function, pre-seed the demo account with sample data, and the account must not expire.
How to spot it: Sign into the demo account on a fresh device right now. Empty home screen, expired session, or a paywall with no test path? Fix the seed data before resubmitting.
3. Credentials are present but malformed
You wrote “Password: see below” with the actual password elsewhere; or smart quotes copy-paste broken; or you wrote “any password works” (true in dev, false in staging). The reviewer’s first login attempt fails.
How to spot it: Copy the credentials into a plaintext editor. Curly quotes, em-dashes, non-breaking spaces, or username and password on different lines? Fix the formatting and retype, don’t paste from a styled doc.
4. 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 wrong, 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.
5. 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”. The 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.
6. Notes weren’t updated between submissions
Your v2.3 notes still describe the v1.0 user journey. The reviewer follows your steps, lands somewhere else, and gives up or asks what changed. Apple rejects “generic descriptions” of new functionality — every changed feature must be described specifically.
How to spot it: Diff your current notes against the previous version’s text (in your repo, if you store them) or the previous submission. Identical text but a materially changed build means you missed an update.
7. 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” is irrelevant. Sentimental framing pushes the facts further down.
How to spot it: Highlight every sentence 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 (note which guideline number it cites).
- 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, pre-seeded, non-expiring demo account with documented credentials.
Shortest path to fix
Step 1: Fill the structured fields first
Before touching the Notes box: in App Review Information, turn on Sign-In Required and enter the demo Username and Password in those fields. Fill Contact Information with a person who will actually answer email or a call within a business day. This alone clears a chunk of “demo account did not work” rejections.
Step 2: Use the canonical reviewer-notes template
Replace the entire Notes field with this structure. Paste, fill in each block, delete anything optional. Restate the credentials here too — redundancy costs nothing and a reviewer reading top-to-bottom should never have to hunt.
DEMO ACCOUNT (also entered in Sign-In Required)
Where to sign in: in-app, tap "Sign In" on launch
Email: apple-review-2026@yourdomain.com
Password: ReviewPass-Spring2026!
No 2FA. Pre-seeded with sample data. Account does not expire.
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" and wait about 5 seconds for processing.
5. Expected: enhanced image preview with a before/after slider.
HOW TO TEST PAYWALL
1. After signing out, sign up with any new email.
2. Try to open "AI Photo Editor" — the 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 3: Audit every screen you mention
Open your build on a fresh simulator and walk the exact path you described. Every “tap,” “scroll,” and “wait” 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 4: 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 don’t need to feel welcomed; they need to find the button.
Step 5: Lock notes in version control
Create or update REVIEW.md in your repo. The next release’s notes start from this file. Every submission, diff against the last 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.mdPaste from REVIEW.md into the Notes field; reviewers see the same text you reviewed.
Step 6: Have a non-developer cold-test
Find someone who didn’t build the feature. Hand them only the rewritten notes and a freshly installed device. If they reach the cited feature in 5 minutes, the reviewer probably can too. If they can’t, edit until they can.
Step 7: Resubmit (notes-only, no new build)
App Review information can be edited at any time and is not visible to customers. In App Store Connect, open the version, update the fields, and use Add for Review / Submit for Review. A notes-and-credentials-only change does not require re-archiving a new build.
How to confirm the fix
- Sign-In Required is on and you can log in with those exact credentials on a clean device, into an account that has sample data.
- Your Notes pass the “skim” test: a stranger finds demo credentials and a feature walkthrough in the first half-screen.
- The next submission either passes or gets a different rejection — the same rejection twice means the rewrite missed.
- Resolution Center replies acknowledge the new information instead of repeating earlier questions.
If it still fails
- Reply in Resolution Center quoting the exact lines in your notes that address the reviewer’s question.
- Attach a 30-second screen recording (.mp4) of the cited path using the Attachment field — Apple’s review tool does display these, and supported types include
.mp4,.png,.jpg,.pdf, and.zip. - In your Resolution Center reply, write that you’d prefer to discuss by phone; Apple schedules the call rather than publishing a number. Walk the reviewer through the path live.
- If the same gap is rejected twice for what reads like a misunderstanding, escalate to the App Review Board (the appeals channel) rather than just resubmitting.
Prevention
- Treat Sign-In Required as mandatory whenever your app has a login; never rely on credentials buried in Notes alone.
- Keep the demo account permanently seeded with sample data and set it never to expire.
- Maintain
REVIEW.mdin your repo as the single source of truth; every submission copies from it. - Add a release-checklist item: “diff REVIEW.md vs previous; non-dev tester walks the notes; confirm demo login works today.”
- Save each submission’s notes as a tagged file (
REVIEW-v2.3.md) so you can roll back or audit later. - The Notes field holds up to 4000 bytes; if you can’t describe the test path in that budget plus an attached video, the flow is probably too tangled to review in one pass — simplify it.
Related reading
- App Review Guideline 2.1 — more info needed
- Demo account stops working during review
- Reviewer can’t access gated features
- Draft an App Review appeal with AI
External references: Apple App Review Guidelines and Reply to App Review messages.