An App Review demo account should give Apple stable, full access to the features being reviewed without depending on you in real time. Create a dedicated production-accessible account, seed the required state, remove avoidable authentication blocks, test it from a clean device, and keep it active until review is complete.
The account is not just a username and password. It is a review environment: role, data, region, entitlements, backend availability, and instructions must work together. Place that access work in the wider sequence from the first iOS App Store submission guide.
The short version
- Use a dedicated account that will not expire or be reused by your team.
- Preload the role, data, and entitlement needed for the review path.
- Do not require a code sent only to your phone or inbox.
- Test the credentials and Review Notes on the exact submitted build.
When Apple needs review access
Apple’s current App Review guidance asks for full access to account-based features through an active demo account or a fully featured demo mode. It also asks you to provide other resources needed for review, such as hardware or a sample QR code.
That means a demo account is normally needed when sign-in gates any feature Apple must inspect. A public browse mode is not enough if purchases, creation, deletion, moderation, or role-specific workflows sit behind authentication.
Apple’s Guideline 2.1 says to include demo account information when the app includes login. If your architecture cannot support a standard account for a justified reason, explain the alternative access arrangement clearly in App Review Information. Do not silently assume the reviewer will create an account with personal details.
Build a dedicated account, not a borrowed one
Create an account only for App Review. A founder’s everyday login is risky because its password, role, data, and security state can change without the release owner noticing.
The review account should have:
- a stable identifier and password;
- the minimum role that still exposes all submitted features;
- representative, non-sensitive sample data;
- the required subscription or purchase state;
- region and language settings that match your notes;
- no automatic expiry or scheduled cleanup;
- monitoring that does not lock it for normal reviewer activity.
Never seed real customer information. Use clearly synthetic names and content. If the app supports user-generated content, ensure the sample material is safe and that moderation actions can be inspected without touching production users.
Document who owns the account and when it may be rotated after review. “Temporary” accounts have a habit of being deleted before an update is reviewed.
Remove authentication dead ends
The reviewer must be able to authenticate without waiting for you. Audit every challenge after username and password:
- email verification;
- SMS or authenticator codes;
- magic links;
- device approval;
- forced password changes;
- CAPTCHA or bot protection;
- corporate SSO;
- geographic or IP restrictions;
- invitation-only onboarding.
Do not disable security globally. Create a bounded review path, such as a dedicated account exempted from a second factor, a stable review OTP documented in Notes, or a fully featured demo mode. The correct implementation depends on your threat model.
If you use Sign in with Apple or another identity provider, test the exact credentials and consent state. Apple’s platform version information reference says sign-in information for a demo account belongs in App Review Information and that the account must not expire. It also asks for working information when a single sign-on service is used.
Seed the state the feature requires
A login that opens an empty dashboard may technically work and still block review. Preload the smallest set of data needed to follow the submitted workflow.
For example:
| App type | Useful seeded state |
|---|---|
| Team SaaS | Workspace, second member, sample project |
| Marketplace | Buyer and seller accounts, test listing |
| Subscription app | Account with the intended entitlement state |
| Finance tool | Synthetic portfolio or sandbox connection |
| Social app | Safe sample posts plus moderation controls |
| Hardware companion | Paired demo mode or documented sample resource |
For workflows involving two roles, provide two accounts and label them. State which one performs each step. Avoid having both reviewers or automated checks mutate the same scarce record in a way that makes the next run fail.
Resettable data is useful. If the flow consumes a coupon, invitation, or one-time object, supply enough reusable state or a clear reset action.
Keep backend and feature flags aligned
The selected build must reach the environment where the demo account exists. Check API base URLs, remote configuration, feature flags, media hosts, email links, payment products, and region rules.
A common development assumption is that “production is live” because the home screen loads. Test every service called by the review path. A feature can fail only after login because its worker, storage bucket, or third-party integration is still pointed at staging.
Do not switch a critical flag off while review is underway. If a flag controls the submitted feature, record its owner and expected state in the release handoff.
Write access instructions as a test case
Put the primary username and password in the dedicated sign-in fields. Use Notes for role, setup, additional accounts, navigation, and expected results.
A compact structure is:
Account state: Workspace owner with sample project and active test entitlement.
Steps: Sign in, open Projects, select Review Sample, then choose Export.
Expected result: A PDF preview appears and the share sheet opens.
Additional resource: Usesample-review-qr.pdffor the Scan Code path.
The guide on writing App Review Notes explains how to turn this into exact, build-specific instructions.
Do not include sales copy, internal architecture history, or a broad compliance claim. The reviewer needs a reproducible route.
Run a clean-device access test
Test the account as if you do not work at the company:
- Install the distribution build on a clean device state.
- Use only the credentials and instructions stored in App Store Connect.
- Sign in from a different network if practical.
- Follow every step without developer tools or admin intervention.
- Test logout and a second login.
- Confirm seeded state remains available.
- Verify that support and account-deletion paths work for this account.
Have a teammate unfamiliar with the feature run the same script. Any information they need to ask for belongs in the setup or Notes.
If the test fails because of code or configuration bundled into the app, prepare a corrected build. If the account state alone is wrong, repair and retest it. Keep the decision tied to the actual cause.
Monitor without interfering
During review, monitor service health and authentication failures, but do not use reviewer activity to infer motives or identify an individual reviewer. Your goal is operational availability.
Avoid aggressive fraud rules that lock the demo account after a new device or repeated login. If automated protection triggers, design a narrow exception and document it internally. Do not wait for Apple to report the same block.
Keep the account active through any follow-up conversation and resubmission. Rotating credentials after the first message can make old instructions unusable.
FAQ about App Review demo accounts
Can the reviewer create their own account?
Do not rely on that when account-based features require access. Provide an active demo account or fully featured demo mode unless Apple has accepted another arrangement.
Can the demo account use two-factor authentication?
Only if the reviewer can complete it without your live intervention. Use a secure, bounded review path and explain it clearly.
Should I give the demo account an active subscription?
Give it the state needed to inspect the submitted flow. If Apple also needs to inspect purchase and restore, explain the starting state and route rather than hiding those screens behind a permanent entitlement.
How long should the account remain active?
Keep it active throughout review and any follow-up or resubmission. Apple’s field reference states that the demo account must not expire.
Can I use real customer data in the account?
No. Seed synthetic, non-sensitive data that demonstrates the workflow without exposing customers.
Conclusion
A reliable demo account is a controlled review environment. Stable credentials, representative state, reachable services, and precise instructions matter as much as the login itself.
Create the account now, then test it from a clean device using only what you plan to give Apple. Fix every moment that requires insider knowledge.