Demo Account or Demo Mode: What to Prepare Before Review

Most business apps should prepare a durable demo account—with a live backend and clear review notes—before App Store or Google Play submission. A built-in demo mode is typically the right alternative when legal or security obligations prevent sharing credentials, and Apple expects prior approval for that path. This article gives you a Review Access Ladder, a Review Access Fit Scorecard, and a worked example so you can choose the path before you burn a review cycle.

Key takeaways

• Apple’s App Review Guidelines require full access for account-based features: an active demo account or a fully featured demo mode, plus live backend services during review.

• Google Play requires reusable, always-valid, English sign-in details that work regardless of reviewer location, including a path that bypasses one-time passwords and 2-step verification when those gates exist.

• Default to a durable demo account. Treat built-in demo mode as the exception for sensitive or regulated products—not as a shortcut that avoids seeding realistic review data.

• Use the Review Access Fit Scorecard below. A weak score usually means fix access before paying for another store review—not rewrite the marketing screenshots.

Why reviewer access is a product decision

If login walls off the core job, reviewers cannot evaluate the product they cannot reach. Apple’s Guideline 2.1 (App Completeness) is explicit: submissions should be final and functional, demo account info should be included when the app includes a login, and backend services must stay on. Incomplete bundles, crashing binaries, placeholder content, and broken demo logins are rejection material.

Google Play’s App content guidance is equally practical. When parts of the app are restricted by login, membership, location, or other authentication, you must provide the details reviewers need on the Sign-in details declaration. Play’s requirements page adds hard constraints: credentials must stay accessible, reusable, and valid regardless of location; expiring passwords and OTP-only flows without a bypass can stop review.

This is different from the earlier product question of whether customers should create accounts on day one. That decision shapes onboarding. Reviewer access shapes whether App Review and Play can finish a fair test of whatever onboarding you chose. If you still need a broader pre-submit checklist, pair this article with what to check before submitting your first business app.

The Review Access Ladder

Climb one level at a time. Do not invent a custom “reviewer only” path after the binary is already in review.

Interpretation rule of thumb: if L0–L3 can be completed without creating a legal or security conflict, stay on a durable demo account. Jumping to L4 because “demo mode sounds easier” usually creates a second product to maintain and still fails if the mode hides unfinished features.

The Review Access Fit Scorecard

Score each factor from 0 (weak) to 2 (strong). Maximum total: 12. Write the evidence next to the score so the decision is auditable later.

Interpretation:

• 0–5: Do not submit. Fix durability, OTP bypass, or backend continuity first.

• 6–8: Draft dual-store instructions only after naming owners for each weak factor. Typical gaps: expired trials, SMS login, and empty seeded data.

• 9–12: A durable demo-account path is usually justified. Move to L4 demo mode only when factor 6 shows a real legal or security constraint and the mode shows the full product.

When demo mode is the better primary path

Choose built-in demo mode as the primary reviewer path when sharing an account would expose protected data, violate a regulated workflow, or create an unacceptable security obligation—and when you can still show the full feature set with demonstration data. Apple’s Guideline 2.1 ties that alternative to prior approval. Apple’s complete-review help also notes demonstration mode for sensitive information or highly regulated industries.

Do not treat “we have not created a review user yet” as a legal obligation. That is unfinished release engineering. Demo mode still needs design, seeded stories, and maintenance across releases. For many SMEs, a locked-down review tenant with fake customers and scrubbed fields is faster and clearer than building a second product surface.

Worked example: membership booking app

Consider a hypothetical wellness studio shipping iOS and Android apps for class booking and a paid membership that unlocks priority slots. Login is required after browsing the schedule. Engineering used SMS one-time codes for every sign-in. Staging sleeps overnight. Leadership wants to submit Friday because screenshots are ready.

A realistic Review Access Fit Scorecard before access work:

• Credential durability: 1 — a shared staging user exists, but nightly resets wipe bookings

• OTP and MFA bypass quality: 0 — SMS is mandatory; reviewers cannot receive the studio’s phone

• Role and state coverage: 1 — only a free member exists; expired-subscription purchase flow is untested

• Backend continuity: 0 — staging auto-sleeps after idle hours

• Dual-store instruction quality: 1 — Apple notes drafted; Play Sign-in details never started

• Legal/security necessity for demo mode: 0 — no regulated-data constraint; the blocker is process debt

Total: 3 / 12. Under the scorecard bands, the team should not submit. The higher-leverage path is L1–L3: a production review tenant, password login without SMS, free and expired-membership accounts, always-on APIs, and matching English instructions in both consoles. Building a polished demo mode here would mostly hide the same unfinished access work behind a different door.

After a focused access pass, a stronger score might reach 10 / 12: durable credentials, OTP bypass, both membership states seeded, backends awake, and dual-store notes verified on a cold install. That is when submission becomes an execution task instead of a guess. If payment architecture is still unsettled, resolve in-app purchase versus website checkout before reviewers are asked to exercise a half-finished paywall.

Mistakes, limitations, and exceptions

• Credentials that work only on submission day. Apple notes that credentials which expire or change before review starts may result in rejection. Protect the review account from cleanup automation.

• OTP theater. If the only login path needs a code the reviewer cannot receive, the product is effectively incomplete for review—even when customers love the security model.

• Empty seeded accounts. A login that opens blank screens does not prove the core job. Seed appointments, messages, invoices, or whatever the product claims to manage.

• Demo mode that hides unfinished features. Apple requires the mode to exhibit full features and functionality. A tour that skips admin tools, refunds, or membership changes fails the same completeness test.

• Play instructions that never leave draft. Updating Sign-in details is not enough if the change is never sent for review from Publishing overview when that step applies.

• Assuming this guarantees approval. Working reviewer access removes a common blocker. Reviewers still evaluate utility, privacy accuracy, payments, and policy fit.

This framework helps you sequence access work. It does not replace counsel for regulated industries, and it does not replace a soft-launch plan when the core job is still unstable for real devices.

Recommended next steps

1. Complete the L0 gate map: every login, invite, QR, geo, membership, and paywall barrier between install and the core job.

2. Score the Review Access Fit Scorecard with one product owner and one engineer on a fresh device. Sign in using only the draft review notes.

3. If the total is under 9 and no legal constraint blocks shared credentials, build L1–L3: durable demo accounts, OTP bypass, role coverage, and always-on backends.

4. If legal or security obligations truly prevent a demo account, design an L4 demo mode with full-feature demonstration data and document the approval path in your review notes before submission.

5. Copy the same access package into App Store Connect and Play Sign-in details, then re-test the exact binary you intend to submit.

If your team needs help turning a login-gated business product into a store-ready iOS and Android release—with durable review access treated as part of the build, not a Friday scramble—Oasbit’s mobile app development services cover native and cross-platform delivery with submission readiness built into the release plan.

When your scorecard still fails on OTP walls, empty seeded data, or a regulated workflow that may need demo mode, book a growth strategy session and bring the gate map, current review notes, and a screen recording of a cold-install sign-in attempt. We will help you decide whether a durable demo account or a built-in demo mode should ship first.

Sources

• App Review Guidelines — Apple Developer (Before You Submit; 2.1 App Completeness)

• Provide information for a complete review — Apple Developer Help

• Prepare your app for review — Play Console Help (Sign-in details)

• Requirements for providing sign in details for review — Play Console Help