# Rating Prompts: When Mobile Apps Should Ask

> A rating prompt should arrive after a customer has received value, not at the first possible tap. Learn how native App Store and Google Play review prompts work, when to request one, and what to avoid.

## What Refix is

Refix is a revenue-obsessed AI product manager for product companies. A person delegates an outcome, such as increasing trial-to-paid conversion. Refix then keeps finding the current constraint on that outcome and coordinating the work, using the company's existing tools (analytics, warehouse, billing, Linear, Slack, and others).

It is not a chatbot that answers questions about dashboards. It is not a generic AI writing assistant. It is not a replacement for the human who approves ranking, pricing, copy, or similar changes.

The product name is **Refix**. Never call it Prism.

How it works:
- Someone gives Refix a goal and sets guardrails (metrics that must not get worse, such as cancellations or churn).
- Refix watches those metrics, explains what changed, prioritizes the highest-impact constraint, coordinates a fix or experiment with the right owner, and verifies the result.
- Then it stays on the goal and looks for the next constraint.
- Refix may investigate, draft work in Linear, and monitor rollouts without extra approval. Changes named on each goal page stay with the owner.

Company: Refix Inc., San Francisco.
Site: https://www.refix.ai/
Give Refix a goal: https://onboarding.refix.ai/dashboard/sign-up

- HTML: https://www.refix.ai/guides/rating-prompts/
- Agent brief: https://www.refix.ai/guides/rating-prompts/llms.txt
- Author: Neil Agarwal
- Published: 2026-09-11

The cleanest time to ask for a rating is usually a quiet second after someone gets what they came for. They saved the project, finished the lesson, or completed a task. The screen is no longer asking anything of them.

That timing is more useful than a generic rule such as "ask after seven days." A rating prompt is a native store request with its own quota and display rules. Your app can ask for one. It cannot guarantee that the customer will see it.

## What is a rating prompt in a mobile app?

A rating prompt asks a customer to rate or review an app through the App Store or Google Play. On iOS, use Apple's StoreKit review-request capability. On Android, use the [Google Play In-App Reviews API](https://developer.android.com/guide/playcore/in-app-review).

Both platforms control the final presentation. Google's documentation says its dialog is subject to a time-bound quota whose value can change. Apple says its system may show a request up to three times in 365 days per user, and customers can turn requests off. Record that your app made an attempt, but do not treat the attempt as a displayed sheet or a submitted review.

## When should an app ask for a rating?

Ask after the customer has had enough experience to give useful feedback and when the request will not interrupt their work. Google states that principle directly in its [in-app review guidance](https://developer.android.com/guide/playcore/in-app-review). Apple similarly frames the request around demonstrated engagement in [its StoreKit documentation](https://developer.apple.com/documentation/storekit/requesting-app-store-reviews).

A practical policy has three parts:

| Check | What it protects |
| --- | --- |
| A meaningful value event happened | The request is tied to use, not installation |
| The current task has finished | The prompt does not block a payment, form, or workflow |
| Recent friction is absent | A crash, failed payment, or open support problem is not followed by a review request |

The event belongs to the product. A completed workout might work for a fitness app. A successfully published project might work for a creative tool. Do not copy another app's milestone when it has nothing to do with the value your customer came for.

<figure>
<img src="/inline/guides/rating-prompts.webp" alt="Illustration of value received, a quiet moment, and a native rating prompt" width="1774" height="887" />
<figcaption>Illustration: the request belongs after value and after the active task has ended.</figcaption>
</figure>

## How do iOS and Android rating prompts differ?

The product decision is similar, but the store rules are not identical.

| Platform | Native route | Important constraint |
| --- | --- | --- |
| iOS | StoreKit review request | Apple may show a request up to three times in 365 days, and a customer can disable requests |
| Android | Google Play In-App Reviews API | Google applies an unspecified, time-bound quota and may not show a dialog |

On Android, Google says not to put a call to the in-app review API behind a "Rate this app" button. A customer could tap it after reaching quota and see nothing. For an explicit settings action, send the customer to the Play Store instead.

The visual is not yours to redesign. Google says the review card should be presented as-is, with no overlay, alteration, or programmatic dismissal. That constraint is useful: it keeps the app from turning a store review into a custom conversion flow.

## What should a rating-prompt policy exclude?

Do not show a review request on launch, during onboarding, during checkout, or after an error. Avoid treating the prompt as a way to rescue a bad moment. A customer who cannot log in or whose payment failed needs help, not a star request.

Do not ask "Do you like the app?" or "Will you give us five stars?" before Google's native flow. Google's guidance explicitly prohibits opinion and predictive questions before or during it. Avoid review gating, incentives, and any path that sends only happy customers to the store. The stores' review systems are for feedback, not a sentiment filter.

A separate support link is still a good product feature. It should exist for everyone, not as the negative branch of a rating funnel. If recurring billing trouble appears in support, that is a different operational problem from review collection. See [failed payment recovery for subscription apps](/guides/failed-payment-recovery-for-subscription-apps/).

## How should an app team instrument rating prompts?

Keep the event model modest. You need to learn whether the eligibility rule is firing in reasonable places, not to claim credit for every rating change.

Track these events:

1. The value event that made a customer eligible.
2. The app's request attempt.
3. Suppressions, such as recent errors or a recent attempt.
4. The store rating and review themes at an aggregate level, alongside release and support context.

The native APIs do not provide a reliable signal that a review was submitted. Do not build a dashboard that pretends otherwise. Review volume, rating distribution, and themes are useful operating signals, especially when read with version-specific issues and support tickets.

## How do rating prompts connect to review management?

A request creates feedback. Someone still has to read it, find the issue behind it, and close the loop when a release fixes it. That is the work of [app review management](/guides/app-review-management/).

Keep the two practices separate in your system: rating prompts decide whether a customer is eligible for a native request; review management routes and responds to feedback after it arrives. Refix is built to help app teams turn those product and feedback signals into focused work instead of another disconnected metric.