Why React Native Exists

"All problems in computer science can be solved by another level of indirection." — David Wheeler

React Native is the answer to a question that had two bad answers for a decade: how do you write one application that runs properly on both phones?

The bad answers were well understood. Write it twice — one Swift team, one Kotlin team, two codebases that drift, every feature specified once and built twice. Or wrap a web page in a native shell, which is what Cordova and PhoneGap did, and which produced applications that looked almost right and felt immediately wrong: scrolling with the wrong momentum, no platform gestures, buttons that were not the platform's buttons.

React Native's bet was a third thing, and Wheeler's line is exactly the shape of it. It does not draw its own buttons and it does not wrap a web view. It keeps React's programming model and changes what React renders to — the components you write become real UIViews on iOS and real Views on Android, driven from JavaScript. The indirection that makes this possible was already in React before anyone had built a phone app with it, which is the genuinely surprising part of the story.

This chapter establishes that claim by looking, not asserting. I traced React Native 0.81.4's source to find out what <View> actually is, and the answer is more literal than most descriptions suggest. Then we deal with the honest limits — including what this volume's own playground can and cannot show you, because that boundary shapes every chapter that follows.

Three ways to be cross-platform

There are only three strategies, and every cross-platform toolkit is one of them. Naming them is worth doing, because the trade-offs are not marketing positions — they follow from the strategy and cannot be engineered away.

Wrap a web view. Ship a browser, run a web app inside it. Cheapest to build, and it inherits every strength of the web. What it cannot inherit is the platform: the scroll physics, the keyboard behaviour, the share sheet, the way a list bounces at the end. Users do not describe these individually — they say the app "feels weird."

Draw your own pixels. Ship a rendering engine and paint every control yourself. Flutter does this, and it buys total consistency: identical output on both platforms and complete control over every frame. The cost is that you now own the entire widget set. When iOS changes how a text field behaves, you get the new behaviour when your framework implements it, not when the OS ships it.

Drive real native views from JavaScript. Keep the platform's actual widgets and control them from a JavaScript thread. You inherit platform behaviour, accessibility and OS updates for free. The cost is a boundary between two worlds, and the rest of this volume is largely about that boundary.

That slogan distinction is not marketing pedantry, and it predicts what the rest of this volume feels like. You will write two platforms' worth of adjustments. What you will not do is learn two component models, two state systems, or two ways to think about a list.

React was never a DOM library

Here is the part that makes React Native possible, and it was true two years before React Native existed.

React separates two jobs. One is deciding what the interface should look like — running your components, diffing the resulting tree, working out the minimum set of changes. That is the reconciler, and it knows nothing about browsers. The other job is actually creating and updating things — and that is a host config, a set of functions like "create an instance of this type", "append this child", "update these props".

react-dom is one host config, where "create an instance" means document.createElement. React Native is another, where it means creating a native view. Same reconciler, different host.

You can verify this from the packages rather than taking my word for it. React Native 0.81.4 declares a peer dependency of react: ^19.1.0 — the same React the web uses, not a fork. And instead of react-dom it ships its own renderers in Libraries/Renderer/implementations/: ReactNativeRenderer for the old architecture and ReactFabric for the new one.

The reconciler in that block is a toy — the real one handles interruption, priorities, suspense and a great deal else. But the shape is right, and the shape is the point: your components are host-agnostic, and swapping the host swaps the platform.

What <View> actually is

Descriptions of React Native tend to say it "renders to native components", which is true and vague. I traced it in 0.81.4 to find out how literal the claim is, and it is very literal.

View.js is a thin JavaScript wrapper — it forwards a ref and processes a few props, then renders <ViewNativeComponent>. That file contains no drawing code of any kind. ViewNativeComponent.js does one meaningful thing:

const ViewNativeComponent: HostComponent<Props> =
  NativeComponentRegistry.get<Props>('RCTView', () => ({
    uiViewClassName: 'RCTView',
  }));

That is the bottom of the JavaScript side. <View> resolves to the string 'RCTView' — a host type name, exactly as 'div' is a host type name in React DOM. The string is then resolved by the platform: React/Views/RCTView.h in the package is an Objective-C UIView subclass, ReactAndroid/.../views/view/ holds the Android ViewManager, and React/Fabric/.../RCTViewComponentView.h is the New Architecture's version.

So the parallel is exact. In React DOM, <div> is a string the host turns into an HTMLDivElement. In React Native, <View> is a string the host turns into a UIView. Your JavaScript never touches either.

Notice what is not in that code: no div, no className, no CSS file, no px. View and Text are not aliases for HTML elements — on a device they are names that resolve to platform classes. And Text is not merely a styled box, which is the subject of the next Part: it has nesting rules a <span> does not.

