react-native-nitro-sound: audio recording and playback without the bridge

The same library under a new name and a new bridge

react-native-nitro-sound is described as a React Native native module for audio recorder and player with NitroModules, and the README calls it a high-performance audio recording and playback library built with NitroModules.

The lineage matters. React Native Nitro Sound is the reborn version of React Native Audio Recorder Player, a library the README describes as having had 40k or more weekly downloads and 180k or more monthly downloads. The project restarted under a new name starting fresh with version 1.0.0, and the legacy package is still listed in the README with its own version and download badges.

The stated feature list is where the difference lies. Zero bridge overhead through direct native module access. Full type safety with TypeScript definitions generated from the native specs rather than hand-written. Synchronous methods where appropriate. Event listeners with type-safe event payloads. Cross-platform code generation, automatic for iOS in Swift and Android in Kotlin. Background processing, with recording operations now running in background threads to prevent UI blocking, which the documentation says requires loading state management. And web platform support through the Web Audio API and MediaRecorder API.

That background processing change is the one to weigh carefully, because it is a behavioural break rather than an internal detail. The README marks it as critical: recording operations now run in background threads, you MUST implement loading states to handle the async delays, or your UI may appear unresponsive.

A code generator is bundled, and the npm scripts show it: a nitrogen script that runs nitrogen and then a fix-nitrogen-swift.sh helper, and a prepare step that runs husky, then a version check script, then the build. The nitrogen/ directory in the repository holds the generated output.

The requirements list is where the friction is

The Requirements section is short and specific, and every line is a decision point.

React Native 0.79 or newer, with 0.86.2 stated as the repository's verified baseline. iOS deployment target 15.1 or newer, and Xcode 26.0 or newer required to compile the generated Swift and Nitrogen bindings reliably. Android with minSdk 24 or newer, JDK 17 recommended and compileSdk 36 recommended, and a note that RN 0.82 and above require Gradle 9.0 or later. The New Architecture is optional, since Nitro works on both old and new architecture, with the caveat that RN 0.82 and above is New Architecture only. Expo SDK 50 or newer for Expo users.

The Xcode requirement has its own callout, and the reason is specific enough to be useful. Earlier Apple toolchains can crash or emit function type mismatch, has_value errors while compiling generated Nitrogen bindings, with the issue referenced as number 718, and upgrade and cleanup steps are documented in the FAQ.

So the practical effect of the Swift 6 requirement is that a team on an older Xcode cannot build this library from source at all, since the failing step is the native compilation rather than a JavaScript resolution problem. There is no npm install that works around it.

The web target is a real third platform rather than a stub. The package exports map gives the browser condition its own entry point, ./lib/module/index.web.js, separate from the default ./lib/module/index.js, and the npm scripts include web, build:web, android and ios workspace tasks that run the example app on each target.

What is in the package, and what the repository carries

The package.json is where the architecture shows through. The package name is react-native-nitro-sound at version 0.2.20, marked type: ready in the badges, with the main entry at ./lib/module/index.js and types at ./lib/typescript/src/index.d.ts.

The exports map has a source condition pointing at ./src/index.tsx, so a consumer in a monorepo can resolve the TypeScript source directly, the react-native condition points at the same source, and the browser condition points at the separate web build. That last split is how the web implementation stays out of the native bundles.

The files array is unusually explicit about what ships. It includes src, lib, android, ios, cpp, nitrogen, nitro.json, the podspec and react-native.config.js, and then a list of negations excluding ios/build, android/build, android/gradle, the gradle wrapper files, android/local.properties, test directories, fixtures, mocks and dotfiles. Shipping the cpp directory alongside nitrogen tells you that the native side has both generated Nitrogen output and hand written C++ in the picture.

The repository root is broader than the package. Beyond src/ and the android/ and ios/ directories there is a knowledge/ directory, a docs/ directory with an FAQ, an e2e/ directory, a plugin/ directory, a scripts/ directory, nitrogen/, and a NitroSound.podspec. There is app.plugin.js, which is the Expo config plugin entry, and turbo.json for the build tooling.

