Building native modules for React Native

Rival compares React Native’s bridge with ways other frameworks connect JavaScript to native code. Messages between JavaScript and native code are asynchronous, and calls carry a module ID, method ID, and arguments. Common values such as numbers, strings, arrays, objects, and promises are supported.

For iOS, Rival describes adding an Objective-C file and exposing its module and methods with React Native macros. On Android, developers create a Java module and register its package in the application class. Both platforms require rebuilding the app, but a basic method can be called without much extra glue code.

Rival recommends keeping a blank React Native app in the module repository so developers can test the latest local version and contributors can check that it works. During development, console messages, Xcode and Android Studio debuggers, and native view inspectors help diagnose issues. RN Snoopy or `MessageQueue.spy` can reveal bridge traffic, while Instruments and Android Monitor help track memory use.

Rival says to handle native exceptions and watch for excessive bridge traffic, which can slow the app and contribute to flicker in highly interactive features. React Native Image Resizer keeps image contents off the bridge because they can weigh several megabytes; it uses file paths instead. Native memory tools can help identify resource problems, including those caused by large images.

Rival distinguishes breaking changes in a module from changes in React Native’s native interfaces. He recommends semantic versioning, with a major version increase for breaking changes, and mentions Commitizen as a way to track them. Changes such as iOS header path updates can require a new, incompatible module release.