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
- Bundle
- CDN
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.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.
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.Resources
NPM Package
despia-native