in_app_review — 3 shots a year, and Apple will never tell you anything

Your app asks the user for a rating. Apple will show it 3 times a year at most. And will never tell you whether it did.

The in_app_review plugin on the Flutter side, SKStoreReviewController.requestReview underneath. Probably the most used API in the world for collecting ratings, and probably the most misunderstood.

What requestReview actually does

requestReview() does not show a prompt. It asks iOS to show one. That nuance changes everything:

• 3 displays maximum per 365-day period, per app and per device. The window belongs to the OS, not to your release cadence: shipping more often does not reset the counter. Beyond that, the call is silently ignored.
• Zero developer feedback. The Future completes whether the prompt was displayed or not. No callback, no boolean, nothing. You will never know if the user saw anything, let alone whether they rated.
• The final decision belongs to the OS: quota already spent, user having disabled requests in Settings, moment judged inappropriate.

Direct consequence: every call placed at a bad moment (at startup, after a crash, in the middle of a checkout) can burn one of your 3 yearly shots on an annoyed user.

final inAppReview = InAppReview.instance;
if (await inAppReview.isAvailable()) {
  // This potentially CONSUMES 1 of your 3 yearly displays.
  await inAppReview.requestReview();
  // And you will never know whether anything happened.
}

Not to be confused with the other path: openStoreListing() (or the ?action=write-review deep link) opens the store rating page, no quota and no OS decision involved. That is the right tool for a "Rate us" button in settings: the user who taps it is a volunteer. requestReview() stays reserved for spontaneous prompts, the 3 shots.

The right reflex: trigger only after a proven moment of value (order delivered, goal reached, third successful session), and track your calls in analytics to estimate quota consumption yourself.

The twist: the guideline everyone cites is wrong

While preparing this post, I asked an AI which Apple guideline forbids review gating (filtering happy users before asking for a rating). Confident answer: "guideline 1.1.7".

Checking the App Store Review Guidelines, the primary document: 1.1.7 is not about that. The relevant rule is 5.6.1, in the Developer Code of Conduct, which covers review manipulation.

Second check, second surprise: I found no documented rejection for review gating alone. Developers have been doing it openly for years. The rule exists, the risk is real on paper, but the public case law is empty.

Two AI claims, two errors, caught only by opening the source document. For a topic as widely covered as rating prompts, the noise ratio of secondary sources (and of the models trained on them) is remarkable.

Takeaways

• requestReview = 3 displays max per 365 days per device, final call belongs to the OS, zero feedback.
• Place your triggers after moments of value, and track them: it is your only way to estimate the quota.
• Review gating falls under guideline 5.6.1 (not 1.1.7), and no public rejection documents it.
• For store rules, read the primary document. Summaries, human or AI, are confidently wrong.

Have you checked where your app spends its 3 yearly shots?