In-app review prompts for iOS and Android (2026)

Key takeaways

• Use the native prompts. On iOS that is requestReview, on Android the Google Play In-App Review API. Tokopedia told Google its five-star ratings grew 4x after adopting the Android one.
• Show the prompt right after a success moment: an order that arrived, a level won, a task finished. Never at launch, mid-task or after an error.
• The stores decide whether the prompt appears. Apple caps it at three times per user a year. Google enforces an unpublished quota. Neither tells your app whether it showed.
• Never trigger the prompt from a button.
• Asking "Do you enjoy the app?" first is review gating. It lifts the average on fewer ratings, and Google Play's rules forbid it outright.
• The prompt brings in complaints too. Plan to reply to them.

Most apps ask for a rating the same way: a popup on day three, shown to everyone, at whatever moment the timer fires. Half the people who see it are in the middle of something. Some just hit an error. The prompt was supposed to collect happy users' ratings and instead it collects annoyed ones.

This guide is for the developer or product manager who owns that prompt. It covers when to show it, the code for both platforms, the limits the stores enforce, and one tempting shortcut that breaks the rules.

Do native review prompts bring more ratings?

Yes. The rating happens in a small sheet inside your app, so users never leave it and more of them finish. Sending people to your store page costs them a context switch: the store opens, they find the stars, they come back if they remember. The native prompts skip all of that. The rating happens in a small sheet inside your app.

The volume difference is large. When Google launched its in-app review API, Tokopedia's technical architect said: "Our 5-star ratings since implementing the API has increased by 4x." (Android Developers Blog)

There is a second effect to expect. Without a prompt, the people who rate are mostly the ones who seek out your store page, often because something annoyed them. A native prompt also asks people who would never have gone looking. For an app that works, that means a steadier flow of ordinary ratings next to the furious ones people write on their own.

The native prompt is also the only kind of rating dialog allowed on iOS. A custom star rating screen of your own is not a substitute: Apple disallows custom review prompts, and on Android only the In-App Review API submits a rating to Google Play from inside your app.

When should you show the review prompt?

Right after the user got what they came for, and never at launch, mid-task or after an error. Apple's own guidance says the same: "Make the request when users are most likely to feel satisfaction with your app, such as when they've completed an action, level, or task. Make sure not to interrupt their activity." (Apple Developer)

The prompt works at the end of a good moment, never in the middle of one.

Good moments by app type:

• Games: after a level or match the player won.
• Shopping and delivery: after an order arrived on time.
• Productivity: after a task is finished, saved or exported.
• Habit and learning apps: after a streak or a goal.

Never ask:

• on first launch or during onboarding,
• in the middle of a task, a purchase or a level,
• after a crash, an error, a failed payment or a paywall,
• from a "Rate us" button.

A practical eligibility rule, before your success moment even counts:

• installed for at least 7 days,
• at least 3 sessions,
• no crash in the last session,
• not asked in the last 90 days.

These numbers are starting points, not store rules. Tune them against your own data.

iOS: requestReview and SKStoreReviewController

On iOS 16 and later, SwiftUI gives you a requestReview action. You ask; the system decides whether to show the prompt.

import StoreKit
import SwiftUI

struct OrderDeliveredView: View {
    @Environment(\.requestReview) private var requestReview

    var body: some View {
        DeliveredSummary()
            .task {
                // Your rules decide if the user is eligible.
                // The system decides if the prompt actually appears.
                if ReviewPrompt.isEligible() {
                    requestReview()
                }
            }
    }
}

In UIKit, call AppStore.requestReview(in:) with the current window scene. Older code uses SKStoreReviewController.requestReview(in:), which does the same job but is deprecated from iOS 18, so move to AppStore.requestReview(in:) when you next touch that code.

What Apple enforces:

• At most three prompts per user in 365 days. Apple may show fewer. (Apple Developer)
• You cannot tell whether it appeared, or whether the user rated.
• Development builds always show it. TestFlight builds never do. Do not judge your flow from TestFlight.
• Custom review prompts are not allowed. App Review Guideline 5.6.1: "Use the provided API to prompt users to review your app… and we will disallow custom review prompts."

Android: the Google Play In-App Review API

On Android, request a review flow, then launch it at your success moment.

val manager = ReviewManagerFactory.create(context)

