What Is React Native? Building iOS and Android Apps from One Codebase

What is React Native and how does one codebase run on iOS and Android?

React Native is an open source framework from Meta that lets you build iOS and Android apps with React components written in JavaScript or TypeScript. Those components render as real native UI elements, not web views. You maintain one main codebase and ship two store apps, while each platform keeps its own look and behavior.

Clients usually ask me what is React Native right after their website project ends and a mobile app lands on the roadmap. I have worked in digital marketing and web since 2012. So I see how app decisions affect budgets, ad tracking and long term maintenance. This guide covers the New Architecture, Expo, a short comparison with Flutter and the cases where React Native is the right call.

I will not repeat how to learn programming from scratch here. However, if you want the wider web context first, the software category collects related articles.

Why does the short history of React Native still matter?

Meta released React Native as open source in 2015. Its teams had tried mobile apps built on web views and found them too slow. Therefore they moved the React component model onto native UI instead. The motto was "learn once, write anywhere". It was never "write once, run anywhere".

In practice, that difference matters in daily work. You share most of your code, yet some screens need platform specific behavior. For example, the iOS swipe back gesture and the Android back button create different expectations. A good React Native team does not hide those differences. Instead, it manages them on purpose.

In short, React Native is not a shortcut. It is a bridge that carries the React mindset of web developers into mobile. Also, the current architecture is very different from the original bridge design. The next section explains why.

Why was the old bridge a bottleneck?

In the old architecture, JavaScript and the native layer talked through an asynchronous bridge. Every call was serialized to JSON, queued and decoded on the other side. As a result, heavy animations, long lists and fast touch interactions could feel laggy.

Put simply, the two worlds could not call each other directly. For instance, reading a layout measurement synchronously during a scroll meant waiting for the bridge. Many teams moved logic into native code to work around it. Consequently, codebases grew harder to maintain.

On top of that, all native modules loaded at startup. That slowed launch times in large apps. The New Architecture was designed to fix exactly these two issues: the async bridge and eager loading.

What are the building blocks of the React Native New Architecture?

The New Architecture rests on four parts. They share one goal: shorten the distance between JavaScript and native code and make rendering more predictable. Here is a plain summary.

• JSI (JavaScript Interface): lets JavaScript hold direct references to C++ objects, so no JSON serialization is needed.
• Fabric: the new rendering system, which supports synchronous layout and React concurrent features.
• Turbo Modules: native modules that load lazily, only when your code needs them.
• Codegen: generates type safe native interface code from TypeScript specs.

According to the official team, the New Architecture became the default in React Native 0.76 in October 2024. The React Native 0.82 release post went further. From that version on, you can no longer switch it off, and legacy opt out flags are ignored.

So a new project today does not need an architecture decision. The real question is whether your libraries support the New Architecture. The easiest check is a quick pass through your dependency list. Most popular packages already support it. Still, small packages without recent updates can cause trouble.

How do JSI and Fabric change the speed users feel?

After all, users never see architecture names. In practice, they only notice whether a tap responds instantly. With JSI, JavaScript can call a native function without queueing through a bridge. Thus gestures, animations and measurements feel smoother.

With Fabric, the view tree lives in a shared C++ layer. Therefore iOS and Android share the same layout calculations, and visual inconsistencies shrink. In addition, React concurrent features, such as transitions that prioritize urgent updates, now work on mobile too.

Let me be honest, though. The New Architecture will not rescue a badly written screen. Needless re-renders, huge images and unbounded lists are slow in any architecture. Performance still depends on team discipline. The architecture only raises the ceiling. So keep profiling after the migration as well.

What does the Hermes engine bring to your app?

Hermes is the JavaScript engine Meta built for React Native, and new projects use it by default. It compiles JavaScript to bytecode at build time. As a result, the app does not waste time parsing JavaScript during launch.

In practice, this has two effects. First, startup feels more acceptable on mid range and entry level Android devices. Second, memory use stays more stable. If a large share of your audience uses budget phones, this difference reaches real users directly.

Even so, Hermes is not a magic wand. Bloated dependencies, unnecessary network calls at launch and a heavy first screen will slow startup regardless of the engine. Measure first, then optimize.

What is Expo and how does it relate to React Native?

Expo is a framework and toolset built on top of React Native. It bundles ready modules for camera, notifications and location. It also includes Expo Router for file based routing and EAS services for cloud builds. In other words, Expo is not a competitor to React Native. It is the comfortable layer above it.

The official React Native getting started page recommends using a framework for new apps, and it highlights Expo. That is a notable change. A few years ago, a bare React Native setup was the default. Today, the official path starts with Expo.

Let me also correct an old myth. Expo no longer locks you into a closed box. With development builds and config plugins, you can add your own native code. Moreover, Expo's New Architecture guide explains how the SDK works with it.

