●CLOUD — Rork Max compiles native Swift on a fleet of cloud Macs, so you never download Xcode or need to own a Mac●PLATFORM — Rork Max targets iPhone, iPad, Apple Watch, and Vision Pro, and reaches games, widgets, and Live Activities●SHIP — Build in the browser, preview through a streaming simulator, install on device via QR code, and submit to the App Store without leaving Rork●SPLIT — Regular Rork generates cross-platform apps with React Native and Expo. Reach for it to ship broadly and fast, and for Max when you need Apple-specific depth●CREDIT — The free tier works out to roughly five prompts a week. It helps to budget the cost of trying something separately from the cost of finishing it●PRICE — Rork Max sits on the $200/month Max plan, while regular Rork starts free with paid plans from $25/month●CLOUD — Rork Max compiles native Swift on a fleet of cloud Macs, so you never download Xcode or need to own a Mac●PLATFORM — Rork Max targets iPhone, iPad, Apple Watch, and Vision Pro, and reaches games, widgets, and Live Activities●SHIP — Build in the browser, preview through a streaming simulator, install on device via QR code, and submit to the App Store without leaving Rork●SPLIT — Regular Rork generates cross-platform apps with React Native and Expo. Reach for it to ship broadly and fast, and for Max when you need Apple-specific depth●CREDIT — The free tier works out to roughly five prompts a week. It helps to budget the cost of trying something separately from the cost of finishing it●PRICE — Rork Max sits on the $200/month Max plan, while regular Rork starts free with paid plans from $25/month
Review Count Is Decided by When You Ask, Not the Wording — Rating Design for Rork Apps
When a Rork-built app's review count stalls, the cause is usually not the request wording but the moment you choose to ask. Here is the expo-store-review frequency limit and how to define the 'moment of delight' that earns ratings.
Shipping apps as an indie developer, there are stretches where downloads grow but the review count refuses to budge past two digits. I struggled with exactly this on a wallpaper app for a long time. The common response is to polish the "please review us" copy, but what actually moved the number was not the wording — it was changing the moment I asked.
A Rork-generated Expo app can add a rating request in a few lines. The question is when you call those lines. The native iOS review prompt has a hard cap on how often it appears, and asking carelessly wastes that precious opportunity. This article covers timing design for growing review count, including how it feeds ASO.
Why Review Count Feeds ASO
On an App Store search result or product page, a user has limited material to decide on installing: screenshots, the star rating, and the count.
The role of "count" is easily overlooked. At 4.8 stars with 5 ratings, a user suspects "maybe friends and family left those." At the same 4.8 with 500 ratings, it becomes proof of trust. Reviews drive conversion only when star height and count work together. Treat "raising stars" and "increasing count" as separate efforts — that is the starting point.
And count indirectly affects ranking itself. When post-install conversion and retention rise, ASO signals improve and exposure for the same keywords grows. Review count is the entrance to that loop.
Three Moments to Never Ask
First, eliminate the moments where you must not request a rating.
Right after launch. Ask a user who has felt no value yet and you get either a low rating or a dismissal.
Right after a crash or error. The worst timing, and it mass-produces one-star reviews.
Right after declining a purchase or right after showing an ad. Asking in a low mood backfires.
My first mistake was number one. While I prompted on launch, the average rating slowly declined. Simply changing the timing recovered the same app's average — that was what made me take this design seriously.
✦
Thank you for reading this far.
Continue Reading
What follows includes implementation code, benchmarks, and practical content we hope you'll find useful. This site runs without ads — server and development costs are supported entirely by members like you. If it's been helpful, we'd be truly grateful for your support.
WHAT YOU'LL LEARN
✦Understand concretely how review count drives ASO conversion along two axes: star rating and number of ratings
✦Given expo-store-review's three-prompts-per-year limit, concentrate the scarce display opportunity on the 'moment of delight'
✦Distinguish, as implementation patterns, the custom rating dialogs Apple forbids from the pre-prompt satisfaction check it allows
Secure payment via Stripe · Cancel anytime
✦
Unlock This Article
Get full access to the rest of this article. Buy once, read anytime. This site is ad-free — your support goes directly toward keeping it running.
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.
Share
Thank You for Reading
Rork Lab is ad-free, supported entirely by members like you. We publish practical guides daily with implementation code, benchmarks, and production-ready patterns. If you've found it useful, we'd love to have you on board.