You submit a build and, after the review (a median of about 24 hours as of June 2026), the status changes to Metadata Rejected with the heading Guideline 2.1 - Information Needed. The body is a polite paragraph that boils down to one of three asks: please provide demo account credentials, please walk us through how to access [feature X], or this feature appears to require [region/hardware/permission] we couldn't test. This is not a code defect. It is a documentation gap: the reviewer could not reach a code path and needs you to bridge it before they continue.
Fastest fix: answer the literal question in the App Review Information section, confirm your backend is live, and push Submit for Review again. In the common case this needs no new build, and the listing re-enters the queue within an hour or two with the same reviewer. The one exception is if the missing piece is a reviewer-only code path (mock data, a hidden toggle); that needs a new build and a fresh ~24-hour review.
Note that Apple labels a 2.1 Information Needed response as a Metadata Rejected status, but it is closer to a held conversation than a hard rejection. You reply, you supply what is missing, and the same reviewer usually picks it back up.
Which bucket are you in
Read the rejection once, then match it to a row. The fix differs by bucket, and most teams misdiagnose by jumping straight to “write better notes” when the real problem is a dead backend or empty credential fields.
| Reviewer’s words include | Likely cause | Primary fix | New build? |
|---|---|---|---|
unable to sign in, credentials did not work | Empty/stale demo fields, or backend off | Fill demo fields; confirm backend live | No |
unable to locate, did not load, could not find [feature] | Region/age/hardware/empty-state gate | Document the gate or pre-seed data | No |
could not create an account, did not receive a code | SMS/email/invite verification wall | Provide a demo account or bypass code | No |
requires a [bank/device/payment] we could not test | Real-money or hardware dependency | Demo mode (needs Apple pre-approval) | Usually yes |
screen was blank, feature did not appear | Orientation/locale/accessibility gate | Document required device state | No |
Common causes
Ordered by hit rate. Roughly 80% of 2.1 rejections are #1, #2, or #3.
1. No demo account, or the backend is off
Two failures hide in one bucket. The first: you shipped a sign-in wall on launch with no “Skip” button, but the demo-account fields in App Store Connect are empty, list expired credentials, or only mention SSO providers (Apple / Google) the reviewer can’t sign into with their personal accounts. The second, which Apple’s own Guideline 2.1 calls out explicitly (“turn on your back-end service!”), is that the credentials are correct but your staging/production API is paused, scaled to zero, or IP-allowlisted, so sign-in spins and fails for the reviewer even though it works for you on a warm connection.
How to spot it: Open the build on a clean simulator on a fresh network (toggle Wi-Fi off, use cellular, or a VPN to a US exit). If you can’t reach any screen past the first launch without an account, check two things in App Store Connect: is the Sign-In Required toggle on with a real username and password filled in, and is your backend actually serving requests right now? A backend that sleeps after idle (free-tier Render, Fly.io scale-to-zero, a paused Firebase project) is the classic invisible cause.
2. Feature is region-locked, age-gated, or hardware-gated
Sports scores for one league, mobile payments in a single country, AR features that need LiDAR, HealthKit data flow that needs an Apple Watch — the reviewer device or account doesn’t satisfy the gate, so the feature looks broken or missing.
How to spot it: Search the rejection for phrases like “we were unable to locate” or “this feature did not load.” Cross-reference against your gating logic: does this feature only render for region == "JP", age 18+, or a specific iPhone model?
3. Account creation needs SMS / email verification the reviewer can’t pass
Self-signup works for normal users but requires a phone number SMS code, a corporate email domain, or an invite code. Reviewer signs up, never gets the code, gives up.
How to spot it: Try signup with a brand-new email + phone number from a different country. If you don’t get a code within 60 seconds, neither did the reviewer.
4. The feature requires real money or a real third-party account
Bank account connection (Plaid), crypto wallet (MetaMask deep link), real-money IAP outside sandbox, or a hardware peripheral (smart lock, fitness scale). Reviewer can read the UI but can’t test the actual flow.
How to spot it: Look at the cited screen in the rejection. If you’d need a real bank, real money, or a real device to complete the flow, that’s the gate.
5. App requires a specific orientation, locale, or accessibility setting to test
You ship a landscape-only iPad layout for a specific use case, or a feature only appears when VoiceOver is on. Reviewer’s default device setup hides what you intended to show.
How to spot it: Re-read the build’s Info.plist for UISupportedInterfaceOrientations and re-check your conditional rendering. If a default-state iPhone in portrait sees an empty screen, the reviewer did too.
6. Initial state is empty by design
Reviewer signs in to a new account and the home screen says “You don’t have any X yet — create your first one.” They tap around, can’t find the core feature working, and rejects. You meant for them to populate it, but didn’t say so.
How to spot it: Cold-install, sign up with a fresh account, do nothing — does the home screen feel like a working app or a tutorial overlay? If it’s the latter, you need pre-seeded data or explicit notes.
Information to collect
- The reviewer’s exact wording, including any subsection (2.1, 2.1(a), 2.1(b)). The (b) subsection is specifically about in-app purchases not being visible or functional.
- Confirmation that your backend is live and reachable from outside your office network right now.
- A screen-by-screen reproduction of the path the reviewer would take from cold-install.
- All gating logic that could hide the cited feature: region, age, hardware, locale, role.
- The current contents of the demo username/password fields and the Notes field, so you can diff what you change.
- Test account credentials, sample data, and any VPN / region toggle the reviewer needs.
Shortest path to fix
Step 1: Decode the literal request
Re-read the rejection and reduce it to a single sentence: “I could not [verb] [noun] because [missing thing].” Examples:
- “I could not sign in because no credentials were provided.”
- “I could not see live scores because none were available in the US during my review.”
- “I could not connect a bank because Plaid asked for SSN I don’t have.”
Write this sentence down. Every other action you take must remove the “because” clause.
Step 2: Fill the right field, not just the Notes box
There are two distinct places in App Store Connect, and putting credentials only in the free-text Notes box is the single most common mistake. As of June 2026 the path is: App Store Connect → My Apps → your app → the version under “iOS App” in the left sidebar → scroll to App Review Information. There you will find:
- A Sign-In Required toggle. Turn it on if your app has any login. This reveals dedicated User Name and Password fields. Put the demo credentials here, not buried in prose. Reviewers read these fields first.
- A Notes field, plain text, with a 4000-character limit. Use it for everything that is not the raw username/password: walkthrough steps, region/hardware setup, IAP explanations, and any reviewer-mode instructions.
- An optional Attachment slot. Attach a short screen recording (under ~50 MB) if a flow is hard to describe in text.
Fill the username/password fields, then add the relevant Notes block below. Pick the template that matches your bucket:
Demo account (also goes in the dedicated fields):
DEMO ACCOUNT
Email: apple-review-2026@yourdomain.com
Password: ReviewPass-Spring2026!
No 2FA required. Account is pre-seeded with sample data.
Backend is live; no VPN needed.Region-locked feature block:
REGION REQUIREMENTS
Live scores feature is available only in US/CA/UK.
To test: Settings > General > Language & Region > Region: United States.
Or use the demo account above (pre-set to US region; ignore location prompt).Verification-gated signup block:
SIGNUP SHORTCUT
Standard signup requires SMS verification.
Use the demo account above to bypass.
If you must test signup: use email apple-test+<random>@yourdomain.com.
The verification code is hard-coded to 000000 for any apple-test+* email.Step 3: Add a reviewer-mode / demo mode if needed
For features that fundamentally cannot work in a reviewer environment (real money, real bank, real hardware), ship a flag that mocks the integration when the app detects a reviewer account or a hidden trigger. Guideline 2.1(a) explicitly allows a built-in demo mode “in lieu of a demo account” only when you cannot provide credentials for legal or security reasons, and Apple says this requires prior approval, and the demo mode must “exhibit your app’s full features and functionality.” A skeleton mode that only shows a couple of screens will be rejected again.
In practice: a hidden reviewer toggle that unlocks a fully-seeded demo account is fine for most apps and needs no special approval. A true demo mode that bypasses login entirely is the path you must clear with Apple first, by explaining the legal/security constraint in Notes or Resolution Center. Document whichever you ship:
REVIEWER MODE
On the login screen, tap the version number at the bottom 5 times to enable reviewer mode.
This replaces live bank data with sample transactions. No real account is contacted.Step 4: Pre-seed the demo account with realistic data
A reviewer who lands on a populated home screen rates the app’s design and functionality; one who lands on an empty state assumes it’s broken. For each major feature your app surfaces, the demo account should have at least one piece of representative data.
Step 5: Resubmit
If your fix is notes/credentials-only, no new build is needed. Open the rejected version in App Store Connect and tap Submit for Review again. The submission re-enters the queue, usually with the same reviewer, who already has your earlier context.
If you needed to change reviewer-mode code, archive a new build in Xcode, upload via Xcode Organizer or Transporter, wait for processing (often 10-30 minutes as of June 2026, occasionally longer), select the new build, then submit. Expect a fresh ~24-hour review.
Step 6: Reply in Resolution Center
In addition to resubmitting, post a reply that quotes the reviewer’s question and points at the exact lines in App Review notes that now answer it:
“Thank you for the feedback. We have added demo credentials and a step-by-step walkthrough for the live scores feature in App Review Information. The credentials are pre-set to US region; please tap ‘Today’s Games’ on launch.”
How to confirm the fix
- The reproduction path you wrote down in Step 1 now works end-to-end on a clean simulator with only what’s in App Review notes.
- Submission status moves from Metadata Rejected to Waiting for Review within 1-2 hours of resubmission.
- No new ITMS warning emails arrive after the metadata change.
- The reviewer’s follow-up reply (if any) acknowledges the new information instead of asking the same question again.
If it still fails
- Reply in Resolution Center with a 30-second QuickTime screen recording showing the path from cold install to the cited feature. Reviewers typically respond within ~24 hours.
- If the reviewer cites the same gap twice, it usually means your fix did not land where they look. Re-check that the credentials are in the dedicated User Name / Password fields (not only the Notes box) and that Sign-In Required is on.
- Provide a second, fully-disjoint demo account in case the first was rate-limited or locked during your own testing.
- Ask to speak by phone: reply in Resolution Center and request a call. Apple schedules these on request, and a 10-minute walkthrough often clears a stuck 2.1 faster than another round of text.
- If you genuinely believe the rejection is wrong (not just incomplete), escalate to the App Review Board from Resolution Center. Use this for disputes, not for “I forgot to add credentials” cases, which the Board will simply bounce back to fixing your notes.
Prevention
- Always fill the demo username/password fields and turn on Sign-In Required from day one, even if the app has no sign-in wall today; you may add one tomorrow.
- Confirm the backend serving the demo account is on a plan that does not scale to zero or sleep, or warm it right before you submit. A sleeping free-tier API is the most common silent 2.1 cause.
- Document region, hardware, and verification requirements in a
REVIEW.mdin your repo; copy from that file into the Notes field every release. - Pre-seed the demo account with sample data via a script that runs on each release.
- Add a reviewer-mode flag for any flow that cannot be tested in a normal environment.
- Have one non-developer on the team cold-install the build and read only the App Review Information you filled in. If they can’t reach the core feature in 5 minutes, neither can a reviewer.
FAQ
Is “Guideline 2.1 - Information Needed” a rejection or a question?
It shows as Metadata Rejected, but functionally it is a held conversation. The reviewer paused because they hit a wall. Supply the missing piece and resubmit, and the same reviewer usually continues from where they stopped.
Do I need a new build to fix a 2.1 Information Needed? Usually no. If the fix is credentials, notes, or turning your backend back on, just edit the App Review Information and tap Submit for Review. You only need a new build if the fix is in code (a reviewer-mode toggle or mock data).
My login works for me but the reviewer says credentials failed. Why? The most common cause is a backend that is paused, scaled to zero, or IP-allowlisted, so it answers your warm session but not a cold request from Apple. Apple’s Guideline 2.1 literally says “turn on your back-end service.” Hit your login endpoint from a fresh network and confirm it responds before resubmitting.
Where exactly do the demo credentials go? In the dedicated User Name and Password fields that appear once you turn on Sign-In Required in App Review Information, not only in the free-text Notes box. The Notes field (4000-character limit) is for walkthrough steps, region setup, and IAP explanations.
Can I just bypass login with a demo mode? Only with conditions. Guideline 2.1(a) allows a built-in demo mode “in lieu of a demo account” when legal or security rules stop you from sharing credentials, but it needs Apple’s prior approval and must show the app’s full features. For most apps, a hidden toggle that signs into a seeded demo account is simpler and needs no approval.
How long until it is back in review after I resubmit? A notes-only resubmission typically re-enters the queue within an hour or two and is often picked up the same day. A new build triggers a fresh review, with a median of about 24 hours as of June 2026.
Related reading
- App Store review common rejections
- Demo account stops working during review
- App Review notes not clear enough
- Reviewer can’t access gated features
- Draft an App Review appeal with AI
- Apple’s official text: App Review Guidelines, section 2.1 App Completeness
Tags: #Troubleshooting #App Store #App review #Guideline 2.1