Review Count Is Decided by When You Ask, Not the Wording — Rating Design for Rork Apps

Defining the "Moment of Delight"

You should ask right after a user has a good experience in the app. For a wallpaper app, the moment they "saved a wallpaper they liked" or "added a third favorite." For a task app, the moment they "completed a task."

The key is that the moment is the user's own achievement — not right after the app pushed something, but right after the user felt satisfied. Layer on "after a few uses, once they have come to like the app" rather than first use, and rating quality rises. My condition is "right after 3+ sessions and 2+ favorite saves."

expo-store-review and the Frequency Limit

Implementation uses expo-store-review. Because the native prompt is limited by iOS to three displays per year, always gate it with isAvailableAsync and your own conditions.

import * as StoreReview from "expo-store-review";
 
async function maybeAskForReview() {
  // Your own gate: narrow to users who felt value
  const sessions = await getSessionCount();
  const favorites = await getFavoriteCount();
  const alreadyAsked = await getReviewAskedThisVersion();
 
  if (sessions < 3 || favorites < 2 || alreadyAsked) return;
 
  if (await StoreReview.hasAction()) {
    await StoreReview.requestReview();
    await markReviewAskedThisVersion(); // once per version
  }
}

Since the iOS three-per-year cap is outside developer control, you cannot know whether the system will actually show the prompt. That is exactly why you narrow to "users who meet the conditions worth asking" and aim the scarce display slots at those most likely to rate well. Calling it carelessly on every action burns the annual budget without ever displaying.

The Satisfaction Check and Apple's Line

Asking "Do you like the app?" first, sending only the "yes" users to the native prompt and routing "no" users to a feedback form — this pre-check is widely used.

But the line matters. What Apple forbids is a homemade dialog that captures star input, or custom UI that substitutes for the native prompt. Asking satisfaction as an entrance to feedback is acceptable. I use "ask satisfaction → call requestReview only for satisfied users → route the dissatisfied to support." This lets me receive low-rating sentiment as improvement requests before it flows into public reviews.

What you must never do is an overt design that fully shuts dissatisfied users out of rating. Blatant funneling gets flagged in review, and more importantly, it is not honest. The satisfaction check is only for guiding users to the right exit.

Measuring the Effect

Measure by comparing the pace of review-count growth and the trajectory of the average rating, before and after the change. Record how daily new reviews shift starting the week you change timing, and the effect shows clearly.

On my wallpaper app, simply moving from a launch prompt to the "moment of delight" recovered the average by about 0.3 and clearly increased monthly new reviews. A number that would not move no matter how many times I rewrote the copy moved on timing design alone — still a telling lesson in hindsight.

You cannot buy reviews, but you can design the moment you ask. I hope this helps anyone else stuck on review count.