What Google Play reviewers need for sign-in gated apps

What do I need to give Google Play reviewers if my app has sign-in or gated features

Give Google Play reviewers everything they need to reach the full app, not just the public shell. That usually means a working test account, clear sign-in steps, any secondary access codes or QR links, and instructions for reaching features behind a login, paywall, subscription, location gate, or other restriction. Google says the access details must be complete, reusable, always available, and valid regardless of where the reviewer is located.

The fastest way to get rejected is to assume the reviewer can figure it out. They will not create an account, wait for a one time password that expires, or guess which screen opens the gated area. If your app needs a password, PIN, social login, master code, static URL, or a preconfigured demo account, put those steps in Play Console and make them simple enough that a reviewer can follow them on the first pass.

If sign-in is required, provide the exact credentials or a demo account that already works. Google says the credentials should be accessible at all times, reusable, and maintained without errors. If you use Google sign-in, Facebook sign-in, or another third party login, include the full account information and the exact sequence the reviewer should follow. If your app uses two step verification or one time passwords, provide a reusable path that bypasses the expiring code flow.

If access is hidden behind a paywall or subscription, give reviewers a way to enter that area for free during review. Google’s help page explicitly says that when content is behind a subscription paywall, you should provide additional instructions or access details that let the reviewer fully and freely access and review the app behind the paywall. Do not ask the reviewer to buy access just to complete the review.

If your app uses location dependent access, such as a geo gate, provide a login or code that works everywhere. Google calls out that location dependent passwords should be replaced with sign-in details that are valid regardless of user location, for example a master login. A reviewer in a different country should be able to follow the same instructions and reach the same screens.

If your gated area depends on a PIN, QR code, barcode, or custom unlock flow, convert it into something reviewable. Google says non alphanumeric sign-in details should be turned into a static URL and uploaded to Play Console. If the user normally sets up their own PIN, write out the exact setup and entry steps. The goal is not to change the product, it is to make the review path deterministic.

Put the access details in the App content area of Play Console, where Google says you can provide and manage special access instructions for reviewers. That same place is where you should keep the instructions current. If credentials change, expire, or get rotated, update them before the next review. A stale demo account is the same as no access at all.

A practical reviewer packet has four parts. First, the account name and password or the exact sign-in method. Second, any backup factor, recovery code, or bypass for one time verification. Third, the path from login to the restricted feature. Fourth, a short note that explains what should be visible once the reviewer gets there. That makes the review faster and removes guesswork.

A concrete example helps. If your app is a fitness app with premium plans, give a demo account that lands on the premium dashboard, explain that the reviewer should tap Profile, then Restore Access, then use the demo password, and note that premium workouts are available without payment during review. If the app locks content after signup, include credentials that already point to an active account so the reviewer does not wait for email confirmation.

What people get wrong is leaving the instructions in a private note, in an email thread, or in their own head. Play reviewers only see what you submit in Play Console and what the app exposes at runtime. If the reviewer cannot get past the gate in a few minutes, the app can be rejected for not providing enough access to review.

What people also miss is that the access path must stay working during the whole review window. A password that expires, a login that only works on your office Wi-Fi, or a code that changes daily breaks review. Google’s wording is direct here: the credentials must be accessible at all times and valid regardless of location, so the review setup has to be stable, not a one day workaround.

If your app is not fully gated, still describe the parts that are. Google says the App content page is where you can provide instructions for restricted parts of the app, not just the whole app. That matters when the home screen is public but a report page, creator tool, paid feature, or admin section needs extra access. Reviewers need the shortest path from install to the restricted screen.

For teams that want a clean workflow, DevConnect can help with tester exchange and closed test tracking, but it does not replace the reviewer instructions you must give Google Play. The reviewer packet still belongs in Play Console, and it still needs to open the locked parts of your app without friction. You can keep the testing process on your side simple and the review access explicit.

Before you submit, check three things. The reviewer can log in without waiting for a code that expires. The reviewer can reach every restricted feature you want approved. The instructions are written in English, clear, and current. If any of those fail, fix the access path first and submit after the app is actually reviewable.