Our blog
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.
How to Respond to App Store Reviews: Examples for Bugs Crashes Pricing and Feature Requests
To respond to App Store reviews, reply through App Store Connect or Google Play Console (or a connected tool) with a short, specific message that names the exact issue, states the app version where it's fixed if one exists, and avoids asking directly for a rating change — the goal is a public record that reassures the next reader, not a negotiation with the one who wrote it. Where the reply actually happens Apple developers reply to App Store reviews through App Store Connect, either in the dashboard or via the App Store Connect API for teams that want to draft and publish replies programmatically. Google Play developers do the same through Play Console's Reply to Reviews tool. In both cases, the reply posts publicly underneath the original review, and it's visible to anyone browsing the listing — not just the person who wrote it. Tailwind can bring reviews from both stores into one inbox so you're not switching between two dashboards to see what needs an answer , and draft a reply in your brand's voice that a team member approves before it goes out. For mobile apps and SaaS teams specifically, the goal is to reply to App Store reviews in your voice consistently, not just quickly — the drafting happens faster with a tool, but the judgment about what to say, version numbers, tone, how much to admit, is still worth getting right regardless of what you use to send it. What makes a reply actually land A few things separate a reply that works from one that reads as noise: Name the specific issue, not a category. "Sorry for the inconvenience" could apply to anything. "This was a sync bug affecting accounts created after the v4.2 update" tells a skimming reader you know exactly what happened. Cite the version where it's fixed, if one exists. A reviewer stuck on an old build and a new visitor reading the thread both get something useful from "fixed in v4.5, released in March." Keep it short. Two or three sentences outperforms a paragraph. Nobody reading a store listing wants to scroll through a developer's defense. Don't ask for a rating change directly. Both platforms restrict replies that look like they're pressuring or incentivizing a rating edit. "We've fixed this in the latest update" is fine. "Please update your rating now that it's fixed" pushes into territory both stores' policies are written to discourage. Templates by situation These aren't meant to be copied word for word — a review response generator can produce a first draft faster than starting from a blank box, but every reply should still get edited to match what actually happened with that specific user's report. A crash or bug after an update "Thanks for flagging this — this matches a crash we've traced to the v6.1 release on devices running iOS 17.1. A fix is in v6.2, which should already be rolling out to you. If it's still crashing after updating, reply here with your device model and we'll dig in further." The structure to copy, not the wording: acknowledge, name the version and condition, point to the fix, leave a door open if the fix didn't land for them. A subscription or billing complaint "We hear you — unexpected charges are the worst kind of surprise. If this was a renewal you didn't expect, refunds for app purchases go through Apple directly since all billing runs through the App Store, but reach out to us at [support email] and we'll help you sort out the subscription settings so this doesn't happen again." Billing disputes on iOS and Android route through the platform's own refund process, not through the developer directly, so the reply's job is to point the person toward the right place and fix whatever setting or communication gap caused the confusion — not to promise a refund you can't issue from your own dashboard. A device- or OS-specific bug "Thanks for the detailed report. This looks specific to the Pixel 6a on Android 14 — we haven't been able to reproduce it on other devices yet, but we're actively looking into it. If you're open to it, email us at [support email] with a screen recording and we'll prioritize this." When a complaint is clearly tied to one device or OS version rather than a general quality problem, say so. It tells other readers with different devices that this isn't necessarily their experience too, and it moves the actual debugging to a channel where you can get more detail than a star rating allows. A feature request mistaken for a complaint Sometimes a one-star review isn't really about a bug — it's a user who wanted a feature the app doesn't have yet and rated it like a failure instead of a gap. "Thanks for the suggestion — dark mode isn't in the app yet, but it's a request we've heard before and it's on our list. We'll update this if it ships." This kind of reply does two things: it doesn't argue that the missing feature isn't a real complaint, and it signals to anyone else reading that the team is listening, even without a fix date. A one-star from a misunderstanding, like the refund policy "Sorry this wasn't clear up front — subscriptions through the App Store are billed and refunded directly by Apple rather than by us, so the fastest way to get a refund is through your Apple ID purchase history. Happy to help if you run into any trouble finding that." Reviews like this are common and easy to get defensive about, since the complaint is really about store policy rather than your app. A calm, factual pointer to the right process reads better to other shoppers than a reply that sounds like it's arguing the user is wrong to be upset. Does the reviewer get notified, and can they change their rating? On both the App Store and Google Play, a reviewer gets a notification when a developer replies to their review, and they're able to go back and edit their rating or review text afterward. That's part of why a specific, version-dated reply is worth the extra sentence it takes to write — the person who left a one-star review for a bug that's now fixed has a direct, visible invitation to revisit it, without you ever having to ask them outright to change the number. Should I reply to every single App Store review, including the five-star ones? Replying to negative and mixed reviews matters most, since that's where a reply can actually change how the next reader interprets the complaint. Replying to glowing five-star reviews is optional and lower-priority — a short thank-you doesn't hurt, but it's reasonable to spend your limited reply time on the reviews that are actually shaping how new visitors read your rating. What if a review is fake, abusive, or violates store policy? Both Apple and Google have separate reporting flows for reviews that violate their content policies — spam, harassment, reviews from someone who clearly never used the app. That's a different track from a normal reply: report it through the platform's own flagging tool rather than trying to argue it down in a public reply, which rarely works and can make the thread look worse to other readers. Can I ask the reviewer to update their rating after I fix the bug? You can invite it gently — "if you get a chance to try the latest version, we'd love to hear if this is resolved" is fine — but both platforms restrict anything that reads as pressure or a condition tied to changing a rating. Keep it an open invitation, not a request tied to the reply itself, and let the version-and-fix information in your reply do most of the persuading. For the other half of this — getting more reviews in the first place with native prompts that don't rely on gating — see our guide on how to get more app reviews, and for the bigger picture across both stores plus your B2B review sites, our App Store review management guide covers the full workflow. 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.
Subscribe to our newsletter
We send helpful materials once a month, along with information about discounts and special offers. No daily spam
We use your email only to send this newsletter. You can unsubscribe at any time from the link in every email. See our Privacy Policy.
How to unsubscribe from the mailing list?