The tooling choices are modern and specific. The package uses jest for tests, tsc for typecheck, eslint across js, ts and tsx, prettier as the style tool, husky for git hooks with a lefthook.yml also present, commitlint for commit message conventions, and a .yarn/ directory with .yarnrc.yml, which points at Yarn Berry rather than Yarn Classic. There is both an .eslintrc.js and an eslint.config.mjs, so the migration to flat config has started.

An AI-maintained repository with human direction

The README carries a notice that is unusual enough to quote directly in substance. The repository is now AI-native maintained, because the maintainer is juggling many open source repositories with very limited time, currently focused on another project, so day to day triage, bug fixes and dependency bumps are handled by Claude on his behalf.

Commits and pull requests labelled with an autogenerated by Claude marker are produced through the .claude/commands/ skills in the repository and the .github/workflows/ai-dispatch.yml workflow. The README asks that if you see something off with an AI-generated change you comment on the issue or pull request, and says the maintainer still reviews direction and humans are always welcome to send pull requests.

There is also a set of slash commands you can leave on an issue from the GitHub mobile app: /ai resolve-issue, /ai upgrade-deps, /ai compile-knowledge and /ai triage-all.

Whether this is a good thing depends on what you want from a dependency. The argument for it is that a library with one over-committed maintainer and a steady trickle of dependency bumps is a library that keeps working. The argument against it is that the human who understands the original design intent has less time to spend on it, and an AI-maintained native module is a place where a subtle regression in a background thread or an audio session handling path could take a while to notice.

The repository layout supports the workflow. There is an AGENTS.md for agents, a knowledge/ directory, an .ncurc.json for dependency update checks, and a CHANGELOG.md.

Where react-native-nitro-sound is the wrong tool

The honest limits are visible in the requirements and the breaking change notice.

The first is the platform floor, and it is high. React Native 0.79 minimum, iOS 15.1 minimum, Android minSdk 24, Xcode 26 required, and Gradle 9 for recent React Native. A team on React Native 0.73 with an older Xcode cannot use this, and there is no fallback path in the package, since the failing step is native compilation.

The second is the background thread change, which the README flags in red. Recording now runs off the UI thread and therefore completes asynchronously, so any UI that assumed a recording call returned when the recording was done now has to model a pending state. Migrating from the legacy package means auditing every call site that relied on the old synchronous behaviour, and the documentation is unusually blunt that skipping this leaves the UI appearing unresponsive.

The third is the scope of the library itself. It provides recorder and player functionality, and nothing else. There is no audio session category management, no interruption handling for a phone call, no background recording with a lock screen, no waveform rendering, no equaliser. For an app that needs to keep recording while the user puts the phone in their pocket and the screen locks, this is not the library for it, and the background threads in this library are about not blocking the UI, not about surviving suspension.

The alternatives differ in where the work happens. The legacy react-native-audio-recorder-player package still works and is what you would stay on if you need the old synchronous semantics and a stable, human-run maintenance model. For a project that needs a real audio pipeline, a native module of your own or a platform specific library gives you control over session categories and interruption handling at the cost of writing and maintaining that code. And for an app where audio is a secondary feature, recording on the web through MediaRecorder with a server side fallback avoids the native dependency entirely.

The honest summary is that react-native-nitro-sound is a good fit for a React Native app where audio is a first class feature and the team can meet the platform floor, and a poor fit for anything that needs to keep recording in the background or that cannot move to a recent React Native and Xcode.

Editorial conclusion

react-native-nitro-sound suits a React Native application that records or plays audio and wants the recorder and player to share one typed API across iOS, Android and the web, and that is willing to manage its own loading states because the native work runs off the UI thread. It does not suit an application that needs to record while the screen is closed and the app is suspended, and it is not a drop in replacement for the legacy package, since the background thread behaviour is a breaking change the documentation flags in bold. Before adopting it, confirm your Xcode version is 26.0 or newer, because earlier toolchains can fail compiling the generated Nitrogen bindings with a function type mismatch error, and plan the loading state handling the README says is mandatory.

Frequently asked questions

Official sources

1. hyochan/react-native-nitro-sound on GitHub
2. Issues
3. License: MIT
4. README
5. Releases