react-native-webrtc: WebRTC for React Native, Without the WebView
The WebRTC module for React Native
At a glance
- What is it?
- react-native-webrtc binds the Jitsi WebRTC build to React Native's native layers so audio, video, data channels and screen capture work on Android, iOS and tvOS. It is MIT licensed, Unified Plan only, and not usable in Expo Go.
- Who is it for?
- Adopt react-native-webrtc if you are building a React Native app that needs real peer connections, data channels or screen capture on Android, iOS or tvOS, and you are willing to follow the per-platform installation guides and keep the native build in a development client. Do not adopt it if you need Plan B, react-native-windows, or a drop-in Expo Go experience, and do not expect macOS support to return without someone contributing it.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 20 days ago.
- What is it written in?
- Mainly Java, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 30, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The gap react-native-webrtc fills between JavaScript and the native WebRTC stack
React Native has no browser RTCPeerConnection. There is no getUserMedia, no RTCPeerConnection, no RTCDataChannel in the JavaScript runtime that ships with the framework. A React Native app that needs a peer connection therefore has two options: run the WebRTC stack inside a WebView and bridge messages across, or bind the platform's native WebRTC implementation into the JavaScript layer. react-native-webrtc takes the second route. It is, in the README's own words, "a WebRTC module for React Native", and the package is published on npm under the name react-native-webrtc.
The audience is narrow and specific. This is for teams already committed to React Native who need live audio, live video, data channels or screen capture inside the app rather than in a browser tab. It is not a signalling server, it is not a TURN service, and it does not give you a backend. The README links a Call Guide and an Improving Call Reliability document, which tells you the maintainers expect you to bring your own signalling and your own network topology. If you have never written a signalling exchange, this module gives you the media engine and nothing else.
The package's own metadata is modest: two runtime dependencies (base64-js pinned at 1.5.1 and debug pinned at 4.3.4) and a peer dependency on react-native >=0.60.0. The weight is not in the JavaScript. It is in the native binaries, which is why the installation story is platform by platform rather than a single npm command.
How the module maps the WebRTC API onto Android, iOS and tvOS
The repository layout shows the split clearly. There is an android/ directory, an ios/ directory, an apple/ directory shared between the Apple targets, a macos/ directory, a src/ directory holding the TypeScript surface, and a react-native-webrtc.podspec at the root for CocoaPods integration. The package.json points the react-native field at src/index.ts and the types field at lib/typescript/index.d.ts, so consumers get typed bindings rather than an untyped bridge.
The underlying engine is not written by this project. The README states the currently used revision is M124, linked to the jitsi/webrtc fork. That matters for two reasons. First, the version numbering of the npm package tracks the upstream WebRTC milestone: the recent releases are 124.0.8, 124.0.7 and 124.0.6, all on the 124 line. Second, bug fixes for codec behaviour, ICE, or DTLS generally arrive by moving that upstream revision, not by patching this repository alone. When you file an issue about media behaviour, the useful question is which M revision you are on.
Architecture support is enumerated in the README. Android builds for armeabi-v7a, arm64-v8a, x86 and x86_64. iOS builds for arm64 and x86_64. tvOS builds for arm64. macOS lists arm64 and x86_64 in the supported-architectures list, but the feature table marks the macOS column with an asterisk and the note says macOS is not actively supported at this time, with support possibly returning in the future. Read those two statements together and the macOS column is best treated as buildable but not promised.
The feature table is the honest part of the documentation. Audio/Video, Data Channels, Screen Capture, Unified Plan and Simulcast are checked for Android, iOS and Web. tvOS gets Audio/Video only: no data channels, no screen capture, no simulcast. Plan B is unchecked across every column. The Web column depends on a separate project, react-native-webrtc-web-shim, which the README describes as providing a shim for react-native-web so that almost the same code runs there, with a link to that shim's own setup notes for the exceptions.
Installing react-native-webrtc and making a first getUserMedia call
Installation starts with a package manager. The README lists npm, yarn and pnpm as the preferred methods and warns that you still need to follow the platform guides for extra required steps.
npm install react-native-webrtc --saveor, if your project uses yarn:
yarn add react-native-webrtcDo not stop there. The README links three separate installation documents: Documentation/AndroidInstallation.md, Documentation/iOSInstallation.md and Documentation/tvOSInstallation.md. These cover the native configuration the package manager cannot do for you. The podspec at the repository root is what CocoaPods consumes on the Apple side.
For a first real use, the README points at Documentation/BasicUsage.md and the examples/ directory, which contains GumTestApp and GumTestApp_macOS. The README's Basic Usage guide is where the capture call itself is documented; read it before writing your own, because the exact import and call shape is defined there rather than in the README body.
What you should see once capture is wired up is a live camera preview on device. If the capture call rejects, the cause is almost always a missing platform permission declared during the Android or iOS installation steps rather than a JavaScript error, so check the platform guide before filing an issue.
The README's Examples section is candid that the bundled projects are "very basic" and that a broader example with a backend included is planned rather than shipped. Plan accordingly: the examples demonstrate capture and rendering, not a complete call flow. For the call flow itself, the Call Guide is the document to read.
Expo users need a different path. The README states that because the module includes native code it is not available in the Expo Go app by default, and that you can get things working through the expo-dev-client library plus the out-of-tree config-plugins/react-native-webrtc package. That is a development-build workflow, not a managed-workflow one.
Where react-native-webrtc is the wrong choice
The most concrete limitation is Plan B. The README states that as of version 106.0.0, Unified Plan is the only supported mode, and that anyone still needing Plan B must use an older release. If your signalling server or your SFU still negotiates Plan B semantics, this module will not meet you halfway. You either migrate the signalling side or you pin an old release and accept that you are outside the supported configuration.
Platform coverage is the second boundary. The README says react-native-windows is not supported at this time and asks whether anyone is interested in getting it started, which is an invitation to contribute rather than a roadmap. macOS is marked as not actively supported. tvOS loses data channels, screen capture and simulcast. If your product needs a desktop Windows client or a data channel on Apple TV, this package does not cover it and the documentation does not pretend otherwise.
Expo Go is the third. A team that has standardized on managed Expo and cannot move to a development client will not be able to use this module at all, because the native code has no place to live in the Expo Go binary.
The fourth limitation is structural rather than documented. Because the engine tracks an upstream Jitsi WebRTC revision, the project's ability to fix a media-layer bug quickly depends on that upstream. The README does not document a rollback procedure, and it does not describe a support window for older M lines beyond the note about Plan B. Teams that need a long-term supported media stack with a contractual upgrade path should recognize that this is a community module maintained in the open, with a Discourse forum as its stated community venue.
react-native-webrtc compared with the react-native-webrtc-web-shim route
The most useful alternative to consider is not a different peer-connection library but a different deployment target. The README points to react-native-webrtc-web-shim, a sibling project in the same GitHub organization, which provides a shim for react-native-web. The stated benefit is that you can use almost the exact same code in a react-native-web project as you would with react-native directly, and the shim's own setup page documents the exceptions.
The difference in approach is where the WebRTC engine runs. With react-native-webrtc on a device, the peer connection lives in the platform's native WebRTC build, which is why the feature table can check screen capture and simulcast on Android and iOS. With the web shim, the code runs against the browser's own WebRTC implementation through react-native-web. That means the browser's codec and API support becomes your constraint, and the native installation guides stop applying. It also means you inherit browser behaviour for permissions and capture, which is a different set of failure modes from the Android and iOS permission model.
Choosing between them is a question about your product, not about API quality. If you need a native mobile app with camera capture and screen sharing on Android and iOS, the shim does not help you. If you need one codebase that also runs in a browser and you can accept the browser's WebRTC stack, the shim removes the native build step entirely. The README presents the shim as complementary to this package, not as a replacement, and the feature table's Web column is checked precisely because of it.
Licence, maintenance and what an upgrade actually costs
The package is MIT licensed, both in the repository's LICENSE file and in the package.json license field. MIT is permissive: it allows commercial use, modification and redistribution provided the copyright notice and permission notice are retained. This is not legal advice, and the practical question for a shipping product is whether the native binaries you bundle carry any additional notices. The repository does not state that they do, but the README does not address the topic either, so a team with a compliance process should inspect the native artifacts rather than assume the root LICENSE covers everything.
On maintenance, the last push to the default branch was on 2026-09-10, and the most recent release listed is 124.0.8 from 2026-07-21. The repository is not archived. That combination indicates a project that is being touched, though the README itself does not publish a release cadence or a support policy.
Upgrade cost is where the version scheme deserves attention. The package version tracks the upstream WebRTC milestone, so moving from 124.x to a later line is not a patch bump in the usual sense: it moves the media engine underneath you. The README's note that Unified Plan became the only supported mode at version 106.0.0 is the precedent. A change of that kind arrives as a version number, not as a deprecation warning, and it can break a working signalling implementation. Treat every milestone-line upgrade as a native-level change that needs a full call test on both Android and iOS, and read the release notes for the specific version before you bump the dependency. The README does not document a rollback path, so your own lockfile is the rollback mechanism.
Editorial conclusion
Adopt react-native-webrtc if you are building a React Native app that needs real peer connections, data channels or screen capture on Android, iOS or tvOS, and you are willing to follow the per-platform installation guides and keep the native build in a development client. Do not adopt it if you need Plan B, react-native-windows, or a drop-in Expo Go experience, and do not expect macOS support to return without someone contributing it. Before you commit, verify three things in your own tree: that your react-native version satisfies the >=0.60.0 peer dependency, that your Expo setup uses expo-dev-client plus the out-of-tree config-plugins/react-native-webrtc package, and that your signalling layer is already Unified Plan compatible, because the README states Unified Plan became the only supported mode as of version 106.0.0.
Frequently asked questions
What is react-native-webrtc?
It is a WebRTC module for React Native, published on npm as react-native-webrtc, that exposes audio and video capture, peer connections, data channels and screen capture inside a React Native app. The README states it uses the Jitsi WebRTC fork at revision M124.
Is WebRTC frontend or backend?
The README does not classify it that way. react-native-webrtc is a client-side module that provides the media engine inside a React Native app; the README links a Call Guide and an Improving Call Reliability document, which implies signalling and network infrastructure sit outside this package.
Is WebRTC free or paid?
react-native-webrtc itself is MIT licensed, as stated in the LICENSE file and the package.json license field. The README does not discuss any paid tier or hosted service for this module.
Is React Native still relevant in 2026?
The README does not address React Native's overall relevance. What it does state is that this module requires react-native >=0.60.0 as a peer dependency and that the last push to the default branch was on 2026-09-10.
Is Netflix using React Native?
The README does not mention Netflix or any other company using this module. It lists the react-native-webrtc organization's related packages and a Discourse community as the places to look for community discussion.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/react-native-webrtc-react-native-webrtc)