How to QA In-App Review and Rating Prompts Without Fake Reviews

People land on a page about in-app review prompt testing for one of two reasons.

The first is a QA lead with a ticket that says "verify the rate-us prompt" and no idea how you're supposed to test a dialog the operating system controls. The second is someone who wants a handful of accounts to leave reviews on an app. The first is a real engineering problem with good answers. The second is rating manipulation, and no amount of browser configuration turns it into QA.

This post is for the first reader. And because the two get muddled constantly, there's a section near the end on how review fraud gets caught and why it isn't worth the risk.

Why your team's test reviews keep disappearing

A common one: a team ships a new review prompt, a few QA people install the production build, tap five stars, write something friendly, and then... nothing appears on the listing. Somebody files a bug.

It isn't a bug.

Stores don't publish their signals, but developer-linked accounts, clusters of similar accounts, bursts of reviews landing together and near-identical wording are the kind of thing moderation looks for. Google's comment-posting policy says it outright: don't review an app if you own or work for the business that made it, and don't review the same app from several accounts. A review of your app written by people who work on your app is precisely what that policy exists to remove.

What grates is the silence. You generally won't get a notice that a review was removed, or why. It just isn't there — which is exactly why this lands in a bug tracker every single time instead of a wiki page where it belongs.

So the lesson isn't "make the test accounts look more independent." It's that production reviews aren't a test surface at all. Your QA plan should never end with a public review on your own listing. Everything you actually need to verify (does the prompt fire at the right moment, does the UI render, does your app behave afterwards) can be tested without one.

What the stores give you for in-app review prompt testing

Both platforms anticipated this. Most teams just don't read the docs first.

Google Play: the In-App Review API

On Android, the rate-us dialog comes from the Play In-App Review API. A few things matter for QA:

FakeReviewManager. The Play Core review library ships a testing class, FakeReviewManager, for unit and instrumented tests. It won't draw the real dialog, but it lets you assert your code launches the flow when it should.
Internal app sharing and internal test tracks. These show the real dialog on a device. Google's testing page for in-app reviews spells out what each option shows and whether a review can be submitted from it. Read it first.
The quota. Google limits how often the dialog can appear for a user, so calling the API doesn't guarantee anything shows. Your app has to work the same either way.
The design guidelines. Google's guidance says not to ask the user questions before or while showing the rating card (no "Do you love our app?" gate), and not to incentivize ratings. That's a QA check worth adding.

Apple: SKStoreReviewController and requestReview

On iOS you request a review through the system API (SKStoreReviewController, or the newer requestReview action in SwiftUI and StoreKit). Apple's documentation is unusually clear about testing:

In a development build, the prompt always appears, so you can check layout and flow. Apple describes this as a way to test the user interface and experience, not a route to a review on your listing.
In a TestFlight build, the request has no effect and the prompt won't appear. Apple's documentation says so directly, and it's the first thing to check before you debug your trigger code.
In production, the system decides whether to show the prompt and shows it to any one user at most three times in a 365-day period. Users can also turn these requests off in Settings.

Apple's App Review Guidelines also push you toward the system prompt rather than a custom review dialog. If your design team mocked up a custom one, flag it early. You'd be rebuilding something the OS already draws, and taking on the UI, the throttling and the review-guideline risk to do it.

One detail both APIs share: neither tells your app whether the user actually left a rating, or even whether the dialog appeared. So never build follow-up logic ("thanks for your review!") on the assumption that it did.

A QA plan that never touches your public listing

Map what you're testing to where it can be tested. The table below looks like something to skim past, but it's what keeps a team from "testing" in production.

What you're verifying	Where to test it
Trigger conditions (sessions, milestones, a prior dismissal)	Unit tests with `FakeReviewManager` on Android; plain unit tests around your own iOS trigger logic
The real dialog's appearance and flow	Android via internal app sharing or an internal test track; iOS via a development build on a device
What the app does after the request returns	Device tests that cover both "shown" and "not shown", since you can't tell which
Localized copy around the prompt	Devices or simulators set to each locale
Your store listing in other languages and regions	The public listing pages, viewed per locale (more on this below)

