App Store Review Notes and Demo Accounts: The Setup That Avoids Rejection

If your app makes users sign in, App Review needs a demo account that works and notes that tell them how to reach every screen behind that login. Put both in App Store Connect under App Review Information: flip on "Sign-In required," enter a username and password for an account that stays active, and use the Notes field to walk the reviewer to each gated feature step by step. Skip either and you get the single most common rejection login-gated apps hit: the reviewer couldn't test the app, so Apple couldn't approve it.

This isn't the reviewer being difficult. Apple's Guideline 2.1 requires that a submitted app be complete and fully testable, and a wall the reviewer can't get past reads as an incomplete app. The good news: this rejection is almost entirely preventable, and the fix takes about fifteen minutes. Below is the exact setup — where the fields live, what a working demo account actually requires, and a review-notes template you can paste and adapt.

Because a human reviewer has to open your app and exercise its features, and if the first screen is a login they don't have credentials for, they're stuck at the door. Apple's own Common App Rejections guidance puts performance and completeness issues (Guideline 2.1) near the top of the list, and "we couldn't sign in to review your app" is one of the most routine flavors of it. The reviewer won't sign up for your service, invent test data, or guess a password. If they can't get in, they reject and move on. It's worth knowing the other frequent triggers too, since a resubmission that fixes the login only to trip a different guideline still costs you a full review cycle — [the common App Store guideline rejections guide](/blog/app-store-guideline-rejections-guide) breaks them down.

The trap is that everything works on your device because you're already logged in, your account has data, and your paid features are unlocked. The reviewer starts from a clean install with nothing. Every gate you've forgotten about — a paywall, an invite-only flow, a feature that only appears once you have three saved items — is one they'll hit cold. Hand them a key to each one before they ask.

In App Store Connect, open your app version and scroll to the App Review Information section. It's easy to blow past because it sits below the screenshots and description, but it's the part App Review reads first. Four fields matter here:

There's also a Contact Information block (name, phone, email) on the same screen. Fill it with a real person who answers during the review window, because a blocked reviewer messages that contact before rejecting. Google Play has its own version, covered further down. For the wider picture of what happens after you hit Submit, [the App Store review process explained](/blog/the-app-store-review-process-explained) walks the pipeline, and [how long App Store review takes](/blog/how-long-does-app-store-review-take) covers the timing — every rejection sends you back to the end of the queue.

A demo account that exists isn't the same as a demo account that works for a reviewer. Most 2.1 rejections on this front come from an account that technically logs in but hits a wall two screens later. Run through this before you submit:

Good review notes assume the reviewer has never seen your app and has about ten minutes. Don't describe your value proposition — they don't care, and they'll skim past it. Tell them exactly where to tap to reach each thing they need to test. Structure it like a checklist a stranger could follow.

Here's a template you can paste into the Notes field and adapt. Keep it terse — the reviewer wants a map, not an essay:

Play has the same problem and its own home for the answer. In Play Console it's the App access section (under App content): you declare whether all functionality is available without special access, or you provide instructions and credentials for restricted parts. Same principle, same failure mode — if the reviewer can't get into a gated flow, your release gets held up. Provide a demo login, document the path to each gated feature, and keep the account active. The two stores diverge in plenty of places once you're live and users start reviewing you, covered in [App Store vs Google Play review replies](/blog/app-store-vs-google-play-review-replies), but on the submission demo-account question they want the same thing: a way in and a map.

The demo-account fix gets you through App Review once. The moment you're live, a different and never-ending kind of review begins: public star ratings and written feedback from real users — and unlike App Review, these you answer for the life of the app. Some will be about the exact login flow you just spent a day getting past a reviewer, because a stranger's device is where edge cases live.

That's the job [ReplyArgus](/features) is built for. It watches your App Store and Google Play reviews in one inbox, drafts an on-brand reply in the reviewer's own language grounded in your past replies and store listing, and lets you approve each one (or auto-publish only the safe cases you opt into by rating, keyword, and language). It won't write your App Review notes — that's a one-time submission task — but it handles everything after launch, so a rough first-week login complaint gets a fast, specific answer instead of sitting for a week. Here's the kind of reply it drafts for exactly that:

That reply is specific, grounded, and out the door in minutes instead of Monday — the difference between a two-star that stays two and one the user quietly updates. For the full playbook on the angry ones, see [how to respond to negative app reviews](/blog/how-to-respond-to-negative-app-reviews).

Set the demo account, fill the Notes with a tap-by-tap map, kill any 2FA the reviewer can't clear, and do one clean-install dry run before you submit — that's the whole defense against the most common login-gated rejection. Once you're through and live, [start free with ReplyArgus](/signup) (no card): both stores land in one inbox with a grounded reply already drafted, so the reviews that come after launch never sit unanswered while you build the next release.