Guideline 2.1 – Information Needed: why Apple can't sign in with your demo account

“Guideline 2.1 – Information Needed” is not a verdict on your app. It is App Review telling you they got stuck before the review really started — and by far the most common reason is a sentence like “We were unable to sign in with the demo account credentials you provided.” The submission sits in Rejected (or Metadata Rejected) until you reply, and every round trip costs a day or more. Here is why it happens and how to close it in one reply.

What Guideline 2.1 actually requires

The relevant sentence in the App Store Review Guidelines, section 2.1(a), reads: “include demo account info (and turn on your back-end service!) if your app includes a login. If you are unable to provide a demo account due to legal or security obligations, you may include a built-in demo mode in lieu of a demo account with prior approval by Apple.” Two requirements hide in there: a working account and a live backend for the entire review window.

The credentials go into App Store Connect under App Review Information → Sign-in required (username and password), with anything else the reviewer needs in the Notes field. App Store Connect's own help text says the demo account “is used during the App Review process and must not expire”.

The three causes, in order of frequency

1. The account is real but does not work from a clean device. The password expired, the account was locked by a rate limiter after a few reviewer attempts, sign-in needs an SMS or email one-time code the reviewer cannot receive, or the username was typed into App Store Connect with a trailing space. All of these look identical from Apple's side: the login button does nothing useful.
2. The backend was not live. Staging environments that are torn down between deploys, a database that only runs when someone is developing, an API behind a VPN or IP allowlist, a free-tier server that sleeps after inactivity. The reviewer signs in at 3 a.m. your time and gets a spinner.
3. There is no way in at all. The app requires an account, no credentials were provided, and there is no guest mode. This is the classic first submission from a solo developer who is always logged in on their own phone and never noticed the wall.

How to reply so the next round passes

Do not resubmit the same build with the same notes. Fix the cause, then reply with the new credentials and a short explanation. Concretely:

• Create a dedicated review account on production, not staging. Give it a password that never expires and exclude it from rate limits, two-factor prompts and email verification. Pre-fill it with realistic data so every screen has content.
• If sign-in needs a one-time code, either whitelist the review account to skip it or put a fixed code in the Notes field. Apple explicitly tells you to include “test registration or account details” there.
• If the app uses Google, Facebook or another single sign-on, provide the demo login for that provider too — App Store Connect asks for it by name.
• Test the exact credentials on a freshly installed build right before you submit, copy-pasted from App Store Connect.
• Keep the backend up for at least a week after submission. If it is a serverless or free-tier deployment, check it does not sleep.

Better: remove the wall

If your app does not strictly need an account to be useful, add a guest or demo mode and let review — and your future users — walk in without credentials. A large share of 2.1 rejections simply disappear. If you cannot provide an account for legal or security reasons, the guideline allows a built-in demo mode instead, but it must show the app's full functionality and it needs Apple's prior approval — say so in the Notes field rather than surprising the reviewer.

What else lands under 2.1

Demo accounts are the headline, but 2.1 covers app completeness in general. The same template is used when the build crashes on launch, when a screen still shows placeholder text, when a linked URL (privacy policy, support) is empty, when in-app purchases are not submitted alongside the binary, or when the reviewer needs hardware or a sample file (a QR code, a paired device) to test a feature. The fix pattern is the same: assume the reviewer has nothing but the .ipa and your notes, and give them everything needed to see every screen.

A pre-submission checklist

• Sign-in required is ticked and the username/password fields are filled (if the app has a login).
• The demo account works on a clean install, on production, with no 2FA, and does not expire.
• Notes explain anything non-obvious: how to reach paid features, test codes, which hardware is needed.
• The backend and any third-party service (auth provider, payment sandbox) stay up through the review.
• The contact phone number is in international format with a leading plus sign, so a reviewer can ask a quick question instead of rejecting.

These are metadata-level questions, so no binary scan can answer them for you — but they are exactly the kind of thing you never notice on your own phone because you are always logged in. RejectProof's free 10-question check asks them before you submit, including whether working demo credentials are in App Review notes.