manager.requestReviewFlow().addOnCompleteListener { request ->
    if (request.isSuccessful) {
        val reviewInfo = request.result
        manager.launchReviewFlow(activity, reviewInfo).addOnCompleteListener {
            // The flow finished. You can't tell whether the card showed
            // or whether the user rated, so just continue.
            continueToNextScreen()
        }
    } else {
        // Requesting the flow failed. Carry on as if nothing happened.
        continueToNextScreen()
    }
}

Google suggests requesting the review info shortly before the moment, once you are sure you will show the card, because the request takes a moment. The sample does both steps together for brevity. Use FakeReviewManager in tests, and an internal test track or internal app sharing to see the real card.

What Google enforces:

• A time-bound quota, which Google does not publish and may change. Call the API too often and it shows nothing.
• No button. Google's guidance: "you should not have a call-to-action option (such as a button) to trigger the API", because the card may not appear and the user gets a broken experience.
• No questions first. More on that below.

What is review gating, and is it allowed?

Review gating means asking users whether they like the app first and sending only the happy ones to the store. It lifts your average, and it is not allowed: Google Play forbids it outright, Apple treats filtered feedback as manipulation, and the FTC warns against asking only customers you expect to be happy.

It is still the most common shortcut in this whole topic. A screen asks "Do you enjoy the app?". Users who tap yes get the store prompt. Users who tap no get a feedback form. Only happy users reach the store.

It works on the number. Filtering out unhappy users before they can rate lifts your average, because the people most likely to rate low never reach the store. The cost is volume: every extra screen loses people.

Here is why you should not ship it:

• Google Play forbids it in plain words. "Your app shouldn't ask the user any questions before or while presenting the rating button or card, including questions about their opinion (such as 'Do you like the app?') or predictive questions (such as 'Would you rate this app 5 stars')." (Google Play In-App Review guidelines)
• Apple treats filtered feedback as manipulation. The App Store Review Guidelines warn developers who "manipulate reviews, inflate your chart rankings with paid, incentivized, filtered, or fake feedback", and guideline 5.6.1 requires Apple's own prompt.
• US regulators say the same. The FTC's guide for marketers: "Don't ask for reviews only from customers you think will leave positive ones."

Both flows ask for a rating. Only one is allowed on both stores.

The compliant version gets most of the benefit. Asking at a success moment already reaches users while they are satisfied, without asking them anything first. And unhappy users still need somewhere to go:

• keep a Help or Send feedback item in settings that is always there,
• after an error, it is fine to offer support ("Something went wrong. Contact us?"),
• but that feedback route must never decide who sees the rating prompt.

What to measure: more ratings, and better ones

Three numbers tell you whether the prompt works:

• Ratings per 1,000 active users per week. Did the prompt raise the flow of ratings?
• The average of new ratings, last 30 days, against your lifetime average. Are recent ratings better or worse than your history?
• The share of new ratings with written text. Written reviews are the ones people read and the stores summarize.

Both Play Console and App Store Connect show ratings over time, so you can compare the weeks before and after a change. The Ratings view in AppReply also splits your store rating by app version, so you can see whether the release that added the prompt moved it. Change one thing at a time: the moment, the eligibility rule, or the cooldown.

The prompt brings in complaints too

More ratings means more written reviews, and some of them will be one star. That is normal and it is useful: those reviews tell you what to fix, and future users read how you answer them.

Answer them well and more of them get raised: in AppReply data, low-star reviews that got a reply were later raised about 4.6 times as often as those that did not, and Google Play reports an average gain of 0.7 stars when a developer responds. AppReply collects new reviews from all five stores in one feed and can alert your team when one-star reviews spike after a release. Our guide on how to respond to negative reviews shows real replies, graded, and the mechanics of replying in each console are in how to reply to app store reviews. If your rating is dropping and you don't know why, start with our rating drop guide.

A checklist before you ship the prompt

• It uses the native API on each platform.
• It fires right after a success moment, from your code, never from a tap on a button.
• Nothing asks the user how they feel before it appears.
• Eligibility rules keep it away from new users, crashes and recent prompts.
• There is an always-available feedback route in settings.
• Someone reads and answers the reviews it brings in.

For the rest of the review lifecycle, from monitoring to analysis, see App Store Reviews 101.