Why the In-App Review Prompt Isn’t Showing

In almost every case we are called into, the integration is correct and the platform decided not to show anything — which both Google and Apple document as a normal outcome rather than a failure. Neither API promises you a dialog, and neither will tell you afterwards that it withheld one.

That is the first thing to internalise, because it inverts how you debug: you cannot reason from "no dialog appeared" to "the call failed". Google's In-App Review API documentation states that Play enforces a time-bound quota on how often a user can be shown the review dialog, and that calling the flow more than once in a short period — its own example is less than a month — might not always display a dialog. Apple's StoreKit documentation is blunter still: because this API may not present an alert, do not call it in response to a button tap or other user action.

So the question is never "why is it broken". It is "which of the documented reasons for silence applies to this build, this device and this user". There are four families, and they are worth checking in this order because the cost of checking rises sharply as you go down the list:

Across the 300+ apps we have managed since 2013, the first family is where these reports usually resolve, and it is also the cheapest to rule out. Start there.

Nothing at all about the dialog — Google states the API does not indicate whether the user reviewed or not, or even whether the review dialog was shown. That single sentence explains why teams burn days on this: they are looking for a signal that was never designed to exist.

The Kotlin and Java integration guide spells it out in the code comments themselves. When the flow finishes, the documentation says the flow has finished, the API does not indicate whether the user reviewed or not, or even whether the review dialog was shown, and that no matter the result you continue your app flow. The instruction that follows is equally firm: if an error occurs during the in-app review flow, do not inform the user or change your app's normal user flow.

There is exactly one place where Play will talk to you, and most implementations throw it away. The request stage — the call that obtains a ReviewInfo object before you launch anything — can fail with a ReviewException carrying an error code. Catch it and log it. It will not tell you whether the dialog appeared, but it will tell you whether you ever got as far as being able to ask.

So the realistic instrumentation on Android is: log the request outcome, log the moment you launched the flow, and accept that everything after that is opaque.

Because Play caps how often any given user can see the dialog, and Google explicitly refuses to publish the number. Its wording is worth quoting exactly, because it settles an argument that comes up in every integration review.

Google states that to provide a great user experience, Play enforces a time-bound quota on how often a user can be shown the review dialog, and that because of this quota, calling the launch method more than once during a short period of time — for example, less than a month — might not always display a dialog. Then the note: the specific value of the quota is an implementation detail, and it can be changed by Google Play without any notice.

We will not print a quota figure here, and neither should your internal documentation. Google has told you the value is not a contract. Any number circulating in a Slack thread or a vendor blog is somebody's observation from a sample of devices at a point in time, and building retry logic or a reporting baseline on it means building on something Google has reserved the right to change silently.

The design consequence is the one Google draws itself, and it is the single most commonly violated rule in this area:

The same logic applies to retries. Calling again five minutes later does not improve your odds. The quota is per user and time-bound, so the only lever you control is choosing a better moment the next time that user reaches it.

On Android the distribution method decides the behaviour, and two of the three testing routes deliberately do not behave like production. This is where most "it does not work on my device" reports resolve, and it is a fast check.

Google's guide to testing in-app reviews sets out three routes and what each one does differently.

The four internal-test-track conditions are the ones people miss, and every one of them is a real-world failure we have seen:

• The user account is part of the internal test track. Adding the email to the wrong track, or to the wrong Google group, is the classic.
• The account is the primary account and it is selected in the Play Store. A test device with three signed-in accounts will fail this without any visible symptom.
• The account has downloaded the app from the Play Store, so it is listed in that user's Google Play library. A sideloaded APK does not qualify — though once the account has downloaded it once from the track, Google says you can deploy new versions locally to that device.
• The account does not currently have a review for the app. Your most enthusiastic tester, who rated the app in week one, is the least useful person to hand the test build to.

If your QA process is "install the APK from the build server and tap through", the prompt was never going to appear, and no code review will find the reason.

Because Apple documents that the review request has no effect in apps distributed for beta testing using TestFlight. It is not throttled there, or delayed, or subject to a quota you might eventually clear. It does nothing.

Apple's documentation for the StoreKit review request states that when your app calls the method while it is in development mode, StoreKit always displays the rating and review request view so you can test the user interface and experience — and then that this method has no effect in apps that you distribute for beta testing using TestFlight.

Read those two sentences together and the confusing bug report resolves itself. The engineer running a debug build from Xcode sees the dialog every time. The QA team on the TestFlight build never sees it once. Both are correct, and nobody's device is faulty.

This one detail probably costs the industry more engineering hours than the rest of the topic combined, because the failure is silent, reproducible and looks exactly like a broken integration. In our portfolio it has been a recurring answer to iOS review-prompt escalations we have received.

More than you would guess — Apple publishes explicit eligibility criteria, including a device-level opt-out that removes a user from your reachable population permanently. If your build is fine and your code is fine, this is the next fault to isolate.

