You uploaded a build, filled in the demo username and password, and within a day the submission flips to Rejected (status used to read Metadata Rejected) with a Resolution Center message like “We were unable to sign in to the app with the credentials you provided” or “login error: invalid credentials.” On your phone the same account works fine. The reviewer is hitting your backend from an unfamiliar IP (often Cupertino, or a VPN egress in another region for Apple’s China-region team), through a fresh device with no cached session, and your account either tripped a security rule or never worked outside your test environment.
This is one of the most common Guideline 2.1 (Information Needed) rejections and one of the fastest to fix, but only if you can confirm exactly why the credentials failed on the reviewer’s side.
Fastest fix if you only do one thing: cold-test the exact credentials from your App Review notes on a wiped device with autofill off (Step 1 below). About 70% of these rejections reproduce immediately there: a 2FA prompt, an empty home screen, or a security lock. Fix what you see, then resubmit. Demo-account fixes are metadata-only, so you do not need a new build.
Which bucket are you in
| Symptom on a clean cold login | Most likely cause | Jump to |
|---|---|---|
| Password accepted, then a code prompt you can’t satisfy | 2FA / SMS / email verification | Cause 2, Step 3 |
401 / “invalid credentials” but password is correct | Backend security lock (geo / rate limit) | Cause 1, Step 2 |
| Login fails for every character combination | Stale / deleted account or typo’d notes | Causes 3-4, Step 4 |
| Login succeeds but home screen is empty | Region-locked content or no seed data | Causes 5, Steps 5 + region note |
| Auth endpoint times out / unreachable | Build points at staging behind Access/VPN | Cause 6 |
Common causes
Ordered by hit rate. About 70% of cases are #1 or #2.
1. Backend security rule locked the account
Your auth service (Auth0, Firebase Auth, Cognito, Supabase, custom) saw repeated logins from an unusual geo / IP / user-agent and triggered rate limiting, geo-blocking, or “suspicious activity” auto-lock. The reviewer sees a 401 that looks like wrong credentials but is actually a lock.
How to spot it: Check your auth provider’s dashboard for the demo user during the review window. Look for failed attempt logs from an Apple IP. Apple owns the entire 17.0.0.0/8 block, and review traffic commonly originates there, though Apple does not publish an official review egress list and some reviews come from cloud/VPN ranges (China-region reviews can egress elsewhere). Match on the failed-login timestamp, not just the IP. If you see “account locked” or “too many attempts,” that’s it.
2. The demo account requires 2FA or SMS / email verification
Reviewer types the password, your app asks for a one-time code sent to a phone number or inbox the reviewer can’t access. They give up. You never tested the cold-start flow on a fresh device because your phone was already enrolled.
How to spot it: Sign out completely, wipe app data, reinstall, and log in with the demo credentials on a device that has never seen this account. If a 2FA prompt appears, the reviewer hit the same wall.
3. The account expired or was deleted between submissions
You created a demo account for the v1.0 submission six months ago, then your cleanup script purged inactive accounts, or the password was rotated, or someone on the team disabled the user. The credentials in App Review notes are stale.
How to spot it: Look up the demo account in your admin panel. Check last_login, disabled_at, password_changed_at. If any of these are newer than the credentials in your notes, the account is dead.
4. Credentials in App Review notes were transcribed wrong
Typos in 0 vs O, l vs 1, trailing spaces, smart quotes pasted from a doc, or the wrong field label (“username” when your app wants email). Reviewer enters exactly what you wrote.
How to spot it: Open the credentials exactly as they sit in the App Store Connect Sign-In fields (your app → the version page → App Review Information → Sign-In required → User Name / Password) and paste them into the production login form. If even one character is off, that’s the rejection.
5. Region-locked features behind login
The reviewer is in the US (or your assigned reviewer region), the account works there for basic login, but the home screen is empty because content is geo-restricted to a region the reviewer can’t reach. They mark login as broken because the app looks dead.
How to spot it: Check your content / feature gating logic. If a logged-in user in the reviewer’s region sees an empty state, you need either a sample data set for that region or, per Apple’s own guidance for features the reviewer can’t reach, a link to a short demo video in the Notes field showing the gated functionality working.
6. App requires a separately-provisioned backend (sandbox / staging) the reviewer was never given
Your production build points at staging for App Review, and the staging domain is behind Cloudflare Access or VPN. Reviewer can’t even reach the auth endpoint.
How to spot it: Decompile or strings the build and check the API base URL. If it’s staging.api.yourapp.com and you have Cloudflare Access rules, that’s the problem.
Before you change anything
- Confirm whether sign-in fails only for the demo account or for every account. The Resolution Center reply differs: account-specific means a lock or stale credential, all-accounts means a broken auth deploy.
- Record the reviewer’s exact wording. “Could not sign in” and “login failed with error X” point at different fixes.
- Back up your current auth config (rate-limit table, geo-block list, MFA enforcement flag) before editing rules.
- Check whether your auth provider’s plan still covers the demo user. Some providers silently disable accounts when you exceed the free MAU tier.
Information to collect
- The exact reviewer message and which Guideline (2.1 vs 4.0) was cited.
- Auth provider logs for the demo user, filtered to the past 48 hours.
- The credentials as they appear in the App Store Connect Sign-In fields, character by character (watch trailing spaces and smart quotes).
- Your auth provider’s rate limit + geo-block rules currently in effect.
- A second device (never logged in before) you can use to re-test cold start.
Shortest path to fix
Step 1: Cold-test the credentials on a fresh device
Borrow a phone or use a fresh simulator. Settings → General → Reset → Erase All Content and Settings, install the production build (TestFlight or App Store install of the previous version), and log in using only what’s written in App Review notes. Do not use Keychain autofill. If anything other than the home screen appears within 60 seconds, fix that first.
Step 2: Unblock the demo user in your auth backend
In Auth0 / Firebase / Cognito / Supabase / your own DB:
# Firebase Auth example
firebase auth:export users.json --project your-project
# find the demo user, confirm disabled=false, emailVerified=true
# Or via Admin SDK
node -e "const a=require('firebase-admin');a.initializeApp();a.auth().updateUser('UID',{disabled:false,emailVerified:true})"If the user is in a rate-limit table, drop their entry. If they’re in a geo-block list, whitelist their account or whitelist Apple’s IP range (17.0.0.0/8) for the demo user only.
Step 3: Strip 2FA + verification from the demo user
In your user table, set mfa_enabled = false, requires_phone_verification = false, requires_email_verification = false. If your code path enforces 2FA for all users globally, add a feature flag that exempts accounts whose email matches apple-review-*@yourdomain.com.
Step 4: Fix the App Store Connect Sign-In fields and notes
Put the credentials in the structured fields, not buried in prose. On your app → the version page → App Review Information → tick Sign-In required, then fill User Name and Password with the exact demo values. Use the Notes field only for context (auth codes, region behavior, second accounts).
For the Notes field, paste exactly:
Demo account: credentials are in the Sign-In fields above.
Login: tap "Sign In" on launch (no separate URL).
This account is reset on each submission and is single-device.
No 2FA is enforced for this user. Region-locked features are
pre-enabled; ignore the location prompt.If your app has multiple account types (admin vs regular), add each extra set in the Notes field, and if any account needs a one-time auth code, paste a currently valid code there too. Use straight ASCII quotes, no smart punctuation, no trailing spaces. Avoid “see attached” since Apple does not reliably surface attachments in the review tool; link a video URL instead.
Step 5: Pre-seed sample data and disable analytics for the user
Reviewer logging in to an empty home screen still triggers 2.1. Pre-populate the demo user with three sample documents / messages / playlists so the first screen has real content. Also flag the user as is_internal = true so they don’t pollute your analytics.
Step 6: Resubmit (binary unchanged)
Open the rejected version, fix the Sign-In fields and Notes, then tap Submit for Review (older accounts may show Add for Review then Submit). Demo-account fixes are metadata-only, so you do not need to upload a new build. If the reviewer asked the question in Resolution Center, also reply there confirming the change, since a silent resubmit can sit behind the open thread.
How to confirm the fix
- Logging in with the Sign-In field credentials on a clean device reaches the home screen with sample content in under 30 seconds.
- Auth provider logs show your test login from a non-Apple IP succeeded without lock or 2FA prompt.
- The App Review Information section in App Store Connect renders the credentials and Notes correctly with no encoding artifacts.
- The submission moves from Rejected back to Waiting for Review within 1-2 hours of resubmission (most demo-account re-reviews clear within 24 hours as of June 2026).
If it still fails
- Reply in Resolution Center with a step-by-step demo: paste the credentials again, attach (or link) a 30-second screen recording of you logging in cold.
- Ask the reviewer for the exact error code or screenshot. Sometimes the failure is a captcha, not credentials.
- Provide a second demo account in case the first was rate-limited by the reviewer plus your simultaneous testing.
- If you suspect IP geofencing, ask App Review to confirm their egress region via the Contact App Review form, then add that region to your allowlist.
Prevention
- Maintain a single
apple-review@yourdomain.comaccount that is permanently exempted from MFA, rate limits, geo-blocks, and inactivity sweeps via a database flag, not a maintained allowlist. - Add a CI step that logs into the demo account once per day from a foreign IP (GitHub Actions runner is non-US) and alerts if it fails.
- Pre-seed the demo account with sample data each release so a cold login lands on a populated home screen.
- Document the credentials in a
REVIEW.mdin your repo, and copy them into the App Store Connect Sign-In fields from that file every submission. - Never tie the demo account to a real person’s phone number or email. Use a shared inbox you control forever.
FAQ
Do I need a new build to fix the demo account? No. Demo credentials, the Sign-In toggle, and Notes are metadata. Edit them on the rejected version and tap Submit for Review again with the same binary.
Where exactly do the credentials go in App Store Connect? On your app’s version page, open App Review Information, tick Sign-In required, and fill the User Name and Password fields. The free-text Notes field is for context only (auth codes, region behavior, extra accounts), not the primary credentials.
The account works on my phone but the reviewer says it doesn’t. Why? You’re testing with a cached session, an enrolled 2FA device, and a familiar IP. The reviewer has none of those. Reproduce their conditions: wipe a device, disable autofill, and log in with only what’s in the Sign-In fields.
Can I whitelist Apple’s review IPs?
You can whitelist the 17.0.0.0/8 range for the demo user only, but Apple does not publish an official review egress list and some traffic comes from other ranges. A database flag that exempts the demo account from geo-blocks and rate limits is more reliable than an IP allowlist.
How long does a metadata resubmission take to re-review? As of June 2026, demo-account re-reviews usually clear within 24 hours, and the status returns to Waiting for Review within a couple of hours of resubmitting.
My app is geo-locked and the reviewer’s region shows an empty screen. What now? Pre-seed sample data for the reviewer’s region, or add a link to a short demo video in the Notes field, which is Apple’s recommended path for functionality a reviewer cannot reach directly.