In this article

Before submitting an account-based app, verify that a reviewer can reach its important features using the access information you provide. A working login on your own already-authenticated device does not prove the submitted reviewer path works from a fresh installation.

Apple's complete-review guidance, checked October 8, 2026, asks for the information and access needed to evaluate the app. This is a review-readiness checklist, not a promise of approval or legal advice about regulated products.

Walk the route from a fresh state#

Use an authorized test device and synthetic account data. Install the intended build, sign in through the exact route described to the reviewer and reach each important feature. Record the first point requiring information not present in the submission notes.

Check account activation, onboarding, region restrictions, backend availability and any role needed for the feature. A demo account that logs in but has no usable sample data may still prevent evaluation.

Do not bypass security globally to make the demonstration easy. Create a supported, appropriately scoped demonstration path that reflects the features being reviewed.

Make the notes reproducible#

Describe where significant features and changes can be found. Use short steps with expected results. For a hypothetical document app:

text
1. Sign in with the supplied review account.
2. Open the sample workspace.
3. Select the demonstration document.
4. Edit its title and save.
Expected: the new title appears in the workspace list.

This example contains no real credentials. Supply the actual necessary review access only in Apple's designated private submission fields, never in a public blog or support ticket.

Account for special access requirements#

Apple's guidance discusses different account types, authentication codes, subscription-review access and hardware-dependent demonstrations. Confirm which apply to your app instead of assuming a username and password cover every feature.

If the route depends on a one-time code, an expiring account or a service restricted to office-network addresses, identify a supported way for App Review to evaluate it. Do not rely on someone being awake to answer an unexpected login request.

For hardware-dependent functionality, read Apple's actual demonstration requirements. A screenshot of a device selector does not establish that the physical workflow is usable.

Use demonstration data appropriately#

Apple describes a demonstration mode as an option in appropriate sensitive or regulated contexts, with full features represented using demonstration data. It does not make that mode a universal substitute for every app's review obligations.

Keep synthetic records clearly distinct from real customer accounts. Verify that actions in the demonstration cannot accidentally contact customers, charge a payment method or alter operational data.

If documentation is required for the app's field or content, resolve that separately. A usable demo cannot substitute for required permission or qualification documents.

Recheck just before submission#

Confirm that the provided access remains valid, the backend is available and the notes match the uploaded build. Record the verification time and responsible operator. Avoid changing the password, account state or demonstration content during review without updating the authorized review information through the supported process.

If an access-related rejection arrives, reproduce the stated path and correct the observed blocker. Do not write a generic appeal asserting that the app works without testing the reviewer's route.

Our AI answer verification guide is useful when a tool drafts review notes: check every claimed feature, step and test against the actual build. Clear notes should describe verified access, not imagined behavior.