react-native-webrtc: a Jitsi M155 fork under a 155.0.1 version, with the Plan B row of its own feature table crossed out

The release number is the WebRTC revision number

The versioning convention is the first thing to internalise, because it tells you where every other change comes from. The package version is 155.0.1 and the WebRTC revision in use is M155 from the Jitsi fork of libwebrtc, hosted at github.com/jitsi/webrtc. So the major component tracks the upstream Chromium derived revision, and the patch component tracks this module's own packaging. The release list shows the same shape three times: 155.0.0 dated 2026-10-14, 124.0.8 dated 2026-07-21, and 124.0.7 dated 2025-10-09. That is under three months between the two newest releases, with nine months between the older two. It also means a peer dependency bump in react-native can arrive on a different cadence than either, so a project that pins versions tightly will have three version axes to track instead of one.

Plan B is marked unsupported on every column, including the primary two

The feature table at the top of the README has six rows and seven platform columns, and one row is empty everywhere:

| | Android | iOS | tvOS | | :- | :-: | :-: | :-: | | Plan B | - | - | - | | Unified Plan* | check | check | - |

Every other row, audio and video, data channels, screen capture, Unified Plan and Simulcast, carries a mark on Android, iOS, Web and Expo, tvOS is marked only for audio and video, and the macOS and Windows columns carry a mark on nothing at all. Plan B being empty on Android and iOS is not a platform gap, it is a mode that no longer exists. The note below the table dates the change: as of version 106.0.0 Unified Plan is the only supported mode, and anyone still in need of Plan B needs an older release. That makes the version line a compatibility decision rather than a preference, since the last release that still supported Plan B is well behind the current 155.x line and behind it sit every other fix in this table.

Expo needs the dev client because the module ships native code

Expo is marked with an asterisk in the table, and the asterisk resolves to a structural fact: this module includes native code, so it is not available in the Expo Go app by default. The documented workaround is two pieces rather than one. You move off Expo Go onto the expo-dev-client library, and you add the out-of-tree config-plugins/react-native-webrtc package, which lives in the expo config-plugins repository rather than here. Both are needed, and neither is a change to this repository. The same asterisk appears on the macOS, Windows and Web columns, where the answer differs per platform. macOS gets a statement that it is not actively supported at this time and that support might return. Windows gets an explicit refusal of react-native-windows with an invitation to contribute. Web gets a separate shim project, react-native-webrtc-web-shim, which is described as letting you run almost the same code under react-native-web, and the word almost is the project's own hedge.

Native builds come from a podspec, a react-native.config.js and two metro configs

The install story is thin in the README and thick in the tree. Installation is a single package manager line, with npm, yarn and pnpm all offered, and the note tells you to follow the platform guides afterwards for the extra steps. Those steps live in a Documentation directory with separate files for Android, iOS and tvOS installation, plus basic usage, a step by step call guide, a reliability guide and a Unified Plan migration document hosted on Google Docs. The tree shows what a build actually touches: android/ and ios/ and apple/ for native code, macos/ present but unsupported, react-native-webrtc.podspec for the CocoaPods side, react-native.config.js for the React Native CLI, and two Metro bundler configs, metro.config.js and metro.config.macos.js, one of which exists only for the platform the README declines to support. The entry point is src/index.ts, with the compiled outputs landing in lib as commonjs, module and typescript builds, which is what react-native-builder-bob produces.

Two runtime dependencies, and a peer floor of react-native 0.60.0

The dependency list is unusually small. Two runtime dependencies: base64-js at 1.5.1 and debug at 4.3.4. The peer dependency is react-native at 0.60.0 or newer, which is the floor for the autolinking era. Everything heavy is native and arrives through the platform build rather than through npm. The development side is where the version numbers live, and they are old on purpose or at least visibly so: typescript 4.6.2, prettier 2.4.1, eslint 8.24.0, husky 7.0.2, react-native-builder-bob 0.18.2, with types for react-native pinned at 0.67.3 and for react at 17.0.40. So the toolchain builds against a 2021 era React Native while the runtime floor is declared as 0.60.0, and the type definitions describe an API surface from that generation. Lint is strict by configuration: `eslint --max-warnings 0`, meaning warnings fail the build, followed by `tsc --noEmit`, and lint-staged runs prettier over every staged file.

The architecture list covers Android and iOS but not Web or Expo

The supported architectures are given per platform, and the omission pattern matters more than the entries. Android builds for armeabi-v7a, arm64-v8a, x86 and x86_64. iOS builds for arm64 and x86_64. tvOS builds for arm64 only. macOS is listed with arm64 and x86_64 even though the README says macOS is not actively supported, so the build matrix is broader than the support statement. Web and Expo have no architecture line at all, which is consistent with the Web path being a shim in another repository and Expo being a native module that reuses the iOS and Android artifacts. Four Android ABIs is also a packaging decision with a cost: an app that ships this module bundles four native binaries unless it prunes them, and nothing in the README documents a per-ABI exclusion. That is a build size question to settle in your own project rather than a setting here.

Simulcast became easy at 111.0.0, and the examples are still very basic

Two smaller items round out the picture, both about what you get on arrival. Simulcast carries an asterisk and a date: as of version 111.0.0 it became possible with ease, because software encode and decode factories were enabled by default. That is a default change, not a new API, and it means a build below 111 behaves differently from a build above it when the factories are not enabled. The examples directory holds two entries and the README is candid about them, calling them very basic example projects and noting there are plans for a broader example with a backend included. So there is no reference implementation with a signalling server in this repository. Anything beyond a two peer loop has to be assembled from the call guide and the reliability guide, which is a deliberate trade for a module whose scope is the native transport rather than the application.

Editorial conclusion

Adopt this module if your product runs on Android or iOS and you have already decided on Unified Plan, because that is the configuration its own table marks as supported everywhere it supports anything. Check three things before you start. Plan B is gone as of version 106.0.0 and callers still needing it must pin an older release, so verify no dependency of yours assumes the old session negotiation. Expo Go will not load it because the module contains native code, and the documented route is expo-dev-client plus the out-of-tree config-plugins/react-native-webrtc package. And note what the release numbers mean: 155.0.1 tracks WebRTC revision M155 from the Jitsi fork, so a version bump upstream is a version bump here. The last push is dated 2026-10-20 and the newest release is 155.0.0 from 2026-10-14.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. react-native-webrtc/react-native-webrtc on GitHub
4. README
5. Releases