You submit a build for review and 24-48 hours later the status changes to Metadata Rejected with the heading “Guideline 2.1 — Information Needed.” The body usually contains 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.” It is not a binary problem — it’s a documentation problem. The reviewer is telling you they could not reach a code path and need you to bridge the gap before they continue.
The fastest path through is to answer the literal question in App Review notes, push Submit for Review again with no new build, and the listing usually re-enters the queue within an hour.
Common causes
Ordered by hit rate. Roughly 80% of 2.1 rejections are #1 or #2.
1. No demo account in notes for an auth-required app
You shipped a sign-in wall on launch with no “Skip” button, but App Review notes either lack credentials, list expired ones, or only mention SSO providers (Apple / Google) the reviewer can’t sign into with their personal accounts.
How to spot it: Open the build on a clean simulator. If you can’t reach any screen past the first launch without an account, and the App Review notes field in App Store Connect is empty or stale, this is your case.
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.0, 2.1.1).
- 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.
- Existing App Review notes text, 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: Add the missing piece to App Review notes
In App Store Connect → your app → App Information → App Review Information, write a structured block. Pick the relevant template:
Demo account block:
DEMO ACCOUNT
Email: apple-review-2026@yourdomain.com
Password: ReviewPass-Spring2026!
No 2FA required. Account is pre-seeded with sample data.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,
verification code is hard-coded to 000000 for any apple-test+* email.Step 3: Add a reviewer-mode toggle if needed
For features that fundamentally cannot work in a reviewer environment (real money, real bank, real hardware), ship a build-time flag that mocks the integration when the app detects a reviewer account or a specific bundle ID variant. Document the toggle in notes:
REVIEWER MODE
Tap the app icon 5 times on the lock screen to enable reviewer mode.
This replaces live bank data with sample transactions for testing.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-only, no new build is needed. In App Store Connect → App Store tab → tap the rejected build → Submit for Review. The submission re-enters the queue, usually with the same reviewer.
If you needed to change reviewer-mode code, archive a new build in Xcode, upload via Xcode Organizer or Transporter, wait ~30-60 minutes for processing, then submit.
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.
- If the reviewer cites the same gap twice, ask Apple to assign a fresh reviewer via the Contact App Review form.
- Provide a second, fully-disjoint demo account in case the first was rate-limited during your testing.
- As a last resort, request a Phone Call from App Review (in App Store Connect → Resolution Center → “Request a Call”) to walk through the reproduction live.
Prevention
- Always include demo account credentials in App Review notes from day one — even if the app has no sign-in wall today, you may add one tomorrow.
- Document region, hardware, and verification requirements in a
REVIEW.mdin your repo; copy from that file into App Review notes every release. - Pre-seed the demo account with sample data via a script that runs on each release.
- Add a “reviewer mode” feature flag for any flow that can’t be tested in a normal environment.
- Have one non-developer on the team cold-install the build and read only App Review notes — if they can’t reach the core feature in 5 minutes, neither can a reviewer.
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
Tags: #Troubleshooting #App Store #App review #Guideline 2.1