Apple's RequestReviewAction documentation lists the criteria StoreKit applies:

• If the person has not rated or reviewed your app on this device, StoreKit displays the request a maximum of three times within a 365-day period.
• If the person has already rated or reviewed your app on this device, StoreKit displays the request only if the app version is new and more than 365 days have passed since their previous review.
• People can disable requests for reviews from ever appearing on their device, which Apple states in its guidance on requesting App Store reviews. That is a system setting across all apps, not something you can detect or influence.

Android has a different eligibility question, which is device capability rather than user history. Google states that in-app reviews only work on Android devices — phones, tablets, and TVs with Google TV — running Android 5.0, API level 21, or higher that have the Google Play Store installed, plus ChromeOS devices that have the Play Store installed. It also states your app must use version 1.8.0 or higher of the Play Core library. An app shipping to devices without Play services, or to a market where a meaningful share of installs come from other stores, has a structurally smaller addressable population for the prompt than its install base suggests. If a large share of your Android installs arrive through alternative app stores, that gap is worth quantifying before anyone sets a ratings target.

The honest version of the maths here is directional. Neither platform reports how many of your users are ineligible on any given day, so any "we should be seeing X prompts a week" projection is an estimate built on an unknowable denominator. We do not publish one, because there is no primary source that supports a figure.

The four most common integration patterns in this area are all explicitly prohibited, and one of them makes the dialog look broken even when everything works. Check these before you open a support thread.

Item two is worth escalating to whoever owns product, not just engineering. Removing the pre-qualifying question usually reduces the average rating of prompted users, which is precisely the point: the store is asking for a representative sample, and our piece on generating ratings and reviews properly covers what to do about volume instead.

After a user has completed something successfully, several times, on a version you have not already prompted them on — and never at launch or during onboarding. Apple publishes a worked example of exactly this, and it is more conservative than most teams expect.

In Apple's sample project, the app presents the request only from the scene shown after a person completes a simulated three-step process, and only when three further conditions hold: the app has not shown a prompt for a version matching the current bundle version; the person has completed the process at least four times, a number Apple describes as arbitrary and adjustable; and the person has paused on the completion screen for a few seconds, which Apple says limits the possibility of the prompt interrupting them. The sample then delays the call by two seconds to avoid interrupting the person using the app.

Apple's Human Interface Guidelines add the pacing rule: ask only after people have demonstrated engagement, avoid asking on first launch or during onboarding because people have not had time to form an opinion, avoid interrupting a task, and consider allowing at least a week or two between requests, prompting again after people demonstrate additional engagement. Google's equivalent is shorter and points the same way: trigger the flow after a user has experienced enough of your app or game to provide useful feedback, and do not prompt excessively.

Put together, the placement question is a retention question rather than a ratings question. You are looking for the point in your product where a user has just succeeded at the thing they came for — which is the same moment your activation analysis should already have identified. Our work on finding the activation moment is the input to this decision, not a separate exercise.

You measure your side of the boundary and correlate it with the store's numbers, because no other feedback loop exists. Any dashboard claiming a prompt-to-review conversion rate on either platform is inferring it, and you should know which parts are inferred.

What you can legitimately record, entirely from your own app:

What you cannot record is whether a dialog appeared, whether it was dismissed, or whether a rating was submitted. Treat that gap as permanent.

The correlation that does work is coarse but honest: change one thing — the screen, the completion threshold, the version gate — hold it for a defined period, and watch new ratings volume in Play Console and App Store Connect. Google notes new ratings are generally held back around 24 hours before posting publicly, so do not read the first day as a result.

If your ratings volume is the real problem rather than the prompt, the diagnosis usually starts one level up, with what happened to the score itself — our piece on why an app rating drops covers the weighting behaviour that makes recent ratings matter so disproportionately.

A user-initiated path that is not the API, and the review-reply channel — both documented, both underused, and neither subject to the quota that is blocking you. This is where a stalled ratings programme usually gets unstuck.

The first is the escape hatch both platforms hand you. Apple documents a persistent link to your product page — append the write-review query parameter to your App Store product URL — and suggests placing it in your app's settings or configuration screens. Google's instruction for the same use case is to redirect the user to the Play Store. That is how you build a "Rate this app" affordance that always works.

The second is replies. Google's ratings documentation states that users can only rate an app once, but they can update their rating or review at any time — and that developers must not solicit or promote ratings in replies, with violations able to result in app or account suspension. Telling a user which version fixed the problem they reported is factual and relevant; asking them to raise their score is not. The former converts existing negative ratings, which is worth more than adding neutral ones on top.

Ratings act as a multiplier on every listing visitor you attract, including every visitor you paid for, so a stalled review prompt is an acquisition problem with a delay attached. Our guide to store listing conversion puts the score in context with the other levers, and our ASO work treats them as one system.

If you have ruled out the build, the user and the implementation and the prompt still will not appear, that is a short conversation with someone who has debugged it before — tell us what you are seeing and on which track.