App Store review demo account: how to set up a reviewer login that passes review (2026)

If any part of your app sits behind a login, your App Store review demo account has to work the first time Apple tries it. Apple's App Review Guidelines ask for demo account info, or a fully featured demo mode, and for your backend to be live during review. In practice that means a dedicated account that never expires, already has realistic data, reaches every paid and role-based feature, and doesn't need a login code only you can see. This guide covers how to build that account, how to write the notes that go with it, and what other developers ran into when it failed.

What does Apple require for an App Store review demo account?

Apple requires a working demo username and password whenever an app needs a login, entered under App Review Information in App Store Connect, and the account must not expire. Guideline 2.1(a) also requires your backend to be running during review.

The wording of guideline 2.1(a) is: "include demo account info (and turn on your back-end service!) if your app includes a login." App Store Connect's platform version information reference adds that "the demo account is used during the App Review process and must not expire", that "details for additional accounts should be included in the Notes field", and that Notes "can contain up to 4000 bytes." The Sign-in required fields apply "if your app requires a login to use it."

Apple's complete review help page gets more specific: "Credentials that expire or change before your review starts may result in the submission being rejected." If your app has several account types, such as admin and general user, add credentials for each one in Notes. If you sell auto-renewable subscriptions, "provide a demo account with an expired subscription to enable review of the entire purchase flow."

How do you set up a demo account for App Review?

Set up a demo account by creating a dedicated production account, keeping every expiry and cleanup job away from it, filling it with realistic data, and signing in to it on the exact release build before you submit.

1. Create a dedicated production account, such as appreview@yourdomain.com. Don't reuse a personal or QA account that someone might change.
2. Exclude it from every cleanup job: password rotation, inactive-account deletion, trial expiry and fraud rules.
3. Seed it with realistic content so no screen is empty. Reviewers judge completeness by what they see.
4. Set its subscription state to match Apple's guidance. If you sell subscriptions, the account should have an expired subscription so the paywall and purchase flow show up.
5. Set it to a region where all your features work, or describe the regional differences in Notes.
6. Sign in on a clean device using the exact release build you're submitting, then walk through each feature you mention in Notes.
7. Don't touch the password again until the review is over.

What if the app uses login codes, SMS OTP, magic links or SSO?

If sign-in needs a one-time code, write a fixed code for the review account in Notes before you submit. Apple warns that without one, "a call may be required to continue the review", and those calls are "typically completed within three to five business days."

For emailed magic links or SMS one-time codes, set up the review account so it accepts a fixed code or password, and put that code in Notes. If you use a third-party single sign-on service, App Store Connect asks you to "include the demo account login information for it" as well.

If you can't share a demo account for legal or security reasons, which is common in banking, health and other regulated apps, guideline 2.1(a) lets you use "a built-in demo mode in lieu of a demo account with prior approval by Apple." That demo mode has to show "your app's full features and functionality" using demonstration data, not a cut-down tour.

Which accounts should you give App Review?

Give App Review one non-expiring login for each account type in your app, plus whatever it needs to get past codes, paywalls and hardware requirements. This table maps each setup to where it goes.

What should App Review notes for a demo account say?

Good review notes give the app's concept, every login, the login code, how to reach the paywall, where each feature lives, any regional differences and the devices you tested on. Here's an example for an imagined team habit tracker that uses emailed login codes and a Pro subscription.

CONCEPT: Team habit tracker. Coaches create groups; members log daily habits.
Pro subscription (monthly/annual) unlocks progress reports.

ACCOUNTS (non-expiring, pre-filled with 30 days of data):
- Member: review-member@example.com (in the username/password fields)
- Coach: review-coach@example.com / password: [shared here]
- Deletion test: review-delete@example.com / password: [shared here]

LOGIN CODE: The app emails a 6-digit code. For these review
accounts, enter 246810.

SUBSCRIPTION: The member account's subscription has expired.
Tap Reports > Upgrade to see the full purchase flow.

WHERE TO LOOK: Groups tab (coach) > Create group. Today tab (member)
> Log habit. Settings > Account > Delete account.

REGIONS: All features work the same in every storefront.
TESTED ON: iPhone 15 (iOS 26), iPad Air (iPadOS 26).
SERVICES: Supabase (auth/data), RevenueCat (subscriptions).

Keep it short and practical. For updates, Apple's help page says to "describe what's changed, and where reviewers can find significant new content or features." Guideline 2.3.1(a) requires new features to be "described with specificity" and warns that "generic descriptions will be rejected." Guideline wording changes several times a year, so read our summary of the October 2026 App Review Guidelines changes before you submit.

Why do demo account logins fail in review? Real cases

In public reports, demo logins usually fail for one of two reasons: a second factor the reviewer can't receive, or an account that works for the developer but returns an error on Apple's device. Two Apple Developer Forums threads show both.

SMS two-factor on a key feature. A developer on the Apple Developer Forums said their app was "constantly being rejected" because profile editing required a code sent by text to a US mobile number. They explained that "since we do not have the cell phone number of the reviewer... the reviewer does not get the validation code." Other developers in the thread described fixes: one changed the backend "so that the test account always gets the same 2FA code" and listed it in the notes, and another linked a production account to a virtual phone number and gave Apple access to it.

Credentials that work everywhere except review. A React Native and Expo developer using Supabase email and password auth reported repeated rejections. Apple's screenshot showed the correct email and the error "Invalid login credentials", yet sign-in worked from the developer's devices, Postman and the Supabase client, with no MFA, rate limiting or geo-blocking. The thread has no confirmed cause. The developer was considering adding a demo mode, but under guideline 2.1(a) that route needs Apple's prior approval.

What the cases have in common: the reviewer's experience is the only test that counts. A fixed code written in Notes fixes the second-factor problem. For the "works for me" problem, you need to sign in on the release build, on a clean device, against production, and then leave the account alone.

What should you check before submitting with a demo account?

Before you submit, confirm the demo login works on the release build, every role and code is in Notes, and nothing will expire, rotate or delete the account during review.

• Signed in to the release build on a clean device within the last hour
• Backend, auth provider and email or SMS service are all live and not rate-limiting the account
• Account is excluded from expiry, cleanup and password-rotation jobs
• Every role has its own login in Notes
• Subscription state shows the purchase flow
• A separate account is ready for the deletion test
• Login code or bypass is written in Notes
• Contact phone number is in international format with a plus sign (+), and someone will answer it

According to Apple's App Review page, "on average, over 40% of unresolved issues are related to guideline 2.1: App Completeness," which covers incomplete information. A broken demo login is one of the easiest of those to prevent. To check the rest of the build, use our release-build test plan for 2.1 rejections.

What do you do if App Review still can't sign in?

If App Review can't sign in, fix the account, test it again on the release build, update the App Review Information and reply in App Store Connect saying exactly what you changed. App Review Information "can be edited at any time."

Read the rejection message closely. Often the cause is a simple mismatch: a password changed, a session expired, or the reviewer was in a region your backend blocks. Our guide to turning a review message into a fix walks through the reply. If you'd rather hand the review setup off, our App Store submission service prepares the review and works through rejection feedback with you, for $599 covering both stores (developer account fees are separate).