react-native-store-review asks for the app rating from inside your app

One native call wrapped for React Native

The whole point of this module is thin. It exposes the native APIs that ask the user to rate the app in the iOS App Store or Google Play Store from inside the app, and the JavaScript side is a single call:

import * as StoreReview from 'react-native-store-review';

StoreReview.requestReview();

Underneath it sits a native module for each platform, with ios/ and android/ directories in the repository, an RNStoreReview.podspec for CocoaPods and an RNStoreReview.xcodeproj for the iOS side. The package.json shows the modern React Native codegen configuration, with a spec named RNStoreReviewSpec and an Android java package name of com.oblador.storereview, so the bridge is generated rather than hand written.

Installation is three commands: add the dependency, link the iOS pod, and rebuild the native project.

yarn add react-native-store-review
pod install --project-directory=ios
react-native run-ios # or run-android

The platform requirements are stated plainly in the README: iOS 14.0 or later, or Android 5.0 with the Google Play Store installed. The underlying APIs are Apple's SKStoreReviewController and Google's In-App Review API, and the README links to both, so anyone extending the module has a reference for the platform contract rather than a black box.

Call it as a side effect, not as a button response

The README spends its most emphatic words on timing. The intention of the API is to ask the user to rate the app as part of the user journey, typically as the user completes a task. And because it is not possible to know whether a dialog will be shown, you should not call it as a result of tapping a button, but as a side effect of an event happening in the app.

That is a platform constraint, not a style preference. Apple and Google both rate-limit how often the request is honoured, so a user who taps a rate button and sees nothing has been told a lie by your interface. Triggering the request after a task completes means the dialog either appears at a moment the user can act on, or does not appear and costs the user nothing.

For a team shipping a review prompt, this is the single most important thing to get right, and it is also the easiest thing to get wrong, because the button pattern is what most apps implement.

The store link fallback for older devices and for the button case

Because the native API cannot be relied on to show anything, the module's own answer to a missing dialog is a button that opens the store listing instead. The README shows how to build that, using the platform app URLs:

import { Linking, Platform } from 'react-native';

const APP_STORE_LINK = `itms-apps://apps.apple.com/app/id${IOS_APP_ID}?action=write-review`;
const PLAY_STORE_LINK = `market://details?id=${ANDROID_APP_ID}`;

const STORE_LINK = Platform.select({
  ios: APP_STORE_LINK,
  android: PLAY_STORE_LINK,
});

export const openReviewInStore = () => Linking.openURL(STORE_LINK)

Two details are easy to miss. The iOS URL uses the itms-apps scheme rather than an https link, and the Android one uses the market scheme, so both open the store app directly rather than a web page. The second detail is that the iOS scheme needs a declaration, which is where the troubleshooting section comes in.

Note that the code as given expects IOS_APP_ID and ANDROID_APP_ID to exist in your project. The module does not define them, so they are constants you supply, and getting the App Store ID wrong is a silent failure that opens the wrong listing.

The iOS setup that makes the dialog appear at all

The troubleshooting section is the most useful part of the documentation, because the failure modes are quiet.

The first requirement is LSApplicationQueriesSchemes in Info.plist, as an array parameter, with itms-apps as one of its entries. The README shows the shape of the entry:

<key>LSApplicationQueriesSchemes</key>
<array>
  <string>itms-apps</string>
</array>

Without it, the app cannot query the App Store scheme, and the store link path is what breaks. The second case is different in kind: the dialog is not showing while testing with TestFlight, but works normally in production, and the README links a discussion of that behaviour. It also states that it will not work for enterprise apps, since those are not available on the App Store.

The last constraint in the same paragraph is the one that shapes product decisions. Apple and Google restrict the amount of times the API can be called to a few times per year, to prevent misuse. A request that works in development is not evidence that it works at any particular rate in production.

The iOS dialog language comes from the OS, not from your bundle

A separate troubleshooting entry covers a problem specific to iOS: the dialog does not appear in the expected language. The explanation is that the strings in the dialog come from the OS, so if your translations live purely in JavaScript, iOS does not know which languages you support and falls back.

The fix is to add metadata declaring supported languages and regions, following Apple's own documentation on adding support for languages and regions. In other words, the problem is not in the module and not in the store API. It is a native project configuration issue that a JavaScript-only team will not find on its own.

This is the kind of detail that makes the difference between a module that works and one that works in a specific app. The README does not enumerate the platform requirements for a store prompt the way an App Store review guide would, so expect to spend time in the platform documentation when a prompt misbehaves.

A small module whose latest release dates from April 2026

The repository is small and shaped like a native module rather than a framework: src/, ios/, android/, the podspec, the xcodeproj, an Example/ application with its own App.tsx, jest and metro configuration, and a yarn.lock. The Example directory is a full React Native app, which means the module ships with a runnable reference for how to wire it into a project.

The version record is worth noting. The most recent release is 0.5.0, published on 2026-04-15, with 0.4.3 and 0.4.2 both dated 2023-10-26 before it. The last push to the master branch was also on 2026-04-15. So the module is at version 0.5.0 and its development had been quiet for most of three years before that release.

The package.json also carries a version 0.5.0 entry, a test script that reports no test specified, and dev dependencies on React 19.2.3 and React Native 0.85.1, with yarn as the declared package manager. The licence is MIT, which is permissive enough to embed in a commercial app without ceremony. The practical upgrade cost of this library is the native layer, since a change in the platform API behaviour shows up as a native change rather than a JavaScript one.

Editorial conclusion

Use react-native-store-review when your React Native app should ask for a rating at a natural moment in the user journey and your minimum platforms are iOS 14 or Android 5 with Google Play installed, and treat the store fallback link as the primary path for older devices. Do not use it as the response to a support button, since the platform may show nothing at all, and do not rely on it to work in TestFlight or in enterprise builds. Before you ship, verify that your Info.plist carries LSApplicationQueriesSchemes with itms-apps for the store link, that your translations are declared so the iOS dialog uses the right language, and that you understand the last push was on 2026-04-15 with version 0.5.0, so a future change in the native layer means checking the repository rather than assuming the store APIs still behave the same.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. oblador/react-native-store-review on GitHub
4. README
5. Releases