Native Module Integration
React Native covers most app requirements through the JavaScript ecosystem – but some features require deep access to native platform APIs that no ready-made package provides.
Native Modules Beyond the JS Ecosystem
A native module in Swift, Kotlin or Objective-C closes that gap and plugs into your React Native app through a shared JavaScript API, giving you access to the device capability you need without giving up cross-platform advantages.
The essentials of Native Module Integration
- A native module in Swift, Kotlin or Objective-C closes the gap no ready-made package covers – plugged in through a shared JavaScript API.
- Before any native code is written, the first check is always whether a maintained open-source package meets the requirement – custom modules are a last resort.
- Depending on the call pattern, the choice falls on the classic bridge or on the synchronous, type-safe turbo module of the new architecture.
- iOS is implemented in Swift and Android in Kotlin, both speaking through an interface typed in TypeScript that hides the platform differences.
- The error case has to be handled cleanly – missing hardware, denied permission, SDK errors – because these paths decide the robustness of the module.
When Native Modules?
Native modules are needed when no maintained package exists, a specific hardware feature is required (special Bluetooth profiles, proprietary SDKs), or existing native libraries must be embedded in the React Native app. The first step is always to check whether a ready-made package suffices, before any native code is written at all.
Turbo Modules
The new React Native Architecture uses Turbo Modules for significantly more performant native bridge communication. If your project runs on the new architecture, the Turbo Module is the right route – it allows synchronous calls and type-safe interfaces between JavaScript and native code.
iOS and Android
A native module needs its own implementation per platform: Swift or Objective-C for iOS, Kotlin or Java for Android. The JavaScript API is identical on both platforms; the implementation underneath is platform-specific. This keeps your React Native code platform-agnostic.
Testing and Debugging
Native modules are particularly error-prone because they bridge the gap between JavaScript and native code. That is why unit tests for the native implementation and logging at the bridge boundary belong in scope from the start – otherwise exactly the problems that arise between the layers stay invisible.
Package-First Decision Process
Before a single line of native code is written, every requirement runs through this evaluation path. The effort of building a custom native module is only justified once all upstream options have truly been exhausted.
Ecosystem Check
Search for well-maintained open-source packages that already cover the requirement.
Package Assessment
Review active maintenance, OS compatibility and licence of any candidate.
Choose Module Type
Classic Bridge for infrequent calls, Turbo Module for frequent or latency-critical functions.
Platform Implementation
Swift on iOS, Kotlin on Android — both encapsulated behind a shared TypeScript API.
Error-Path Hardening
Handle missing hardware, denied permissions and SDK errors gracefully and explicitly.
Custom native modules are the last resort — not the first step.
Bridge vs. Turbo Module
The choice of communication architecture between JavaScript and native code directly affects latency, type safety and maintainability. Which model fits which use case?
| Classic Bridge | Turbo Module | |
|---|---|---|
| Call model | asynchronous | synchronous possible |
| Type safety | enforce manually | TypeScript-typed |
| Architecture | old architecture | new architecture (RN 0.68+) |
| Performance in critical path | ||
| Implementation effort | lower | higher |
| Recommended for | infrequent calls | frequent / latency-sensitive calls |
The wrong choice produces either unnecessary complexity or exactly the latency you were trying to avoid.
What matters for Native Module Integration
What matters first with native modules is the decision not to write them unless you must. A well-maintained open-source package is almost always the better choice than your own native code, because it is used by many and kept current with every OS update. We check the ecosystem first and recommend native code only when nothing there holds up.
If a custom module is needed, the choice between the classic bridge and a turbo module decides. For rarely called functions, a classic module is enough. If a native function is called often and on the critical path, the synchronous, type-safe turbo module of the new architecture pays off. The wrong choice creates either needless complexity or exactly the latency you wanted to avoid.
A good native module hides the platform differences behind a clean JavaScript API. iOS is implemented in Swift, Android in Kotlin, and both speak through an interface typed in TypeScript, so the app developer never needs to know what happens underneath. A leaky abstraction that lets native quirks show through into JavaScript is a future source of bugs.
And a native module is only finished once the error case is handled cleanly. What happens when the hardware is missing, the permission is denied, or the SDK throws an error? These paths decide robustness but are easily forgotten in a happy-path test.
Bridge vs. Turbo Module
Classic native modules communicate asynchronously over the JavaScript Bridge. Turbo Modules (new architecture) enable synchronous calls and type-safe interfaces – significantly more performant for frequently called native functions.
Swift, Kotlin, TypeScript
The iOS implementation is written in Swift, the Android implementation in Kotlin, and the JavaScript API in TypeScript. Each layer in the language optimised for it.
Package-First Approach
Before any native code is written, the first check is always whether a maintained open-source package meets the requirement. Custom native modules are a last resort, not a first step.
Native power where it counts
With us you're always one step ahead technologically and tap directly into our extensive app development expertise. We take a close look at your app idea, identify key success factors and create tailor-made applications. Your visions and goals are at the heart of our joint project work.
Expert knowledge in app technologies
React Native, native iOS and Android development: we pick the stack to fit your project, not our preference.
Comprehensive user experience know-how
Intuitive operation and seamless interactions decide ratings and how long users stay in the app.
Proven track record
Published apps in the App Store and Play Store, from MVP to mature platform.
Versatile team
Concept, design, development and backend come together in one team that works without interface friction.
Long-term partnerships
We stay after launch and keep evolving your app with maintenance and updates.
READY FOR YOUR APP THAT SETS NEW STANDARDS?
Related articles from our blog
Flutter vs React Native 2026: The ultimate comparison for developers, CTOs and decision-makers
Flutter or React Native - which framework will win in 2026? 12,500 words, 32 chapters, 25 criteria weighted, 40 FAQs, side-by-side code, case studies from BMW, Shopify, Discord. The definitive German-language guide for decision-makers, CTOs and developers.
MedusaJS: What the headless commerce framework 2026 can really do
MedusaJS crops up in almost every composable commerce discussion. But what is the framework really suitable for - and what is it not? A neutral overview of the architecture, workflow engine, TCO and realistic entry paths for decision-makers in the e-commerce SME sector.
Angular vs React vs Vue: Which frontend framework suits your shop?
Angular, React or Vue for your shop? A practical comparison for e-commerce and headless shopware with a clear recommendation based on team, SEO and setup.
Frequently asked questions