react-native-get-random-values

react-native-get-random-values is a small native module that polyfills the Web Crypto API’s crypto.getRandomValues() method for React Native applications. Many popular npm packages, most notably uuid, assume crypto.getRandomValues is available globally, which it normally is in browsers and Node.js but not in the React Native JavaScript runtime. This library patches that gap by exposing a cryptographically secure random number source through native iOS and Android modules, backed by SecRandomCopyBytes on iOS and Java’s SecureRandom on Android.

The package requires no configuration beyond a single import at the top of the app’s entry file. It is implemented as a TurboModule with a codegen-generated spec, so it integrates directly with React Native’s New Architecture, and it gracefully degrades with an insecure Math.random-based fallback (plus a console warning) when running inside Chrome’s remote debugger, where synchronous native calls are not supported.

What You Get

• A single-import polyfill that installs global.crypto.getRandomValues for the whole app
• Native secure random number generation backed by SecRandomCopyBytes on iOS and SecureRandom on Android
• TurboModule/codegen support for React Native’s New Architecture
• Automatic deference to Expo SDK 48+‘s built-in ExpoCrypto.getRandomValues when available
• A safe fallback to Math.random with a console warning when running under Chrome remote debugging

Common Use Cases

• Generating UUIDs in a React Native app with the uuid package, which requires crypto.getRandomValues
• Implementing client-side token or nonce generation for authentication flows
• Polyfilling crypto APIs so libraries built for browsers or Node.js work unmodified in React Native
• Supporting cryptographic operations in wallet, security, or encryption-focused mobile apps

Under The Hood

Architecture The library is a single-purpose native module with a flat, minimal structure rather than layered internals: index.js patches global.crypto.getRandomValues at import time, delegating byte generation to platform-native code reached through React Native’s TurboModuleRegistry (spec/NativeRNGetRandomValues.ts defines the codegen contract, consumed by ios/RNGetRandomValues.mm via JSI and android/src/main/java/org/linusu/RNGetRandomValuesModule.java via the ReactModule bridge). index.web.js is a no-op override for web builds, relying on React Native’s platform-specific file resolution rather than runtime branching. There is no dependency injection or internal layering; the entire module is a thin bridge between a JS-facing polyfill and two native random-byte generators, so the only thing that could meaningfully break downstream consumers is a change to the global.crypto.getRandomValues contract itself.

Tech Stack The JS layer is plain CommonJS with no build step, distributed as-is via npm. Native integration uses Objective-C++ (RNGetRandomValues.mm) implementing a JSI TurboModule on iOS via SecRandomCopyBytes, and Java (RNGetRandomValuesModule.java, RNGetRandomValuesPackage.java) using BaseReactPackage and SecureRandom on Android. The only runtime dependency is fast-base64-decode, used to move random bytes across the bridge as base64 and decode them directly into the caller’s typed array; react-native itself (>=0.81, i.e. New Architecture) is a peer dependency. Distribution uses a CocoaPods podspec for iOS and a Gradle build.gradle for Android, both wired into React Native’s autolinking.

Code Quality No automated test suite, linter configuration, or CI workflow is present in the repository — the spec/ directory holds only the TurboModule’s TypeScript type contract, not test cases. Naming is consistent and the JS source carries JSDoc type annotations for its two exported functions, giving lightweight type-checking value without a full TypeScript build. Error handling is minimal but explicit (a TypeMismatchError and QuotaExceededError guard the two ways getRandomValues can be misused), and the isRemoteDebuggingInChrome check is a deliberate, if implicit, error-avoidance measure. The absence of any tests for a security-sensitive random-number path is the clearest quality gap.

API Design Developer experience is very strong for such a small package: consumers add a single side-effect import at the top of their entry file and every downstream library that expects the standard Web Crypto API works without further changes, mirroring web semantics exactly. The library actively detects and defers to Expo’s own crypto implementation when present rather than conflicting with it, and it fails safe (with a visible warning) rather than crashing under remote debugging. The tradeoff is minimal documentation: a single README covers install and usage with no separate API reference, changelog, or troubleshooting guide beyond what’s needed for this narrow use case.