# react-native-audio-api: a Web Audio style engine for React Native

> The library reimplements the Web Audio API model on top of native C++ audio, so a React Native app can build the same node graphs it would build in a browser. The gap between the web specification and the mobile implementation is where the real evaluation happens.

**software-mansion/react-native-audio-api** — High-performance audio engine for react-native

- Repository: https://github.com/software-mansion/react-native-audio-api
- Website: https://docs.swmansion.com/react-native-audio-api/
- Stars: 850 · Forks: 97
- Language: C++
- License: MIT
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/software-mansion-react-native-audio-api

## The Web Audio API is the model, and the gap is the product

react-native-audio-api describes itself as a system for controlling audio in a React Native environment that is compatible with the Web Audio API specification, so audio is generated and modified in the same way it is in a browser. That framing is the single most important fact about the project, because it gives you a mental model you already have, and it also defines the risk. Anything the web specification has and this engine does not will be a gap you discover at runtime rather than at design time. The project anticipates this directly: the README links a Web Audio API coverage page that documents how much of the specification is currently implemented. That is a more honest position than claiming parity, and it is the first document to read before committing, alongside the changelog linked as ghdocs/changelog.md. For teams with existing web audio code, the appeal is that a familiar graph of nodes, gains and connections can be ported to mobile rather than rewritten against a platform-specific API.

## A monorepo of packages, apps and native C++

The repository is a Yarn 4 monorepo, and its root package.json declares itself private with the name react-native-audio-api-monorepo. The workspace list names two publishable packages, packages/react-native-audio-api and packages/react-native-audio-worklets, plus packages/custom-node-generator and two applications, apps/common-app and apps/fabric-example. The C++ engine is the primary language of the codebase, and the tooling reflects it: the root scripts include validate:cpp, validate:cpp-extended, validate:cpp-full, validate:android, validate:ios and validate:full, each dispatching to scripts/validate.sh with a different scope. There is a dedicated setup:clangd script pointing at packages/react-native-audio-api/common/cpp/clangd/generate-and-copy.sh, which tells you the native sources are laid out under common/cpp and that an editor configuration step exists for clangd. The build script compiles the two package workspaces in order, and the clean script removes both android and ios build directories. Plan for a native build in your CI, not just a JavaScript install. The root scripts also give you graduated validation commands, so you can start with the fast pass and widen the scope as you go:

```bash
bash scripts/validate.sh --fast
bash scripts/validate.sh --cpp
bash scripts/validate.sh --android
bash scripts/validate.sh --ios
```

The full list also includes --cpp-extended, --cpp-full and --full, plus separate targets for typecheck, format:check and a check-audio-enum-sync script that runs packages/react-native-audio-api/scripts/check-enum-sync.sh, which suggests the native enum definitions and the JavaScript bindings are kept in step by a script rather than by hand.

## Audio worklets and custom processors move code onto the audio thread

Two roadmap entries mark the sharpest technical claims in the project. JS Audio Worklets V1, released in 0.9.0, receive events and data callbacks from the audio thread so you can synchronize with the UI thread. JS Audio Worklets V2, released in 0.10.0, let you customize the process pipeline with JavaScript functions that run on the audio thread. A Custom Audio Processor, released in 0.7.0, lets you write your own processing AudioNode, which is the lower level escape hatch when a built-in node does not fit. Put together, these three features are the reason to choose this engine rather than simply playing a sound file: real-time parameter updates, custom DSP written in JavaScript or native code, and a node graph you control. The trade-off is that code on the audio thread has a deadline it must meet, and the README does not document the callback budget, the thread priority or what happens when a user callback overruns. If you plan heavy processing in a worklet, that behaviour is worth testing on the slowest device you support.

## Decoding, recording and streaming, each with its own catch

The feature list is easier to read as a set of capabilities with a catch attached to each. Decoding support arrived in 0.8.0 for m4a, mp4, aac, ogg and opus, so those formats can be decoded into the graph. HLS streaming support landed in the same release, but it requires the optional FFmpeg build flag, documented on the prebuilt libraries support page, so it is not available in a default build. Microphone support in 0.7.0 lets you grab audio from the device microphone or a connected device, connect it to the graph, or stream it over the internet. Recording to file in 0.11.0 is described as fully customizable, with a choice of file format and quality, and recording rotation in 0.12.0 chunks recordings into smaller files for resilience. Note the asymmetry: playback and recording in the browser is simple, but here the permission and routing story is device-specific, and the README does not spell out per-platform microphone permission handling. A decoding utility module set was added in 0.10.0 so audio data can be handled without creating an AudioContext first.

## Notification controls, filters and an Audio tag for simple playback

Not every feature needs a graph. The Audio tag, released in 0.12.0, gives simple play and buffer behaviour with the commonly used functions, working the way the web element does and without building an audio graph by hand. A notification and lock screen control system from the same release lets you control playback and recording from the notification center and create custom notification layouts, which is a mobile concern with no direct web equivalent. The DSP side grew in 0.11.0 with a Wave Shaper Node for custom nonlinear distortion and an IIR Filter Node for digital filters built from feedforward and feedback coefficients. The Convolver Node, added in 0.10.0, applies impulse responses for realistic reverb and spatial effects. The project also publishes a coverage document for the Web Audio API, which is the practical way to check whether the specific node you need is implemented rather than scanning the changelog.

