Skip to main content
Ask users to rate your app using the operating system’s own star prompt, presented as a sheet inside your app so the session is never interrupted and nothing navigates away. The prompt is drawn, rate-limited, and dismissed entirely by the OS, which means a rating costs the user a single tap. For users who want to leave written feedback instead, a separate variant opens the store’s review composer for your listing.
The operating system decides whether the native prompt actually appears. It is capped to a small number of displays per user per year and is silently suppressed once that budget is spent. Treat the call as a request, not a guarantee, and never block a flow or show a confirmation on the assumption that the user saw it.

Installation


How it works

rateapp:// is fire and forget. There is no return value and no callback, so the call resolves immediately whether or not the OS chose to render anything. The host portion of the URL selects which of the two behaviours you want.
The store URL behind rateapp://review resolves to your own listing automatically from the build configuration, so there is no parameter to pass and no ID to hardcode.

Ask for a rating after a positive moment

The native prompt performs best when it lands immediately after a user has finished something they wanted to finish, and worst when it interrupts them mid-task. Fire it at the end of a successful flow, once the confirming UI is already on screen.
Because the OS silently swallows the request once the yearly budget is spent, calling it on every single completion is wasteful rather than harmful. Track your own counter and only spend the request on users who have already shown positive engagement, for example a third completed order or a seventh session, so the limited number of displays goes to the people most likely to leave a high rating.

Open the review composer for written feedback

rateapp://review is the only variant that leaves your app. It opens the store listing with the write-review composer already focused, which is what you want behind an explicit “Write a review” button, never as an automatic prompt.
Users are sent to the store app and have to come back on their own, so save this for a settings screen or a feedback page where leaving is the expected outcome. If a user has just told you something is wrong, route them to your support form instead. Sending an unhappy user to the composer is the fastest way to collect a one star review.

Verify the prompt during development

Development builds installed straight from a debug run always render the prompt, with no rate limiting, so this is where you confirm your trigger logic fires at the right moment. Builds distributed through TestFlight behave differently: the request is accepted and then discarded without drawing anything, which looks identical to a broken integration.
A prompt that never appears in a TestFlight build is expected behaviour and not a bug. Verify the trigger with a log line or your analytics event, and confirm the prompt itself renders in a development build.

Resources

NPM Package

despia-native