How to Get More App Reviews: In-App Prompts Timing and What Apple and Google Allow

To get more app reviews, trigger Apple's StoreKit review prompt or Google Play's In-App Review API right after a user hits a genuine success moment — not on first launch, not after an error — ask every user the same way regardless of how they're feeling, and back it up with an email or SMS request after support interactions close well. Why most apps have fewer reviews than they could Most teams don't have a review problem so much as a timing problem. The prompt fires on a session counter instead of an outcome, so it interrupts people mid-task as often as it catches them after a win. Or it fires once during onboarding, gets dismissed by someone who hasn't formed an opinion yet, and burns one of a limited number of yearly prompt opportunities before the app has even proven itself. Fixing native review prompts and review tracking together — getting the timing right and knowing which requests actually converted — tends to move the review count more than any single clever trick. It's also worth separating two different jobs that get lumped together: the native in-app prompt (StoreKit on iOS, the In-App Review API on Android) and an outside-the-app request sent by email, SMS, or in a support reply. They work differently, they're governed by different rules, and the strongest review programs use both. Apple's StoreKit review request API On iOS, the compliant way to ask for a rating inside your app is Apple's StoreKit review request API (commonly referred to by its underlying class, SKStoreReviewController). You call it, and iOS decides whether to actually show the native rating sheet — you don't control that decision, and you get no callback telling you whether the user rated, dismissed, or never saw it at all. Two things matter about how Apple throttles this: the system caps how many times a given user can see the prompt within a rolling period, and once someone has already rated or dismissed it, repeated calls from your code do nothing until that window resets. That's by design — Apple's guidelines explicitly prohibit launching your own custom rating-request UI that mimics or replaces the system prompt, and they prohibit asking only certain users based on a filter you built. The API exists partly to prevent exactly the kind of selective asking some teams try to engineer around it. Practically, that means you get a handful of real attempts a year, so the moment you pick for each attempt matters more than the mechanics of calling the API. Google Play's In-App Review API Android's equivalent is Google Play's In-App Review API. Like StoreKit's version, it shows a native, non-interruptive rating dialog inside your app flow, and Google — not your code — decides whether to actually display it for a given user at a given moment. Google also quotas how often a single user sees the prompt, and the API intentionally gives developers no way to target the request only at users who've indicated they're happy, which closes off the same gating loophole Apple's API closes. If your app runs on both platforms, treat the two prompts as entirely separate review pools to manage — your iOS rating and your Android rating are independent numbers, built from independent prompt flows, and a strong rating on one tells you nothing about the other. When to actually trigger the prompt Since both platforms limit how often the system will even show the dialog, wasting an attempt on a bad moment is expensive. A few patterns that hold up across most apps: Ask right after a completed task, not during one. An order placed, a workout logged, an export finished, a trip booked — the moment right after something worked is when people are most willing to say so. Ask after a milestone, not a session count. A tenth completed session or a streak hitting a round number reads as an achievement. A generic "you've opened the app 5 times" counter doesn't. Never ask right after an error, crash, or failed sync. This sounds obvious, but it's the single most common mistake when prompts are wired to a timer instead of an actual outcome. Give purchases and subscriptions a beat. People are often slightly guarded right after a charge hits their card. Let a day or a successful follow-up action pass first. Stop asking once someone's rated. Both APIs throttle this for you to a degree, but your own code should still track whether a user has already responded so you're not burning app logic re-triggering a dialog the OS has already decided not to show. Why a "do you like the app?" pre-survey is the wrong fix A pattern that shows up constantly in app-growth advice: put a simple yes/no question in front of the native prompt — "Enjoying the app so far?" — and only route the people who say yes into the StoreKit or In-App Review call, sending everyone who says no to a private feedback form instead. It sounds reasonable. It's also review gating, and it's the exact behavior both platforms' APIs are built to make harder, not easier, to pull off. The problem isn't just that it's against Apple's and Google's developer policies, or that the FTC's rule on fake and deceptive reviews (16 CFR Part 465) treats steering only satisfied customers toward a public review as a form of review manipulation. It's that it quietly breaks the one thing a star rating is supposed to tell a stranger: what the typical user actually experienced. If your prompt logic filters out anyone who hesitates, your 4.8 stars stops meaning what a shopper assumes it means. See our deeper look at why review gating is a legal risk, not just a reputational one, for the mechanics of how this gets enforced. The fix is almost boring: trigger the native prompt the same way for every user who hits the chosen moment, full stop. If you want to catch unhappy users before they vent in a public review, do it with a separate, always-available feedback channel inside your app — a support button, an in-app message option — rather than a gate that decides who's even allowed to see the rating prompt. Asking outside the app: email, SMS and support follow-ups The native prompts aren't the only lever. A direct link to your App Store or Google Play listing, sent by email or text after a support ticket closes well or a milestone email goes out, reaches people the in-app prompt never catches — someone who hasn't opened the app in a week but just got unblocked by a support reply, for instance. The same no-gating rule applies here too: send the same request to everyone who reaches that trigger point, not just the tickets your support team marked as a win. If you need a starting point for the wording, our review request text message templates cover the tone that tends to convert without sounding like a demand. One mechanical note if you're texting users in the US: review requests sent by SMS are generally treated as subject to TCPA consent requirements , so make sure you already have a basis for texting that user before adding an automated review request to the flow. Keeping track of what's actually working Once you're running more than one trigger — an in-app prompt on both platforms, plus email and SMS follow-ups — it gets easy to lose track of which moment is actually driving new reviews versus which one is just noise. Review volume by trigger, by platform, and by week tells you more than a single aggregate number. If a change to your onboarding flow quietly moved your "ask" trigger earlier and your iOS rating started drifting down a month later, you want to be able to see that connection instead of guessing at it after the fact. That tracking, paired with staying on top of the replies once reviews land, is most of what our App Store and Google Play review management guide walks through in more depth — and it's worth pairing with a clear process for how you respond to app store reviews once the new ones start coming in, since a higher volume of reviews is only a win if someone's actually answering them. How many times can the App Store review prompt appear to one user? Apple's StoreKit API limits how often the system will actually display the native rating dialog to a given user within a rolling period, and the exact figure has changed over past OS releases . Your code can call the API more often than that, but iOS simply won't show the sheet past its own cap — so there's no benefit to calling it aggressively, only a cost if it means you're calling it at bad moments instead of good ones. Can I only ask users who seem happy in my app? No — not if "ask" means routing them differently into the store's rating flow based on a sentiment check you ran first. Both Apple's and Google's developer policies prohibit that kind of selective prompting, and the FTC treats it as a form of review manipulation when it results in a skewed public rating. Every user who reaches your chosen trigger moment should see the same native prompt, regardless of any in-app signal about how they feel. Does triggering the native prompt guarantee a review gets posted? No. Both StoreKit and the In-App Review API let the operating system decide whether to display the dialog at all, and even when it displays, the user can rate, dismiss, or ignore it with no feedback to your app about which happened. That's intentional — it's part of what keeps developers from gaming the system — so plan your review strategy around giving people good moments to ask, not around a guaranteed conversion rate. Every review from the App Store, Google Play, G2 and Capterra in one inbox → Try Tailwind free. Tailwind runs $5 a month per tool, or $50 a month for the Full plan covering every tool, with the first month free and no card required to start.