Google Play rejection
Google rejected the release because its reviewer could not get past your login screen. Nothing in the app is broken; the reviewer simply had no working way in. Add a reusable test account in Play Console under Sign-in details (the section older guides call App access), make sure it skips one-time codes and email links, and resubmit.
From $109 one-time per platform, or let our team do it all from $698.
Google's reviewers have to see everything your app does. If any part of it is restricted by a login, a membership, a location or another form of authentication, you must hand over whatever they need to get in: test credentials, a demo account, or instructions for codes and other special cases. You enter this in Play Console under Policy and programs → App content → Sign-in details. Older guides, forum posts and some notices still call the section App access; it is the same thing. You can store up to five sets of instructions, each with the login details and an Any other instructions field for everything unusual about your login.
Google's requirements for sign-in details are short and strict. The credentials must be available at all times, reusable, valid from any country, kept working, and in English (or come with an English version). If your login normally needs a one-time password or a second factor, you must provide credentials that bypass that step. A login by QR code needs a static URL instead, and content behind a paywall needs instructions that let the reviewer use the paid part freely. A password that expires during review can get the app rejected.
The Policy status entry is usually titled along the lines of Need login credentials for app review. It explains that the reviewer could not access all or part of the app and asks for an active demo account plus any other resources needed for the review, such as codes. The attached screenshot is typically your login screen, an email confirmation page or a "check your inbox" message.
The same root cause also hides behind other rejections. A reviewer stuck at the login can file the app under minimum functionality, because a sign-in form is all they saw (the minimum functionality guide covers the rest of that rejection). A declaration for background location, account deletion or another feature can be refused because the reviewer could not verify the feature behind the login. Before you rewrite anything else, check whether the reviewer actually got in.
AI builders generate modern, passwordless auth by default. It is great for users and a dead end for a reviewer on a fresh test device.
Passwordless email links are a common default in Supabase-based apps and many auth kits. The reviewer has no access to the inbox of your test account, and on a phone the link opens in the browser or mail app instead of your WebView anyway, as the magic links guide explains.
A six-digit code sent by email or SMS to an address only you control stops the review cold. Google asks for reusable credentials that skip the code step.
Inside a WebView, Google refuses its own sign-in page unless the WebViewGold login helper is configured (GOOGLE_LOGIN_HELPER_TRIGGERS, see the disallowed_useragent fix). Even when it works, a reviewer will not use a personal Google account. Offer email and password too.
Waitlists, invite codes and "an admin will approve your account" flows mean a new sign-up never reaches the product. Pre-approve the review account.
Country blocks, strict firewall rules, aggressive bot challenges or rate limits on the login route can stop a reviewer's device. Google expects credentials that work regardless of location.
Trial expiry, cleanup jobs for inactive users, and your own account deletion flow (which a reviewer may test) can remove the account between two reviews.
My iOS WebView is finally approved. Thanks!!
About thirty minutes once; it then works for every update.
Use an address like [email protected] that exists only for store reviews. Never hand over your own login or a real customer's: Google asks for credentials made for testing. Mark the email as confirmed in your auth provider's dashboard so no confirmation mail is needed.
If your app signs in by magic link or one-time code only, add an ordinary email-and-password option that any user can choose, for example a "Use a password instead" link under the email field (the prompt below does this for you). Phone login can often use a fixed test number: Firebase Authentication, for example, lets you register test phone numbers with a fixed verification code. Write the exact steps into the instructions.
Add realistic sample content so every screen shows its purpose, and grant the paid entitlement on your server so premium screens are reviewable without a purchase. If your app has roles (customer and provider, member and admin), create one account per role and use one instruction set for each.
Exclude the account from cleanup scripts and trial expiry. After each review, log in once to check that it still exists; a reviewer testing your account deletion flow may have used it. A small script that recreates the account with its sample data saves you a rejection.
Allow the login route from all countries and make sure bot protection does not challenge a fresh Android device on its first launch. If your service only operates in one country, keep at least the review account working worldwide and say so in the instructions.
Open Policy and programs → App content → Sign-in details, choose Start or Manage, then Add new instructions. Paste the credentials exactly as they are typed on the login screen and use Any other instructions for everything unusual: which button to tap, how the code step is skipped, which role the account has and where the main features are.
Uninstall the app, install the build from the internal testing track and log in by pasting the credentials from Play Console. If CLEAR_CACHE_ON_STARTUP is true in Config.java, the app clears cookies on every start, so the reviewer logs in again after each launch; mention it. If the app lock (enableBioMetricAuth) is on, mention that too and try a device without enrolled fingerprints so you know what the reviewer will see. Both options are described in the Android Config.java reference.
If only the sign-in details changed, save them and send the update for review; Play Console lists pending changes in the Publishing overview. If you changed the app, for example to add the password option, upload a new release with a higher version code. A one-line reply in Policy status pointing to the new instructions helps.
Plain English, numbered steps, no marketing. The reviewer reads this while the app is open on a test device.
Login method: email and password. On the start screen tap [Log in], then [Use a password instead] below the email field. This account is pre-confirmed and needs no one-time code or email link. It works from any country. Role: [customer]. A second instruction set contains the [provider / admin] account. The account has the [Pro] plan unlocked on our server, so all paid features are visible without a purchase. Where to find the main features: 1. [Bookings tab]: create and cancel a booking. 2. [Profile > Notifications]: turn on reminders; a test notification arrives within [2] minutes. 3. [Profile > Settings > Delete account]: account deletion. Please use the second test account for this, so the main account stays available for future reviews. The app asks for [location] only on the [Store finder] screen, after an in-app explanation. [Only if enabled:] The app is protected by an app lock on launch; [describe what appears on a device without fingerprint or face unlock]. Contact during review: [email address].
Keeps your magic-link or code flow and adds an ordinary password login that any user can use. That is what the reviewer needs, and it is not a hidden backdoor.
My app currently signs users in with [magic links / email one-time codes] via [Supabase Auth / Firebase Auth / Clerk]. Add a standard email-and-password sign-in next to the existing method, without removing it: - On the login screen, add a clearly visible link 'Use a password instead' that switches the form to email + password. - Add 'Set a password' to the account settings, so existing users can create one. - Use the auth provider's built-in password sign-in. Do not build a custom, secret or hidden bypass. - Show a clear error for wrong passwords and include a 'Forgot password' flow. - Keep the session persistent across app restarts; the app runs inside an Android WebView. - Change nothing else. At the end, list the files you changed and explain how I create a pre-confirmed test user with a password in the [provider] dashboard.
Only if sign-up works instantly, without email confirmation, codes or approval, and even then Google expects credentials when a login is required. Providing a ready account is faster and avoids a second rejection.
Not if it is a normal, visible option that every user can use. What you must avoid is a secret code or route that unlocks different behavior for reviewers; that falls under the deceptive behavior rules.
The robust fix is to add email and password. A dedicated Google account for review often runs into extra verification steps when it signs in on a new device, and Google sign-in in a WebView needs the WebViewGold login helper to work at all.
Only when something changes, but every update is reviewed with the details on file. Keep the account valid permanently and update the instructions whenever you add a role, a paywall or a new main feature.
Only if you give them a real account, which you should not do. Google asks for credentials created for testing. Use sample data that shows what each screen is for.
Same result, different amount of work on your side. All three come with the approval guarantee and 24/7 human support.
$109 per platform, one-time
The WebViewGold license: a finished Xcode or Android Studio project. Paste your URL, set name and icon, switch on features, build and submit. Free updates forever.
See plans on the main page$349 per license, one-time add-on
No Mac, no Xcode, no Android Studio: configure in the browser, we build both apps in the cloud and hand them to App Store Connect and the Play Console.
How the Cloud Builder works Try the free demo$698 per platform $798
Send us your URL and icon. Our team configures, builds and delivers your app within 72 hours, white-label, with source projects. Both platforms for $1,158.
Full Service details Powered by
Winter Sale prices valid until December 31, 2026.
App Store & Google Play approval guarantee – or your money back within 14 days
Rather hand it over? Full Service: we configure, build and deliver within 72 hours, from $698 per platform. Questions? Chat with us 24/7.
Refunds are granted under the conditions listed in our FAQ: a non-content rejection by Apple and/or Google, claimed within 14 days after purchase.