Should you start with Expo or the bare React Native CLI?

For most business projects, my answer is Expo. However, some cases call for a different choice. The table below compares both approaches by their effect on daily work.

In short, the takeaway is clear. Expo cuts the time you spend on tooling. On the other hand, banking SDKs, custom Bluetooth hardware or embedding React Native screens into an existing native app may feel easier with the CLI.

One rule works well for me: start with Expo and leave only if you truly must. Going the other way, from CLI to Expo later, is usually more painful.

What is the main difference between Flutter and React Native?

The core difference is rendering. React Native uses the platform's own UI components. Flutter draws every pixel with its own rendering engine. Therefore a Flutter app looks nearly identical on both platforms, while a React Native app picks up the native feel more easily.

You can read the official Flutter documentation for details. That said, my observation is simple. Both are mature, and both power successful store apps. Your team's language and your product's design needs should decide, not hype.

When is Flutter the smarter choice?

I find Flutter stronger in three scenarios. First, your brand design deliberately departs from platform conventions and must look identical everywhere. Second, your team already knows Dart or Flutter. Third, you are building playful interfaces with heavy custom animation and graphics.

For example, a colorful learning app for children benefits from Flutter's own rendering engine. By contrast, users of a business ordering app expect familiar iOS and Android behavior. There, React Native's native components feel more natural.

Also look at community size, job demand and library ecosystems. If you plan to grow the team, finding React developers is often easier than finding Dart developers in many markets. Verify that against job listings in your own region, though.

When is React Native the right choice?

From my field experience, React Native shines under these conditions. This is not a guarantee. It is the checklist I use when advising clients.

1. Your team already has web developers who know React and TypeScript.
2. Your app consists of business screens such as forms, lists, carts, profiles and notifications.
3. You want to share business logic, validation rules and API clients with your website.
4. Launch timing matters: you need to launch on iOS and Android at the same time with the same feature set.
5. You want to ship bug fixes through remote updates instead of waiting for store review.

If three or more points apply, React Native is a strong candidate. Also, if your site was built with React during a web design project, reusing that team knowledge for mobile eases the budget.

Still, business goals matter as much as technology. Writing code before the app's role in the sales funnel is clear leads to expensive rework later.

When might React Native be the wrong choice?

I do not recommend React Native for every project. For example, 3D games that push hardware limits, real time video processing or AR heavy apps usually work better with Swift and Kotlin, or with game engines.

Similarly, if your app lives on a single platform, such as an iPad only field app, the cross platform advantage mostly disappears. In that case, fully native development can be simpler.

Finally, be careful if you must adopt new OS features on day one. The React Native community moves fast. Yet when Apple or Google ships a new API, a wrapper can arrive later. So you may need to write native glue code yourself in the first weeks.

How do you manage platform specific code in one codebase?

One codebase does not mean every line is identical on both platforms. React Native supports platform specific file extensions, so you can write one version of a component for iOS and one for Android. You can also check the platform inside your code for small differences.

Here is the structure I recommend. Keep business logic, API calls and state management fully shared. Push platform differences to the edges of the UI: navigation gestures, permission dialogs and notification behavior. Consequently, the diverging code stays small and testable.

This discipline also helps designers. They know upfront which screens will differ by platform. Marking that in layers during Figma design work cuts the back and forth between design and development.

How do you measure performance in a React Native app?

You cannot improve what you do not measure. I suggest tracking three signals from day one: cold start time, dropped frames while scrolling and time to the first meaningful screen. Together they shape the user's first impression.

• Use React Native DevTools to inspect the component tree and re-renders.
• Use virtualized list components for long lists.
• Serve images at the right size. The habit you apply on the web with an image resizer matters on mobile too.
• Run pre release tests on an entry level Android phone, not the fastest device in the office.

The discipline you use with Lighthouse on the web applies here as well. My Lighthouse performance test guide shows that measuring habit. It is platform independent.

How do your website and React Native app grow together?

An app is never a standalone channel. Users often find you first in search, social media or ads. Then they visit your website and only later install the app. Therefore the path between site and app must not break.

Here is a practical example. If you tag campaign links with a UTM builder, you can see which channel drives app installs in your web analytics. Also, if your mobile site is weak, users drop off before they ever reach the app. That is why mobile first design is part of app strategy too.

In short, do not leave the React Native decision to engineering alone. When marketing, analytics and design sit at the same table, the app creates value faster.

How do you set up navigation with Expo Router?

Expo Router brings file based routing to mobile. When you add a screen file to a folder, that screen becomes a route automatically. Anyone who has used Next.js on the web recognizes this on day one. Hence the learning curve is short.

Additionally, a side benefit is deep linking. Because every screen has an address, a link in a campaign email can open the exact product screen. For instance, a cart reminder can open the cart directly instead of the home screen.

