Shared screens
Screens, state and calls to your server, written once in JavaScript with React and shared by the iPhone and Android apps.
React Native app development company in India
One React Native codebase for iPhone and Android — and we write the native side too.
A React Native app is JavaScript running inside an iOS app and an Android app. The screens are written once for both. Some features can only be written on the native side, in each platform's own code. We write both sides, and we draw the line between them using reactnative.dev's own guides.
- We write both sides: React and native
- Native modules tested on real devices
- We reply within one working day.
- Native Platform guide
- Turbo Native Modules guide
- About the New Architecture
- React Native 0.82 release post
- Headless JS guide
In brief
- What it is
- React Native app development for iOS and Android. We write the screens once in JavaScript, and the native code some features need in each platform's own code.
- Why it matters
- Picking React Native decides the language of the screens, not which features need native code. Those features rarely appear in a list of screens, so they are easy to find too late.
- What you get
- A feature-by-feature list of what runs natively, a small typed contract for each native module, and both platforms built against it and tested on real devices.
What we build
Shared screens, plus the native code some features need.
Screens, state and server calls are written once, in JavaScript, for both platforms. The Native Platform guide on reactnative.dev names two kinds of native code past them. We write all three parts.
Native modules
Native code with no user interface, which JavaScript reaches as functions and objects. Background work, Bluetooth and a vendor's SDK (software development kit) are handled here.
Native components
Platform views, such as a map with live positions, that a React screen places like any other component. The view itself comes from iOS or Android.
Where this page starts. Whether React Native was the right choice over two native apps or Flutter is the question cross-platform app development takes up. This page assumes the choice is made and asks where the line runs through your app, one feature at a time.
For the rest of the build, from store release to the security review, see mobile app development. For each store's own rules, see iOS and Android app development. To keep a live app current, see app maintenance and support.
Where JavaScript stops
We list the native features before the build starts.
Native code covers whatever the app needs from the device that React Native and its libraries do not already provide. Choosing React Native settles what the screens are written in. It does not settle which features need native code.
That list belongs in the plan beside the screens. A feature missing from it still ends up native, just discovered late. So we go through your app one feature at a time and agree where the line runs.
What puts code on the native side anyway
None of these shows up in a list of screens.
- Work with the app closed. Whatever the operating system wakes an app for starts natively. The Headless JS guide on reactnative.dev, which covers running a JavaScript task in the background, sits with the Android guides. Even there, a native service has to start the task, and the task may not touch the user interface.
- A vendor SDK with no JavaScript. When a vendor's payment, identity or accessory SDK comes only as iOS and Android libraries, the app needs a native module around it, unless a maintained wrapper exists. Either way, that code goes inside your app.
- A library left on the old architecture. React Native 0.82 made the New Architecture the only option, says its release post on reactnative.dev, with 0.81 the last version allowing the Legacy Architecture. A library that never moved leans on interop (compatibility) layers until it is ported or replaced.
Feature by feature
Where the parts of familiar features sit.
Hardware and system screens stay native, and plain data crosses the line between native code and JavaScript.
| Feature | Native side | What crosses the line |
|---|---|---|
| A map with live positions | The map view, as a native component | Positions to the map, marker taps back |
| A Bluetooth accessory | Scanning, connecting, staying connected | Devices found, connection state, readings |
| Biometric sign-in | The system prompt and the stored key | Yes or no, and why it failed |
| Push notifications | Device registration and message delivery | The token, and the message a tap opened |
| Sharing out of the app | The system share sheet | The text or file being shared |
How calls cross the line since the New Architecture
On reactnative.dev, the page About the New Architecture says the asynchronous bridge between JavaScript and native code is gone. In its place is the JavaScript Interface, JSI, which lets JavaScript hold a reference to a C++ object and call its methods directly, with no serialization cost (data no longer has to be converted into messages to cross).
Faster crossings do not change what should cross. That is still decided feature by feature, and written into a small contract for each native module.
How we build a native module
The spec comes first, and real devices have the last word.
The New Architecture made calls between JavaScript and native code cheaper. A small written contract, the spec, is what keeps two platforms answering alike.
List what the platform provides
The API the feature calls, the permission it asks for, whether it must work with the app closed, and any vendor SDK involved.
Write the spec first
The guide to Turbo Native Modules on reactnative.dev starts from a spec in TypeScript or Flow, declaring the methods and data types that pass between the two sides. Codegen, React Native's code generator, turns it into interfaces the native code implements.
Build Android and iOS against it
Both answer the same calls with the same types, so no screen asks which platform it is on. The Android half is Kotlin, held to the rules of any native Android app.
Run it on real devices
On both platforms, through the failures a demo skips: hardware switched off, the network gone, and the app closed halfway through a task.
FAQ
Questions about React Native builds.
Native code, vendor SDKs, background work, upgrades and new platform features. For anything else, ask us directly.
Whatever the app needs from the device that React Native and its libraries do not already provide. The Native Platform guide on reactnative.dev divides that code into native modules, which have no user interface, and native components, which bring platform views into a React screen. Background work, vendor SDK wrappers and new platform APIs all land there.
Yes, through a native module that wraps it. The guide to Turbo Native Modules on reactnative.dev builds one from a typed spec in TypeScript or Flow, which Codegen turns into interfaces for the Android and iOS code. JavaScript sees only what the spec declares, and when the vendor changes its SDK, the wrapper changes with it.
Yes, with native code at the start. The Headless JS guide on reactnative.dev, filed with its Android guides, runs a JavaScript task in the background once a native service starts it, and the task may not touch the UI. On either platform, the operating system wakes native code first, and JavaScript runs only if handed the work.
It is the redesigned core of React Native. According to the page About the New Architecture on reactnative.dev, it replaces the asynchronous bridge with JSI, which lets JavaScript hold a reference to a C++ object and call its methods without serialization costs. React Native 0.82 made it the only architecture, its release post says, with 0.81 the last version allowing the old one.
Yes. A takeover starts with a short assessment of the codebase and its dependencies, and in a React Native app that includes the native side: libraries built only for the Legacy Architecture, native modules written in-house, and what each asks of an upgrade. That is where upgrading React Native stops being a version number and becomes native work.
Yes, through native code, once the API exists in the platform's own SDK. No community library can wrap an API before it ships, so a new capability means a native module of the app's own. If only one platform has it, the plan also has to say what the other platform's screen does instead.
Let's talk
Which of your features are native?
Send the feature list, including anything that touches hardware, runs in the background or needs a vendor's SDK. Project work is delivered remotely from India during business hours. We reply within one working day.