A couple of opinions, for what they're worth.

Test the trigger logic far harder than the dialog itself. You don't own the dialog. Apple and Google own it, and they'll change it whenever they like. What you own is when you ask, and that's where the bugs live: the prompt firing on a crash-recovery screen, or right after a failed payment, or twice in one session because two features each thought they owned it.

And if the last step in your QA plan is a live review on your own listing, the plan is the bug. Not the filtering.

Where a browser fits (and where it doesn't)

Limits first. JustBrowser is a desktop app for Windows x64 and Apple Silicon Macs, and it generates desktop identities only: no Android or iOS identities, no mobile app. In-app review prompts are a device problem, so test them on devices and emulators.

The browser side of app-store work is still real, though, and that's where separate profiles earn their keep.

Console access for each person. Google Play Console and App Store Connect both let you invite teammates with their own accounts and scoped permissions. App Store Connect has roles such as Customer Support for people who answer reviews, and Play Console lets you grant permissions down to things like replying to reviews (check each console's current permission list, since both change).

So: every person gets their own invited login, and their own browser profile. Don't pass one admin password around the team.

That isn't just tidier. A shared login is the pattern that sets off sign-in security checks, and it leaves you with no record of who changed the pricing, who edited the listing copy, or who replied to that reviewer at 1am.

Agencies working in client consoles. If you manage store listings or review replies for clients, each client grants your staff access through their own console, and each client gets its own profile. Cookies, sessions and saved logins stay apart, so a teammate can't reply to Client A's reviews from Client B's session by accident. JustBrowser's team seats are free, and a seat can run the profiles shared with it, which suits the "junior replies to reviews in the client's console" setup well. (A seat can't create its own profiles or use the API; anyone who needs that subscribes.)

Localization checks on public pages. How does your Play Store web listing read in Japanese? Does the App Store web preview show the right screenshots in Germany? A profile with its language and timezone set to the target locale shows you what a visitor there sees. If you need the page as served from that country, add a proxy in that region. JustBrowser doesn't include proxies, so you bring your own. This is the same idea as ad verification across geos: you're checking what real visitors are shown, not pretending to be anyone.

Web feedback flows you own. A post-purchase survey link, an NPS widget on your web app, a "report a problem" form: those are yours to test end to end, and a fresh profile shows exactly what a first-time visitor gets.

For screenshot comparisons, use a profile whose operating system matches the one you're checking, so fonts and layout render the way that visitor sees them.

Automating the browser side

Once the manual checks settle, script them. JustBrowser exposes a local REST API (bound to 127.0.0.1 on the machine running the app) plus CDP, so Playwright, Puppeteer or Selenium can open a profile and capture each localized listing page. Two things trip people up: POST /profiles/{id}/start starts headless unless you send {"headless": false} (a common cause of blank screenshots), and closing the browser from your script only disconnects, so stop the profile through the API. The Playwright and Puppeteer guide walks through the setup, and the full endpoint reference lives at justbrowser.app/docs.

For review monitoring itself, skip the browser where you can. Google's Play Developer API has endpoints to list reviews and post replies, and App Store Connect offers API access to customer reviews and responses too. An official API beats a scraped console page every time.

The review-seeding version, and why it isn't a QA problem

Now the other reader. If the goal is a stack of accounts leaving positive reviews (yours, friends', bought, or "testers'"), that's rating manipulation, whatever the ticket calls it.

Why does it get caught? The stores don't check one thing. Google says it removes policy-breaking reviews through a mix of automated and human review, and neither store publishes its signals, but they can look well beyond the browser: accounts, devices, install history and timing. A browser profile changes, at most, what one browser reports. It doesn't change the fact that ten "independent" reviewers all showed up the week your rating dipped. There's a longer look at this in our piece on how review seeding gets detected.

And the downside is far bigger than a few deleted reviews:

Google Play's developer policies prohibit manipulating ratings, reviews and installs, and enforcement can go from removing reviews to removing the app or terminating the developer account.
Apple's developer code of conduct says that attempting to manipulate reviews or chart rankings can get you removed from the Apple Developer Program.
In the US, the FTC's rule on consumer reviews and testimonials, in force since late 2024, lets the agency seek civil penalties for fake reviews.

If a developer account has been actioned for this, the route back is the store's own appeal process, not a new account.

What do teams with good ratings actually do? Boring things. They ask at a genuinely happy moment (a finished workout, a delivered order), never after an error. They reply to reviews, especially angry ones, because other users read the replies. They fix what the one-star reviews keep naming. And on iOS, when a release fixes a problem that dragged the rating down, App Store Connect lets you reset the summary rating with the new version. That's the legitimate version of a fresh start.

Common errors and how to fix them

The review prompt never shows in TestFlight

Cause: Expected. Apple's review request has no effect in TestFlight builds.

Fix: Check the UI in a development build on a device, and cover the trigger logic with unit tests.

The Play dialog showed once, then never again

Cause: The In-App Review API's quota. It isn't guaranteed to display on every call.

Fix: Follow Google's testing page for a repeatable setup, and make sure your app behaves the same whether or not the dialog appears.

Reviews from our QA team aren't showing on the listing

Cause: Store filtering doing its job. Reviews from people tied to the developer aren't meant to count.

Fix: Stop posting real reviews from test accounts. Delete any that are live, and move that test step to a development build or test track.

A teammate hits a security checkpoint signing in to Play Console

Cause: Usually a shared login, or a new device and location on an account that wasn't set up for it.

Fix: Invite the person with their own account, turn on 2-Step Verification, and complete Google's verification normally. Their own profile keeps the session stable.

Frequently Asked Questions

Why do reviews posted by our QA team disappear from the store?

Google Play's review policy tells people not to review an app they own or work on, or to review the same app from several accounts, and says reviews that break it are removed. Apple's guidelines forbid manipulating reviews. A team reviewing its own app falls under both, so a missing test review is most likely the stores' moderation at work. Check each store's current review policy, test with their official tools, and keep real submissions off your production listing.

How do I test the Google Play in-app review dialog?

Use FakeReviewManager from the Play Core review testing package to test your trigger logic, then use internal app sharing or an internal test track to see the real dialog on a device. Google's testing page for in-app reviews explains what each option shows and whether a review can be submitted. The API also has a quota, so the dialog won't appear on every call.

Why does the Apple review prompt never appear in TestFlight?

Apple documents this: the review request always shows in a development build so you can check the UI, but it has no effect in an app distributed through TestFlight. In production the system decides whether to show it and shows it to any one user at most three times in a 365-day period. Test the UI in a development build and test your trigger conditions in code.

Can an antidetect browser help with app review testing?

Only on the desktop and web side. JustBrowser runs on Windows x64 and Apple Silicon Macs and generates desktop identities, not mobile ones, so in-app prompts belong on devices or emulators. It helps with separate profiles for each teammate's own console login, locale checks on store listings and web feedback pages, and automation through a local API. It is not a tool for posting reviews.

Is it ever OK to post reviews from several accounts to boost a rating?

No. Google Play's policies prohibit manipulating ratings and reviews, Apple's developer code of conduct can remove you from the Developer Program for it, and in the US the FTC's rule on consumer reviews lets the agency seek civil penalties for fake reviews. Ask real users at a good moment with the official prompt, reply to reviews, and fix what the one-star reviews are telling you.

If you're also paying for install campaigns, bot traffic on the ad side is a separate leak worth understanding; this breakdown of what click fraud really costs is a decent place to start.

Try JustBrowser

Native Chromium antidetect browser — not extension-based. Real C++ engine patches at the canvas / WebGL / audio / font / screen layer, always current with upstream Chromium. Local REST API + CDP for Playwright, Puppeteer, Selenium. Runs on Windows x64 and macOS (Apple Silicon). $9.99/month or $99.99/year. 7-day free trial, card required — cancel any time in the seven days and you are not charged. Unlimited profiles, unlimited cloud sync, unlimited team seats.

Get started → · How it differs from Multilogin / GoLogin / AdsPower