EntryIdP

Appearance

Submitting to the App Store / Google Play ​

If your app signs in with EntryIdP, app-store review needs a moment's planning. EntryIdP is passwordless by design — face liveness is the only way in — so there is no username/password "demo account" to type into Apple's or Google's reviewer fields. This page gives you a copy-paste-ready way to clear review anyway.

Why there's no demo account ​

Apple's Guideline 2.1 (App Completeness) and Google Play's "App access" declaration both expect you to get a reviewer past your login — normally by handing over a test username and password. EntryIdP has neither: identity is proven by a real face-liveness check on the user's own device, not by a shared secret. This is the generic login-gated-app review problem, and you have two clean ways to solve it.

The one question that decides your approach ​

Can a reviewer complete EntryIdP enrolment end-to-end on their own device, with nothing provided by you — no allowlist, no approval, no code sent to your inbox?

  • Yes → the reviewer-notes approach below is legitimate and commonly accepted. Strengthen it with a screen recording.
  • No (for example, once you require real, bureau-backed identity verification a reviewer can't pass with a throwaway identity) → ship a demo / preview mode in your app. This is the durable answer and the one we recommend building once.

Most teams end up shipping demo mode regardless, because it removes the reviewer from your real identity flow entirely and never breaks.

Add a reviewer-only build flag that renders your signed-in screen with static sample data and makes no real auth call to EntryIdP. The reviewer always reaches your core functionality; your real biometric flow is never exercised by an automated reviewer on an emulator (where liveness is unreliable anyway).

Keep it honest and unmistakable:

  • Label it clearly on-screen — a persistent "PREVIEW MODE — sample data, not a real account" banner, and an "Exit preview" control.
  • Gate it behind a build flag / environment variable so it can never be reached in a production build.
  • Use obviously fake claims (sub: preview-…-account, a sample display name).
tsx
// preview-mode.ts — reviewer-only, compiled out of production builds.
export const PREVIEW_MODE = process.env.EXPO_PUBLIC_PREVIEW_MODE === 'true';

// Static sample identity — never a real token, never a real /userinfo call.
export const previewIdentity = {
  sub: 'preview-0000-account',
  name: 'Alex Preview',
  face_liveness_verified: true,
  acr: 'urn:entryidp:biometric:liveness',
  tenant_id: 'preview-tenant',
};

// In your auth provider: when PREVIEW_MODE is on, resolve the signed-in
// state from previewIdentity instead of starting the real OIDC + liveness flow.

Because demo mode lives entirely in your app, it is invisible to EntryIdP — there is no server-side change and no new sign-in path. It does not weaken the biometric-only guarantee for real users.

Alternative: reviewer notes + screen recording ​

If a reviewer genuinely can self-enrol on a stock device (typically pre-launch, before you enforce real identity verification), you can submit without demo mode:

  1. Declare no demo account required (Apple: demoAccountRequired = false; Play: describe self-enrolment in the App access form).
  2. Paste review notes explaining how to self-enrol (template below).
  3. Attach a short screen recording of the full enrol → sign-in flow. Apple explicitly accepts video when a login can't be demoed conventionally.

App Review notes template (Apple) ​

Show the template — fill in the bracketed fields before submitting

[App name] signs in with EntryIdP, a purposefully passwordless, biometric-only identity provider — there are no username/password credentials to share, so no demo account is provided. To test sign-in, create a profile directly from the app: tap "Create account" (or "Sign in") and complete the EntryIdP registration / face-liveness enrolment in the redirected flow. After review, the test profile can be permanently removed from the in-app account screen (total account deletion). Questions: [your name], [your email], [your phone].

Google Play "App access" declaration ​

What to write in the Play Console

In the Play Console App access section, choose "All or some functionality is restricted" and add an instruction along the same lines: sign-in is by biometric self-enrolment, no credentials are issued, and the reviewer should create a profile in-app to reach the signed-in experience. Attach the same screen recording.

Android without store review ​

Three routes that skip functional review of your login

If you don't need a public Play listing, you can skip functional review of your login altogether:

  • A signed APK distributed directly (sideload), or
  • An internal / closed testing track in the Play Console, or
  • MDM / enterprise distribution.

None of these put your sign-in flow through Google's functional review, so the demo-account question doesn't arise.

Checklist ​

  • [ ] Decide: can a reviewer self-enrol unaided? If not, ship demo / preview mode.
  • [ ] Demo mode is clearly labelled, uses sample data, and is compiled out of production.
  • [ ] Review notes filled in with your own contact details.
  • [ ] Screen recording of enrol → sign-in attached.
  • [ ] (Android) Chosen a distribution track that matches whether you need functional review.

EntryIdP — Synapser