Building a custom native module

WHAT THIS TESTS Whether you understand the structure of a native module: writing platform code, exposing it asynchronously across the bridge, registering it, and consuming it from JavaScript.

A GOOD ANSWER COVERS You implement the module twice, once per platform. On Android you create a class extending ReactContextBaseJavaModule, give it a name via getName, and annotate methods with ReactMethod; you register it through a ReactPackage added to the app's package list. On iOS you create a class with the RCT_EXPORT_MODULE macro and expose methods with RCT_EXPORT_METHOD in Objective-C, or use the appropriate bridging setup for Swift. Because the bridge is asynchronous, exported methods cannot return values directly; you pass results back through a promise (resolve and reject blocks) or callbacks, and for continuous data you emit events via an event emitter that JS subscribes to. You map types carefully, since only bridge-serializable types cross. On the JS side you access the module through NativeModules.YourModule and wrap it in a friendly JS API. With the new architecture you would instead define a Turbo Native Module with a typed spec and codegen, but the conceptual steps mirror the legacy bridge.

COMMON WRONG ANSWERS Forgetting to register the module in a ReactPackage or via the export macro, so JS sees undefined. Expecting an exported method to return a value synchronously across the asynchronous bridge. Not handling threading, running heavy native work on the main thread. Passing non-serializable types. Ignoring events for streaming data and trying to poll.

LIKELY FOLLOW-UPS How do promises versus callbacks versus events differ here, what changes under the new architecture with Turbo Modules and JSI, how do you handle threading with getMethodQueue, and how do you type the JS API.

ONE CONCRETE EXAMPLE For a hardware SDK that reads a sensor: on Android a ReactContextBaseJavaModule exposes a ReactMethod readSensor(promise) that calls the vendor SDK and resolves the promise with the value; on iOS an equivalent RCT_EXPORT_METHOD does the same with resolve and reject. Both register through their package or macro. In JS you import NativeModules.SensorModule and call await SensorModule.readSensor(), and for live readings you subscribe to a 'sensorUpdate' event from the module's emitter.