skip to content

Why might App Store or Google Play review reject a Flutter app that requires a login, and what do you give the reviewers?

level: juniorimportance: should knowfreq 38%

answer

  1. reviewer stuck at the sign-in screen
  2. App Review Information sign-in fields
  3. Play Console App access declaration
  4. valid on the release build's backend
  5. no second factor sent to you

basics

~20 s

Reviewers must reach every feature, so a login wall without working credentials gets the app rejected. Give a demo account in App Store Connect's App Review Information and Play Console's App access, valid on the release build's backend.

solid answer

~40 s

Review can only approve what it can see. If a Flutter app opens on a sign-in screen and the reviewer has no account, the store rejects it as incomplete or inaccessible. In App Store Connect you mark sign-in as required under **App Review Information** and enter a username, password and notes; in Play Console you fill the **App access** declaration the same way. The account must work against the backend the release build actually calls, not a staging server selected by a `--dart-define`, must not need an SMS or email code only you receive, and should hold seeded data so every screen has something to show. If the app lets people create accounts, both stores also expect a way to delete one.

go deeper

for a junior

Recall that review needs a working login and where it goes: App Review Information in App Store Connect and App access in Play Console.

for a middle

Explain what breaks a demo account in practice: wrong environment compiled in, a second factor, empty data, region blocks or a biometric gate.

for a senior

Show that you make the review account part of the release checklist and verify it on the exact binary, including the account-deletion path.

for a principal

Frame review access as an operational contract: who owns the review account, how it survives data resets and how every release proves it still works.

## Why a login wall gets rejected Store review is a person (helped by automated checks) running the **release binary** you uploaded. They cannot approve features they cannot open. When a Flutter app launches straight into a sign-in screen and nothing tells the reviewer how to get past it, the outcome is predictable: the submission comes back asking for credentials or rejected as incomplete. Nothing about Flutter changes this. The reviewer sees an ordinary app; the widget tree underneath is irrelevant to them. The fix is administrative, not technical: give review a **demo account** and instructions. The work lies in making sure that account really works on the build you submitted. ## Where the credentials go | Store | Where | What you enter | |---|---|---| | App Store | App Store Connect, the version's **App Review Information** | a sign-in-required switch, username, password, free-text notes | | Google Play | Play Console, **App content → App access** | whether parts of the app are restricted, plus credentials and instructions | Never put the credentials in the public description, a screenshot or an in-app hint. Review reads the dedicated fields; the public listing is for users. ## What makes a demo account actually work - **It exists on the backend the release build calls.** The build you upload is a release build; if production is selected by a flavor or a `--dart-define`, the reviewer's account must live in production. - **No second factor you control.** A one-time code texted to your phone or mailed to your inbox stops the reviewer cold. Disable the second factor on the review account or explain a code that always works for it. - **Seeded data.** An empty account shows empty lists. Give it orders, messages or whatever the app's main screens display, so review sees the product rather than empty states. - **No expiry and no lockout.** Review may happen days after submission and may be repeated for later versions. - **No region wall.** If your backend blocks traffic by country, the reviewer may be elsewhere. - **Notes for anything non-obvious**, such as hardware the app pairs with or a feature switched on only for some accounts. ## Flutter-specific traps 1. **The wrong environment compiled in.** A CI job that builds the store binary with the staging `--dart-define-from-file` sends the reviewer to staging while the account lives in production, or the reverse. 2. **Identity-provider-only sign-in.** If the app offers only Google or Apple sign-in through a plugin, prepare a real account on that provider that the reviewer can finish without your phone. 3. **Biometric gate on first launch.** A `local_auth` prompt with no fallback leaves a reviewer without enrolled biometrics stuck. 4. **Feature flags defaulting off.** A screen hidden behind a remote flag the review account never receives looks like missing functionality. ## A pre-submission check for the review account Run this on the exact archive or bundle you are about to upload, not on a debug build from your IDE: 1. Install the release build on a clean device or simulator with no cached session. 2. Sign in with the review credentials exactly as written in the store fields. 3. Walk every main screen and confirm each shows real content. 4. Trigger any flow the notes mention, such as a purchase in a sandbox or a pairing step. 5. Sign out and back in, so a token that only works once is caught before review finds it. If the account is shared across releases, record who owns it and make sure scheduled data clean-ups on the backend never delete it. A review that fails because the demo account was wiped overnight costs the same days as a real defect. ## Rules that ride along with accounts - If the app supports **account creation**, Apple expects the user to be able to start **account deletion from inside the app**, and Google Play also asks for a deletion path, including a web link. - The review account is how the reviewer finds that deletion action, so keep it reachable in settings. Treat the demo account as part of the release checklist, alongside signing and version numbers: check it on the exact build you are about to submit, every time.

  • Your Flutter app offers only Google and Apple sign-in. How does a reviewer get in?
    Create a dedicated account on that provider for review, without two-step verification tied to your own phone, and enter its credentials plus a short walkthrough in App Review Information and Play's App access. The reviewer must be able to finish the provider's sign-in sheet unaided on the release build.
  • The Flutter app lets users sign up. What account rule does review check besides the demo login?
    Apple expects an app that supports account creation to let users start deleting their account from inside the app, not only by emailing support; Google Play also asks for a deletion path, including a web link. In Flutter that is a reachable settings action calling the backend's deletion endpoint, which the demo account should let review find.

saying these in an interview costs you the question

  • Reviewers register their own account, so credentials are optional.
  • A staging demo account is fine even though the release build calls production.
  • Put the demo login in the store description so reviewers can find it.
  • A one-time code sent to my phone is fine; the reviewer can ask me for it.
  • Flutter apps are reviewed under different rules from native apps.