react-native-agora wraps Agora's RTC video SDKs for React Native on Android and iOS

An engine object, not a component tree

The API shape is the first thing to understand, and it differs from what a React developer might expect. You do not render anything. You call createAgoraRtcEngine to get an engine object, and you initialise that engine with your app ID. From there the engine is the object your code talks to, and the calls it exposes are the channel and media operations of the Agora RTC Video SDK. The README gives the TypeScript form with a named import and the JavaScript form with a require, and the difference between them is only how the factory is pulled in. The underlying native layer is the same Agora Video SDK for Android and iOS, which is what the repository description means by React Native around the Agora RTC SDKs. The consequence for an application is that the engine has a lifecycle that your component code has to manage, join and leave channels explicitly, and release when the app is done, rather than a set of props that drive a mounted component.

Installing means adding the package and running pod install

The installation path is short, and it has one platform-specific step that catches people. The package is added with yarn or npm, and the version line in the documentation points at react-native-agora ^4.0.0 for projects on React Native 0.60.0 or newer. After that you go into the ios folder and run pod install, which is what pulls the native framework into the Xcode project.

yarn add react-native-agora

npm i --save react-native-agora

pod install

The pod step is the reason the package is a native module rather than a pure JavaScript dependency, and it is also the step that fails in some setups, which is why the troubleshooting section exists. The repository ships two example applications, one under examples/expo and one under examples/legacy, and the package scripts wire them as workspaces, with an example script pointing at react-native-agora-example-expo and a legacy script at react-native-agora-example-legacy. That pairing is worth noting because it tells you which React Native generations the binding is expected to work across.

The libcrypto.a conflict comes from Flipper, not from Agora

The most common install failure on iOS is a CocoaPods error about conflicting library names, libcrypto.a. The documented fix is not to change anything about Agora but to disable Flipper, which is in the Podfile, and to comment out the Flipper related code in AppDelegate. The Podfile block the documentation shows is the one that enables Flipper and installs the Flipper pods in a post_install hook. This is a fairly old dependency conflict surfacing in a modern build, and the workaround in the README is oriented at projects on React Native 0.62.0 or newer. It is a good illustration of what using a vendor binding means in practice: a failure in your iOS build is often a conflict between the native dependencies Agora pulls in and the debug tooling React Native itself installs, and the fix lives in the Podfile rather than in the SDK.

Screen sharing drags in a media projection permission you may not want

The second documented iOS and Android build issue is more than a warning. If your app does not use the screen sharing feature, the documentation says you should exclude the Screen Sharing extension at the project level in build.gradle, using a configurations.configureEach block that excludes the io.agora.rtc module named full-screen-sharing. The reason is stated plainly in the heading: the extension requires the FOREGROUND_SERVICE_MEDIA_PROJECTION permission, which on Android is a user-visible capture permission tied to screen recording. Excluding the module keeps a permission your app never asked for out of the manifest, and the block also shows the signingConfigs and compileOptions sections of the same project-level file. The general rule this illustrates is worth carrying to other SDKs: a native module can add permissions to your manifest whether or not your code calls it, so the manifest is something to check after every dependency upgrade.

Two old React Native bugs in the troubleshooting list

The rest of the troubleshooting entries are historical, and reading them tells you how long this binding has spanned React Native versions. One is a set of RCT_EXTERN_MODULE Swift modules broken in Xcode 10.2, where the error is that Swift class extensions and categories on Swift classes are not allowed to have +load methods, and the note says it was fixed in React Native 0.59.3. The other is an XCode 11 beta app launch crash, an exception thrown while invoking getCurrentAppState on the AppState target with an index out of bounds, which the documentation says was fixed in React Native 0.59.9. Both are linked to the upstream React Native issues so you can read the original discussion. They are worth keeping in mind for a specific reason. They document the floor of the ecosystem this binding was built for, and if you are on a modern React Native, the entries are noise, but if you are reading this to decide whether the library has kept up, the fact that the newest releases in 2026 are 4.6.4 and a build of it is a weaker signal than the presence of these old entries.

GitHub issues are no longer a support channel

The first note in the README is the one that changes how you should work with this repository. Agora states that to provide better and higher quality technical support services, it will no longer provide technical support through GitHub issues, and points users to Agora Support for help. The Resources section still links to filing file bugs about this sample on GitHub, so both statements sit in the same document, and the honest reading is that the tracker is for defects in the sample while product support goes through the vendor. For an open source project, that is a meaningful change in the support model, and it is a reason to evaluate the commercial relationship with Agora as carefully as the code. The project is MIT licensed, and the changelog lives in the repository as CHANGELOG.md, while longer release notes are published on the Agora developer site for React Native.

How this differs from calling the native SDKs directly

The alternative for a React Native team is to skip the binding and talk to the Agora native SDKs yourself through your own native module, or to use a cross platform toolkit that wraps several RTC vendors behind one interface. The difference in approach is what the binding actually costs you. Writing your own native module means you own the bridge, the thread handling, the event delivery and the release of native resources, on both Android and iOS, and you inherit that forever. The binding moves that work to Agora and gives you an engine object in JavaScript, at the price of being pinned to the surface Agora chose to expose. The cross platform toolkit approach is different again, since it hides one vendor behind an abstraction, which is worth it when you expect to switch vendors and not worth it when you have already decided on Agora, since the abstraction then only adds indirection. The binding also comes with a history that matters for trust, since the community developer Syanbo built the 1.0 version from 2016 to 2017 and Agora later reached official cooperation with him and now maintains the project.

Editorial conclusion

Mobile teams that already use Agora for real-time video and need the same RTC engine on Android and iOS from a React Native codebase are the people this binding serves, and the fact that Agora now maintains it officially, after a community developer built the 1.0 version between 2016 and 2017, is what makes it a reasonable dependency. It is the wrong choice for a greenfield project that has not yet picked a video vendor, since the API is locked to the Agora Video 4.x surface and the previous generation lives on a separate 3.x branch, and it is the wrong choice for a team that expects to file bugs in a public tracker, because support is handled through Agora Support and the maintainers state they no longer provide technical support through GitHub issues. Check three things before you commit: that your project is on React Native 0.60 or newer, that you can run pod install for the iOS side, and that the troubleshooting entries you are likely to hit are covered, since the Pod install conflict with libcrypto.a, the Xcode 10.2 module breakage and the screen sharing permission all have documented workarounds. The licence is MIT, the newest tag is v4.6.4-build.1 from 2026-10-16, and the last push was on the same day.

Frequently asked questions

Official sources

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