Is Review Gating (Asking Only Happy Users) Allowed?

No. Review gating — showing a preliminary question like "Enjoying the app?" and only sending the happy users to the store while routing everyone else to a private feedback form — is against the rules on both the App Store and Google Play. And on iOS it isn't even a rules question anymore: Apple's review API makes the classic gate technically impossible, because you no longer get to see the rating before it's submitted.

I'll be blunt, because gating is still the most common "growth hack" teams quietly ship. Your rating is recency-weighted and gates your install rate, so filtering out the one-stars sounds like free upside. It isn't. Below is what each store forbids, why Apple closed the loophole in code, and the compliant play that works better: prompt everyone at a good moment, then reply to the unhappy ones.

Review gating (also "review filtering" or a "sentiment gate") is any flow that decides who gets asked to leave a public store review based on how they're likely to rate you. The textbook version is a two-step popup: a custom screen asks "Are you enjoying MyApp?" Tap yes, you're sent to the store listing to rate; tap no, you're routed to a support form, somewhere private and off the public record.

The result is a lopsided sample: only your fans reach the star field, while frustrated users get funneled somewhere that never touches your public rating. It works mechanically, which is exactly why both stores banned it. A rating that only counts happy users isn't a rating; it's marketing, and the stores treat it as manipulation.

Yes, on both — but they enforce it differently, and the iOS side is the one that surprises people.

On the App Store, Apple's guidelines require the provided rating API rather than a custom prompt, and treat interfaces designed to manipulate reviews as grounds for rejection. The key detail: Apple didn't just write a rule, it removed the tool you'd need to break it. Since iOS 10.3, the only sanctioned in-app rating prompt is `SKStoreReviewController` (now `requestReview`). You call it, the system shows a standardized rating sheet on its own schedule, the user rates inside it, and you never learn what they picked. No score to read, no low rating to intercept. The gate has nowhere to attach.

On Google Play, the ban is spelled out plainly in the In-App Review API policy. Google says you must not filter or pre-screen users before the review flow (no "do you love our app?" gate) and must not take any action based on whether the user completed it or the score they gave. Same intent as Apple, stated as a flat prohibition.

It's not villainy, it's math. Google moved to a recency-weighted rating average at I/O 2019, so a bad week hurts more than an old one, and pushing fresh five-stars feels like the fastest lever. The stakes are real: Apptentive has reported that moving from a 3-star to a 4-star average can lift conversion by roughly 89%. When a fraction of a star swings your install rate that hard, stacking the deck starts to look tempting.

But gating solves the wrong half of the equation. A one-star you hid is still a churned, angry user; you've suppressed the signal, not the cause. The compliant path happens to be the one that improves the number you care about. See [how your app star rating is calculated](/blog/how-is-your-app-star-rating-calculated); the gate never touches the input that matters.

You don't need the gate. You need two things the stores fully allow: ask everyone at the right moment, and answer the unhappy reviews you get. The timing half has its own craft, covered in [in-app review prompt best practices](/blog/in-app-review-prompt-best-practices); here's the whole compliant playbook.

Step 4 is where the data turns against gating. Google said at I/O 2019 that developers who respond see an average lift of about 0.7 stars, and a study of over four million reviews by Hassan et al. found users roughly six times more likely to raise their rating after a reply (4.4% versus 0.7%). You can't legally hide the one-star, but you can answer it and watch a meaningful share become three- and four-stars, in public where it compounds. The full tactical version is in [how to respond to negative app reviews](/blog/how-to-respond-to-negative-app-reviews).

That reply is public — the next reader sees a live bug handled honestly, not a wall of unanswered one-stars. Replying is fully within policy: a first-party developer response is a sanctioned feature on both stores, unlike a sentiment gate, and letting a tool draft those replies doesn't cross any line either, which we covered in [is AI review reply against App Store policy](/blog/is-ai-review-reply-against-app-store-policy).

Prompting everyone is a one-time code change. Replying to every review that lands, in the reviewer's own language, sized to each store's limit, week after week — that's the part that quietly stops happening. Google Play caps developer replies at a hard 350 characters; Apple publishes no official limit (community testing suggests a few thousand). By hand across two stores, it lapses during the busy weeks when a bad build is generating the most one-stars.

This is the slice [ReplyArgus](/features) is built for. It watches your Apple App Store and Google Play reviews in one inbox and drafts a grounded, on-brand reply to every written review in the reviewer's own language (100+ supported), sized to each store's limit, from your past approved replies. You approve in a click, or opt into rule-based auto-publish for the clean cases by rating, keyword, or language. It never gates or filters a prompt; it just makes sure the compliant path, answering people, actually happens at volume.

So the verdict stands: review gating isn't allowed, and on iOS it isn't even buildable. The compliant path is also the higher-performing one: prompt everyone honestly, then answer the people who weren't happy. [Start free with ReplyArgus](/signup) (no card) and Argus drafts your first reply to a real one-star in minutes, so the honest way to lift your rating is the one that actually gets done.