Flutter In-App Review Prompts on Google Play (2026): When to Ask, What to Store, How to Test

By giosaia (GSPTeck) · Published 2026-10-11 · Last verified 2026-10-11

Ratings matter for a small Android app, and Google Play's In-App Review API lets users rate you without leaving the app. It's also easy to get wrong: prompting too early, wrapping it in a “Do you like the app?” dialog, or wiring it to a button that sometimes does nothing. This is the routine I use for Flutter apps as a solo developer: when to ask, what to store locally, how to stay within Google's rules, and how to test it. Every rule quoted here comes from Google's own In-App Review API documentation, checked 2026-10-11.

Google's rules, in short

Two columns of Play in-app review rules: do ask after real use, show the card as-is, keep it rare and have a Play Store fallback; don't ask a question first, overlay the card, trigger from a button or assume it was shown — Google's rules at a glance.

The documentation sets out a few guidelines that shape everything else:

Timing: trigger the flow after the user has experienced enough of your app to give useful feedback, and don't prompt excessively.
No pre-questions: your app shouldn't ask the user any questions before or while showing the rating card. That includes opinion questions such as “Do you like the app?” and predictive questions such as “Would you rate this app 5 stars?”.
Design: show the card as-is. Don't change its size, opacity or shape, don't overlay anything on or around it, and don't remove it programmatically.
Quota: Google Play enforces a time-bound quota on how often a user can see the dialog. Calling the flow more than once in a short period (the docs give less than a month as an example) might not display anything. The exact quota is an implementation detail Google can change without notice.
No button triggers: because the dialog might not appear, don't attach the API to a call-to-action such as a “Rate us” button. For that use case, send the user to the Play Store listing instead.

Device requirements are modest: Android 5.0 (API level 21) or higher with the Play Store installed, or ChromeOS with the Play Store.

Picking the moment

Four steps to pick the moment: after a completed task, on the Nth success rather than first launch, when there was no recent error or paywall, and weeks after the last attempt — Picking the moment.

The API gives you no feedback on whether the dialog appeared or whether the user rated, so the only thing you control is when you call it. My rules of thumb:

After value, not on launch. Call it right after the user completes the app's core action: a successful swap, a saved file, a finished workout. Never on the first open.
After repeat success. Wait for the third or fifth success, not the first, so the user has an informed opinion.
Only in calm moments. Skip it if the session just had an error, a crash, a failed purchase or a paywall. A frustrated user isn't a good moment, and it's not fair to them.
Leave long gaps. Keep weeks between attempts and a small lifetime maximum. The Play quota will block excess calls anyway, so extra calls only waste your best moments.

What to store locally

Grid of local state to keep: first open date, success count, last attempt, lifetime attempts, recent crash flag and app version — What to store locally.

All of this needs a little local state. Shared preferences are enough:

First open date, to enforce a minimum install age.
Success count for the core action.
Last attempt timestamp and lifetime attempts, for gaps and caps.
Recent crash or error flag, set by your error handling and cleared after a clean session.
App version at last attempt, if you'd rather allow at most one attempt per release.

The decision then becomes one small pure function, shouldAskForReview(state, now), which is easy to unit test, and much easier to reason about than review calls scattered across screens.

The Flutter side

Most Flutter apps use a plugin rather than calling Play Core directly. The community in_app_review package wraps the native API on Android (and the equivalent on iOS). It offers a way to check availability, request the in-app review, and a separate method to open the store listing. Check the package page for its current API and platform notes before you integrate. The pattern stays the same:

When your decision function says yes, check availability, request the review, and record the attempt whether or not anything visibly happened. You can't know.
For a permanent “Rate this app” item in Settings, open the store listing. Don't call the in-app flow from a button, as Google's docs warn.
Never show your own dialog first. No “Enjoying the app?” gate, and no star picker that only sends happy users to Play. That's exactly what the no-questions rule forbids.

If you'd like a way to switch prompting off without shipping a new build, put the whole thing behind a remote flag. I covered that pattern in Remote Config kill switches and staged rollouts.

Testing it properly

Four testing steps: the internal test track where quota isn't enforced, internal app sharing where submit is disabled, FakeReviewManager for unit tests only, and shipping behind a remote flag — Testing before release.

Google's testing guide for in-app reviews explains why “it doesn't show up” is so common during development:

The app must be on Play. It doesn't need to be in production, but its application ID must be available at least on the internal testing track.
Internal test track: the account must be a tester, be the primary account selected in the Play Store, have downloaded the app from Play, and not already have reviewed it. Quota limits aren't enforced for apps downloaded from the internal test track. After that first download, you can deploy local builds to the device.
Internal app sharing: good for fast iteration, but reviews can't be submitted, and the submit button is disabled.
FakeReviewManager: the native library includes a fake for unit and integration tests. It doesn't simulate the UI. It just reports success.
Other common blockers listed in the guide: a protected or enterprise account, an existing review on that account, and a sideloaded Play Store.

In Flutter, I unit test the decision function with fixed dates and counts, then do one manual pass on the internal test track before each release that touches this logic.

Fitting it into a release routine

Review prompts pair naturally with the post-launch habits from my Play Console product-ops checklist. Before each release:

Check that crash rates are normal. Don't widen prompting during a bad release. My Crashlytics triage routine helps here.
Confirm the remote flag and thresholds are what you intend.
Read new reviews in Play Console and reply to the ones that report bugs.
Change one threshold at a time, so you can tell whether a change helped.

One last tip: write down your thresholds in the changelog when you change them, so a future you can tie rating trends in Play Console to a specific release.

FAQ

Why doesn't the review dialog appear?

Usually the quota, an account that already reviewed the app, an install not from Play, or internal app sharing (where submit is disabled). Google's testing guide lists the common causes.

Can I ask whether users like the app first?

No. Google's guidelines say not to ask any questions before or while showing the rating card.

How often can I call it?

Google doesn't publish the quota and can change it. Call it rarely, at good moments, and assume a call may show nothing.

Can I add a “Rate us” button?

Yes, but have it open the Play Store listing rather than the in-app review flow.

Sources

Android Developers: Google Play In-App Reviews API (checked 2026-10-11)
Android Developers: Test in-app reviews (checked 2026-10-11)
pub.dev: in_app_review (checked 2026-10-11)