## Running the example app before you write your own graph

The README points to a runnable example rather than only to API reference, and that is the cheapest way to find out whether the engine behaves the way you need on a real device. The source for the example application is under the apps/common-app directory, and the README adds that if you want to play with the API but do not want to try it inside a real app, you can run the example project instead. Installation instructions for that project live in apps/fabric-example/README.md. The example app is a workspace member, so the root scripts operate on it as well. Once the workspace is set up, the package level commands are the ones the root scripts call:

```bash
yarn workspace react-native-audio-api run build
yarn workspace react-native-audio-worklets run build
yarn workspace react-native-audio-api run test
```

The test target is the one worth noting. The repository has a dedicated Audio Api tests workflow alongside the general CI workflow, and a separate check-audio-enum-sync script that compares enum definitions across the native and JavaScript layers. Neither tells you how those tests are structured, so the useful check is to look inside packages/react-native-audio-api once you clone the repository.

## Still missing: compressor, MIDI, spatial audio, noise cancellation

The Planned section of the roadmap lists four items, and they are informative precisely because they are missing. DynamicCompressorNode is planned, which would reduce loud sounds and boost quieter nodes to balance the signal and avoid clipping. MIDI support is planned as a complementary library rather than part of this package, intended to communicate with MIDI devices or read and write MIDI files, so the two would ship separately. Spatial Audio, described as manipulating audio in 3D space, is planned. Noise Cancellation is planned as system-based active noise and echo cancellation support. If your product depends on any of these, the current engine cannot serve it. The schedule is also unmarked, with the roadmap using a Coming_in-x.x.x badge, so there is no release any of them is committed to, and you should not build a delivery plan that assumes one lands on a particular date.

## MIT licence, a Webkit borrowing, and a busy release cadence

The library is licensed under the MIT License, but the licence section of the README adds two conditions that belong in any adoption decision. Some source code uses implementation copied directly from Webkit, so parts of the codebase carry upstream copyright, and the THIRD_PARTY.md file holds the details, with copyrights held by the respective organizations. Builds that opt into the FFmpeg link also pull in FFmpeg binaries, and those binaries carry their own licensing terms on top of the MIT grant. A directory named lgplv3 exists at the repository root, which suggests LGPL-licensed code is present, though the README does not map that directory to any component. If you are shipping a commercial app, read THIRD_PARTY.md and the FFmpeg build configuration before producing a release artefact, because a codec choice changes the obligations you take on. On maintenance, the repository is not archived and the last push was on 2026-10-19. The release history is busy: 0.13.4 on 2026-09-17, 0.13.5 on 2026-09-18 and 0.13.6 on 2026-09-23, three releases in a week, with a patch-level series still climbing under a version still below 1.0. Pin an exact version and read ghdocs/changelog.md before each upgrade.

## Conclusion

Adopt react-native-audio-api if your React Native app needs a real-time audio graph, custom processing on the audio thread, or microphone capture routed through native code, and if you can absorb the C++ build step and the FFmpeg flag for streaming formats. Do not adopt it as a drop-in replacement for the browser Web Audio API, because the project publishes a coverage document for that specification and the roadmap still lists planned nodes such as DynamicCompressorNode, MIDI support, spatial audio and noise cancellation. Before you commit, open the Web Audio API coverage page, check the AudioContext and node options you depend on, and confirm that the platform you ship on is covered by the CI workflows.

## FAQ

### What is react-native-audio-api?

It is an audio engine for React Native, written in C++, that provides a system for controlling audio in a way compatible with the Web Audio API specification. Audio can be generated and modified in a React Native app in the same way it can in a browser.

### How do I install react-native-audio-api?

The README does not give an install command itself and points to the Getting Started section of the project documentation at docs.swmansion.com/react-native-audio-api for detailed instructions. The published npm packages are react-native-audio-api and react-native-audio-worklets.

### Does react-native-audio-api support the full Web Audio API?

Not necessarily. The project publishes a Web Audio API coverage page documenting how much of the specification is currently implemented, and the roadmap still lists planned items such as DynamicCompressorNode, spatial audio, noise cancellation and MIDI support.

### What does react-native-audio-api need for HLS audio streaming?

HLS streaming support requires the optional FFmpeg build flag, which is described in the prebuilt libraries support documentation. Builds that opt into FFmpeg link FFmpeg binaries, and the licence section notes that some source code is copied directly from Webkit, with details in THIRD_PARTY.md.

## Sources

- [License: MIT](https://github.com/software-mansion/react-native-audio-api/blob/main/LICENSE)
- [Project website](https://docs.swmansion.com/react-native-audio-api/)
- [README](https://github.com/software-mansion/react-native-audio-api/blob/main/README.md)
- [Releases](https://github.com/software-mansion/react-native-audio-api/releases)
- [software-mansion/react-native-audio-api on GitHub](https://github.com/software-mansion/react-native-audio-api)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/software-mansion-react-native-audio-api