What "native" buys, and what the boundary costs

The gain from real native views is concrete and mostly invisible until you lose it. Platform widgets bring their own scroll physics, their own text selection, their own keyboard avoidance, their own accessibility tree that a screen reader already knows how to walk — and when the OS updates, they update with it, without a release from you.

The cost is that your code and your views live in different places. JavaScript runs on its own thread; the views are owned by the platform's UI thread. Everything you do to the interface is therefore a message, and messages have properties that direct function calls do not: they are asynchronous, they are batched, and their arguments must be serialisable.

Almost every performance rule in this volume descends from that one fact.

The batched column is the important one. Sixty operations became three crossings, and that is the difference between a usable framework and a slideshow. It also explains a class of bug that surprises people arriving from the web: you cannot read back a layout you just requested, because the request has not crossed yet.

What this volume can and cannot show you

One more thing before we go further, and it is unusual for this Library to have to say it.

Every previous volume has held to a simple promise: if there is a code block, you can run it, and what you see is true. Volume 19 cannot keep that promise everywhere, because the subject is a device and the playground is a browser. Rather than paper over that, here is the map — and this chapter's own rn try block above was already running under the first of these caveats.

rn try blocks run react-native-web. They are honest about structure: View, Text, Pressable, StyleSheet compose exactly as they do on a device, and flexbox layout applies. They are not honest about the platform, and the next block shows you the seam rather than describing it.

Expo Snack embeds appear where the platform genuinely matters — real iOS and Android simulators, and a QR code so you can run the code on your own phone. That is where anything platform-specific, gesture-driven, or native-module-shaped will live.

Miniatures — models like the reconciler and the boundary above — carry the internals. A navigation stack is a data structure; a virtualization window is arithmetic. Those you can genuinely run.

Stating that boundary explicitly is not a hedge. A volume that let a browser result stand in for a device result would teach confident wrong answers, and the whole method of this Library — measure it, then say what you measured — depends on the distinction between the two being visible.

Common Mistakes

1. Expecting "write once, run anywhere". The claim was always "learn once, write anywhere" — the model transfers, the platform code does not.

2. Budgeting React Native as "React". It is React plus a platform: navigation, Yoga layout, permissions, store review, two build toolchains.

3. Thinking <View> is a styled div. Measured in 0.81.4, it resolves to the string 'RCTView', which the host turns into a real UIView or Android View.

4. Assuming React had to change for this. React Native's peer dependency is react: ^19.1.0 — the same React, with a different renderer alongside it.

5. Treating a prop update as a mutation. It is a batched, asynchronous message, which is why you cannot read back a layout you just requested.

6. Trying to send a function across the boundary. Only serialisable values cross; callbacks are registered and referenced by id.

7. Reaching for a web view for a real screen. It is always faster to build and it reintroduces the exact feel you adopted React Native to avoid.

8. Trusting undated architecture descriptions. The bridge answer and the JSI answer differ, and articles about the former outnumber the latter by years.

9. Reading a description instead of the source. The JavaScript half ships in your node_modules; View.js and ViewNativeComponent.js take five minutes and settle the question.

10. Letting a browser result stand for a device result. rn try is react-native-web, so Platform.OS reads "web" and layout is browser flexbox rather than Yoga.

Interview Corner

Hands-on

Summary

• There are only three cross-platform strategies — wrap a web view, draw your own pixels, or drive real native views — and the trade-offs follow from the strategy rather than from implementation quality.
• React Native drives the platform's own widgets, so it inherits scroll physics, accessibility and OS updates, and pays for a boundary instead.
• The slogan was "learn once, write anywhere" — a claim about the programming model, never about the code.
• React was never a DOM library. The reconciler decides what the UI should be; a host config performs it, and react-dom is only one host.
• React Native uses the same React — peer dependency ^19.1.0 in 0.81.4 — shipping ReactNativeRenderer and ReactFabric in place of react-dom.
• <View> resolves to the string 'RCTView', exactly as <div> is a string, and the host turns it into a real UIView or Android View.
• Every interface update is a message, not a mutation: asynchronous, batched, and restricted to serialisable values.
• Batching is what makes the boundary survivable — 60 operations became 3 crossings — and also why you cannot read back a layout you just requested.
• Read the source when a description feels vague, and keep the version beside the claim, because this framework has already changed its answers once.
• rn try is react-native-web, honest about structure and not about the platform, which is why Platform.OS reads "web" in this volume's blocks.

In the next chapter, The Two Threads, we take the boundary seriously — what actually runs on the JavaScript thread, what the UI thread owns, and why a dropped frame is a scheduling problem rather than a slow function. It is the chapter that explains why the same code can be smooth on a desktop browser and visibly janky on a phone.