When to Use Native Modules in a React Native App

Use a native module in a React Native app when a feature needs something the JavaScript layer cannot reach directly: low-level Bluetooth and hardware control, augmented reality, heavy graphics or games, advanced camera and sensor work, or platform-specific performance tuning. For everything else, React Native handles it from one codebase. The trick is knowing where that line sits so you write native Swift or Kotlin only where it earns its keep. The State of React Native 2025 survey by Software Mansion gathered 3,501 developer responses and put new-architecture adoption at 80 percent, a sign the framework is mature enough to be the default and native code is the exception, not the rule. If you are worried about painting yourself into a corner, this guide gives you a clear decision framework.

Key Takeaways

• React Native covers the large majority of app features from one JavaScript and TypeScript codebase; you drop to native only for specific hardware, graphics, or performance needs.
• A native module is a small bridge that lets your React Native app call platform code written in Swift (iOS) or Kotlin (Android).
• Reach for native modules for low-level Bluetooth and hardware, augmented reality, high-frame-rate graphics and games, advanced camera and sensor work, and millisecond-level performance.
• Many native needs are already solved by mature open-source React Native libraries, so check before you build a custom bridge.
• You can mix a mostly React Native app with one or two native modules, keeping cross-platform speed where it counts and native power where you need it.

What a Native Module Actually Is

React Native runs your app’s logic in JavaScript and renders real native user-interface components underneath. Most of the time, that is all you need. But your phone has capabilities the JavaScript layer does not expose on its own, like a specific Bluetooth profile, a camera feature, or a graphics pipeline. A native module is the bridge that connects the two: a thin piece of Swift or Kotlin that does the platform-specific work and hands the result back to your JavaScript code through a defined interface.

In practice, you write a small native class that exposes methods and data types, then call those methods from React Native as if they were ordinary JavaScript functions. The React Native runtime marshals the call across the boundary, the native code executes, and the response comes back to your app. Under React Native’s New Architecture, this happens through Turbo Native Modules and a tool called Codegen, which reads a TypeScript specification and generates the type-safe glue for both platforms. The official React Native Turbo Native Modules documentation walks through the mechanics if your engineers want the deep version.

How Bridging Works, in Plain Terms

Picture your app as two rooms connected by a doorway. One room is JavaScript, where your screens, navigation, and business logic live. The other is native, where the operating system and the device hardware live. The native module is the doorway. When your JavaScript needs something only the native room can provide, it sends a request through the doorway, the native code does the work, and it passes the answer back.

The older React Native architecture used an asynchronous bridge that serialized every message as it crossed. The New Architecture replaced that with the JavaScript Interface (JSI), Turbo Native Modules, and the Fabric renderer, which let JavaScript call native code far more directly and synchronously when needed. The practical result is lower latency and faster startup, which matters most for exactly the hardware- and performance-heavy features that push you toward native code in the first place. You define the contract once in TypeScript, Codegen generates the Swift and Kotlin scaffolding, and you fill in the platform logic.

The Honest Default: Don’t Write Native Code You Don’t Need

Every native module you add is code you have to maintain twice, once for iOS and once for Android, plus the bridge between them. That is real long-term cost. So the discipline is simple: stay in React Native by default, and only open the doorway to native when a feature genuinely requires it. Before writing a custom bridge, check whether a well-maintained open-source library already solves your problem, because the React Native ecosystem has mature packages for camera, Bluetooth, maps, payments, biometrics, and much more. A great deal of “we need native” turns out to be “we need the right library.”

At Chop Dawg, we treat React Native as the starting point for nearly every cross-platform product and reach for native Swift or Kotlin only where a specific requirement forces our hand. Our app development and programming team is United States-led, with senior American engineering leads plus in-house developers in Pakistan and India and an in-house Brazilian design team. We size that decision feature by feature, so you are not paying for two codebases on screens a single codebase handles just as well. You can read more about why this is our foundation in why we build with React Native.

React Native Handles This / Drop to Native for This

React Native handles this	Drop to native for this
Standard screens, navigation, lists, and forms	Custom, high-frame-rate graphics, 3D scenes, and games
Common camera capture and photo selection (via mature libraries)	Advanced camera pipelines: real-time computer vision, custom frame processing, depth and LiDAR
Standard Bluetooth Low Energy via established libraries	Low-level or proprietary Bluetooth profiles, tight pairing and firmware control, specialized hardware
Maps, geolocation, and push notifications	Augmented reality using ARKit (iOS) or ARCore (Android)
Payments, authentication, biometrics, and analytics	Heavy on-device machine learning and custom sensor fusion (accelerometer, gyroscope, motion)
Most business logic and application programming interface (API) calls	Millisecond-level, performance-critical processing where every frame counts
The overwhelming majority of consumer, marketplace, social, and business apps	The one or two features that genuinely need the metal underneath

The Five Situations That Justify Going Native

1. Bluetooth and Hardware Integration