That looks minor, yet it shows up in conversions. Removing two extra taps reduces funnel drop off. I explain the same logic for websites in my conversion funnel guide. The principles carry over to mobile.

What can over the air updates change, and what can they not?

The JavaScript part of a React Native app runs as a bundle separate from native code. Thanks to that, services like EAS Update let you ship text fixes, small bug fixes or content changes without waiting for store review.

However, the limits are firm. Adding a native module, changing permissions or upgrading React Native requires a new store release. Besides, Apple and Google store rules do not let you change the core purpose of your app through remote updates. So OTA is a maintenance and emergency tool, not a hidden release channel.

My advice is to test remote updates like normal releases. A bug that reaches thousands of users within minutes spreads much faster than a bug in a store build. Therefore roll updates out to a small group first and watch the metrics.

How do you set up testing and releases for a React Native app?

First, I recommend three test layers. Unit tests check business logic. Component tests check screen behavior. End to end tests check critical flows such as login, payment and order creation, the steps that actually earn money.

Next, automation is essential for releases. Set up a pipeline that runs tests on every merge and sends a build to an internal testing track when they pass. Then the "it worked on my machine" debates disappear. Moreover, cloud builds like EAS Build remove the need for Xcode setup on every laptop.

Small teams should not see this as heavy process. A few end to end tests for critical flows and one automatic internal build already make release day much calmer. You can widen coverage over time.

How should you plan analytics and ad tracking for a mobile app?

After launch, the question I hear most is: which ad drives installs? The answer starts with planning measurement early. The Firebase and GA4 integration lets you see in app events and conversions in the same property as your web data.

Specifically, keep event names consistent across web and app. For example, if you named the add to cart event on the web, use the same name in the app. Otherwise reports split in two and comparisons break.

On the ads side, app campaigns follow their own logic. In Google Ads management, sending in app conversions correctly is a basic condition for smart bidding to learn. So write the tracking plan before coding starts, not after.

Why should you not underestimate React Native maintenance?

Above all, launch day is not the end of the work. It is the beginning. Apple and Google update their operating systems every year, store policies change and your libraries ship new versions. React Native itself releases on a regular schedule as well.

My starting suggestion, based on field experience and not a guarantee, is this: next to the first release budget, reserve a separate yearly line for maintenance. It covers dependency upgrades, OS compatibility and small fixes. Apps that skip maintenance fall several versions behind, and upgrade costs then grow fast.

When choosing libraries, look at maintenance continuity rather than popularity. A package with no recent updates may not support the New Architecture. Therefore check freshness and support before adding any new dependency.

What is React Native in plain business terms?

Beyond the technical definition, what is React Native for a business owner? The answer is simpler: one team, one codebase and two stores. This model simplifies budgets and timelines, especially for companies that want a fast first release. Yet simpler does not mean free.

Consider an example calculation. If you hire one React Native team instead of two separate native teams, hiring and coordination effort drops. In return, that single team must understand the details of both iOS and Android. So the savings depend on the team's skill.

That is why price should not be your only filter when you collect quotes. Download apps the team has already published, try them on a budget phone and ask how they handle maintenance. Then you compare promises with real performance.

Which myths should you avoid when researching what is React Native?

Part of what circulates online about React Native comes from the old architecture era. So check the date of any article and the version it mentions. Most bridge related speed complaints do not apply the same way today.

• Myth: React Native is a web view. Reality: the UI renders with native components.
• Myth: Expo cannot run native code. Reality: development builds allow it.
• Myth: one codebase means zero platform differences. Reality: differences shrink but remain.
• Myth: cross platform is always cheaper. Reality: hardware heavy projects can be the opposite.

In short, relying on current official sources lowers the risk of a bad decision. Also, when you hear a claim, ask which version it applies to. That question settles technical debates quickly.

Which questions should you answer before starting a React Native project?

Above all, clarifying business questions before choosing technology is the most efficient use of budget. I answer these questions with clients before any new mobile project.

• Which business goal will the app serve: sales, loyalty or operations?
• What will users do in the app that they cannot do on the website?
• How many people on your team know React, and who will own maintenance?
• Which native features are essential: camera, location, payments, Bluetooth?
• Which metrics will define success?

Finally, the last point matters most. To define success metrics upfront, you can apply the framework from my digital marketing KPIs article to apps as well. After launch, the discussion then focuses on goals, not on taste.

So what is React Native, in one final answer?

To sum up, React Native is a mature framework that carries React knowledge from the web to iOS and Android. Its New Architecture has left most old bridge problems behind. Starting with Expo is now the official recommendation. Flutter remains a strong alternative with a different rendering philosophy.

When you decide, weigh your team's language, your product's design needs and the app's business goal together. In other words, put the problem at the center, not the technology. If you want to discuss how an app should connect with your website, ads and tracking, you can reach me through the contact page.