react-native-in-app-review

react-native-in-app-review is a thin native-module bridge that lets a React Native app ask the user to rate it without leaving the app or opening a browser. On Android it calls into Google’s Play Core In-App Review API; on iOS it wraps Apple’s StoreKit SKStoreReviewController; on Huawei devices it drives the AppGallery in-app comment flow. The JS surface is deliberately small: RequestInAppReview() to launch the native prompt, requestInAppCommentAppGallery() for Huawei’s comment flow, and isAvailable() to check platform/OS-version support before calling either.

Because each platform’s review API is rate-limited and non-deterministic about whether a dialog actually appears, the library documents this behavior explicitly (its promises resolve on flow completion, not on whether a review was submitted) rather than pretending to guarantee a review was captured, and ships a Jest test suite that mocks the native modules to cover both the happy path and each platform’s documented error codes.

What You Get

• A single InAppReview class with three static methods: RequestInAppReview(), requestInAppCommentAppGallery(), and isAvailable()
• Autolinking support for React Native 0.60+ (no manual native project edits required on modern RN, CocoaPods podspec included for iOS)
• Platform-specific native modules already written: Java for Android (Play Core In-App Review), Swift/Obj-C for iOS (StoreKit), plus an HMS path for Huawei AppGallery
• A documented table of platform error codes (e.g. ERROR_DEVICE_VERSION, GOOGLE_SERVICES_NOT_AVAILABLE) so consuming apps can handle failures explicitly
• TypeScript ambient type declarations (index.d.ts) for the exported API

Common Use Cases

• Prompting users to rate an app in-context (e.g. after completing a key flow) without a webview or store redirect
• Gating the review prompt behind isAvailable() so unsupported OS versions or platforms are skipped safely
• Supporting Huawei AppGallery-distributed builds that can’t use Google Play’s review API
• Feeding review-flow completion (not review content) into an app’s own “ask me later” scheduling logic

Under The Hood

Architecture The library is a thin cross-platform bridge rather than a stateful component: index.js inspects Platform.OS, guards execution with isModuleAvailable() (which throws a clear “did you forget to link the library” error if the expected native module is missing), and delegates to one of two native modules — InAppReviewModule for Android, backed by Java code under android/src that calls Google’s Play Core In-App Review API and also exposes an HMS-specific showInAppCommentHMS() entry point for Huawei AppGallery, or RNInAppReviewIOS for iOS, a Swift class (RNInAppReviewIOS.swift) bridged to the RN runtime through an Objective-C bridging header wrapping SKStoreReviewController. There is no internal state, event emitter, or caching layer — every call is a direct pass-through to the platform API, so the entire “core abstraction” is really just the platform-branching in isModuleAvailable() plus the two native modules behind it.

Tech Stack The JS layer has no runtime dependencies beyond React Native’s own NativeModules/Platform APIs. Android is a Java module built via Gradle (android/build.gradle) against Google’s Play Core in-app-review library; iOS is Swift plus an Objective-C bridging header, packaged as a CocoaPods pod (react-native-in-app-review.podspec) for RN’s autolinking. Development tooling is Babel (with the Metro React Native preset) for transpilation, ESLint via @react-native-community/eslint-config for linting, Jest for testing, and Travis CI (.travis.yml) for running the test suite; a Husky pre-commit hook runs lint-staged plus test:ci before every commit.

Code Quality __tests__/InAppReview-test.js mocks both NativeModules and Platform to exercise every branch of the JS bridge: unsupported platforms, Android and iOS success paths, the Huawei AppGallery comment flow, and each documented native error code, so the thin JS layer is genuinely covered even though the native Java/Swift code underneath it is not unit-tested from this repo. There is no TypeScript source — index.d.ts is a small hand-written ambient declaration rather than a compiled artifact — so the JS itself has no static type checking, though ESLint and a pre-commit hook enforce consistent style. Error handling favors explicit thrown errors over silent failure (isModuleAvailable() throws rather than returning undefined).

API Design The public surface is intentionally minimal: three static methods, promise-based, requiring no configuration objects or setup beyond installing the package (and running pod install on iOS). isAvailable() gives callers a synchronous capability check before invoking the async review flow, and the README documents platform quirks clearly (the promise resolves on flow completion, not on whether a review was actually submitted, matching what the underlying platform APIs themselves guarantee). The main rough edge is the README’s promotion of a paid third-party registry (“PayDevs”) for “faster” updates alongside the normal public npm package, which is unusual friction in an otherwise simple integration.