If your product talks to a physical device, you are often in native territory, especially for custom or low-level Bluetooth profiles, tight firmware control, or specialized peripherals. This is exactly the kind of work where the doorway to native pays off. When we partnered on Aurio, a real-time infant monitoring product, the companion app maintained a reliable Bluetooth connection to baby-safe sensor hardware, logged data on-device when out of range, and synced automatically on reconnection. That blend of hardware, connectivity, and resilience is a textbook case for native-level access wrapped in an otherwise approachable cross-platform app.

2. Augmented Reality

Augmented reality leans directly on the platform frameworks, ARKit on iOS and ARCore on Android. These are deep, fast-moving native systems for plane detection, world tracking, and rendering virtual objects into the camera feed. There is no meaningful way to do serious augmented reality without touching native code, so an AR feature is a clear signal to plan for native modules or a native-heavy implementation from the start.

3. Heavy Graphics or Games

If your app renders complex, high-frame-rate visuals, a 3D environment, or game-style interactions, the JavaScript layer is the wrong place for that hot loop. Native graphics pipelines using Metal on iOS or the equivalent on Android give you the throughput and control that demanding visuals require. You can still build the menus, accounts, and social features in React Native and reserve native for the rendering-intensive core.

4. Advanced Camera and Sensor Work

Basic photo capture is well served by existing React Native libraries. But real-time computer vision, custom frame-by-frame processing, depth sensing, and tight sensor fusion across the accelerometer, gyroscope, and motion coprocessor are different beasts. When you need to process the camera stream as it arrives or combine multiple sensors with low latency, native code is the right tool because it sits closest to the hardware and avoids round trips across the bridge.

5. Platform-Specific Performance

For the small set of features where every millisecond and every frame matters, native code removes the abstraction layer entirely. This is rarely the whole app; it is usually one demanding component. The pattern we favor is a mostly React Native app with a focused native module for the performance-critical piece, so you keep cross-platform speed and maintainability everywhere else. Our proven process identifies these hotspots during planning, before they become surprises in development.

Frequently Asked Questions

Can a React Native app use native code at all?

Yes. React Native is designed to interoperate with native Swift and Kotlin through native modules. You build the bulk of the app in JavaScript and TypeScript, then add small native modules for the specific features that need direct hardware or platform access. This lets one app combine cross-platform speed with native power exactly where it is required.

Does adding a native module mean I lose the cross-platform benefit?

No. A native module is a targeted addition, not a rewrite. The rest of your app stays in shared React Native code that runs on both iOS and Android. You only maintain separate Swift and Kotlin for the bridged feature itself, so you keep most of the cost and timeline advantages of a single codebase while unlocking the one capability you needed.

How do I know if I need a custom native module or an existing library?

Check the React Native ecosystem first. Mature, well-maintained libraries already cover camera, Bluetooth Low Energy, maps, payments, and biometrics. Build a custom native module only when no reliable library exists or when your requirement is genuinely specialized, such as a proprietary Bluetooth profile or real-time computer vision. A short technical discovery usually answers this quickly.

What changed with React Native’s New Architecture?

The New Architecture replaced the old asynchronous bridge with the JavaScript Interface, Turbo Native Modules, and the Fabric renderer. The result is more direct communication between JavaScript and native code, lower latency, and faster startup. For hardware- and performance-heavy features, those are exactly the improvements that matter, and Codegen generates type-safe glue from a TypeScript specification.

Is native code more expensive to maintain?

Generally yes, because native modules mean maintaining Swift for iOS and Kotlin for Android plus the bridge between them. That is why the smart approach is to stay in React Native by default and add native modules only where a feature truly requires it. Spending native effort selectively keeps your long-term maintenance cost and team size down.

Should the whole app be native if one feature needs it?

Almost never. One demanding feature, such as augmented reality or heavy graphics, does not justify rebuilding everything natively. The common and cost-effective pattern is a mostly React Native app with a focused native module for the intensive part. You reserve native effort for the component that needs it and keep cross-platform efficiency across the rest of the product.

Build Cross-Platform First, Native Where It Counts

The smartest mobile architecture in 2026 is not “all React Native” or “all native.” It is React Native by default, with native modules placed surgically where hardware, graphics, augmented reality, advanced sensors, or raw performance demand it. Get that balance right and you ship faster, spend less, and still deliver experiences that feel native to the device. Since 2009, Chop Dawg has planned and built more than 500 products used by over a billion people, on a foundation of React Native plus native Swift and Kotlin, and you own all of your code and intellectual property. We work as a partner, not an agency, on fixed monthly budgets with transparent pricing, and we have earned 300-plus five-star reviews across trusted directories like Clutch, GoodFirms, G2, Google, and TopDevelopers by being straight with the teams we build for. Whether you are a founder scoping a new cross-platform build or an established team deciding whether to add a native module to an app you already ship, book your free 45-minute consultation and we will map the architecture with you, no obligation.