What React Native Actually Is

Everything up to this point in your React learning has ended at the DOM. A component returns JSX, React figures out the difference between renders, and the browser paints actual divs, buttons and spans. React Native keeps the first two parts of that sentence — components, JSX, hooks, the whole mental model — and completely replaces the third.

The same JS, a different target

A React Native app is still one JavaScript (or TypeScript) codebase. You still write function components, you still return JSX, you still use useState and useEffect exactly as you already know them. What changes is what that JSX turns into. Instead of DOM elements, your JSX describes native platform components — the same kind of UI building blocks a native iOS or Android engineer would use directly, just reached through a JavaScript API instead of Swift or Kotlin.

function Greeting() {
  return <Text>Hello from React Native</Text>;
}

That Text is not an HTML tag standing in for something else. On iOS it becomes a real native text label; on Android, a real native TextView. Nothing here is simulated or drawn by a browser engine — the pixels you see on the device are produced by the platform's own UI toolkit, driven by your JavaScript.

Not a WebView — the distinction that matters

Before React Native (and still today, for some apps), a common way to ship a JavaScript UI on mobile was a hybrid app: bundle a WebView — essentially an embedded browser — inside a thin native shell, and load your web app into it. It works, and it lets you reuse web code directly, but you inherit every characteristic of a browser rendering HTML: web-style scrolling and animation performance, the DOM's rendering pipeline, and generally a UI that users can often feel is "not quite" native, even when the app tries hard to disguise it.

React Native takes a different approach entirely: it never renders HTML at all. Your JS still runs (on a JavaScript thread), but the actual UI is produced by the platform's native component APIs.

From your code to pixels, conceptually

At a conceptual level (you'll go much deeper on this later in the track, including the bridge and JSI), the flow from your source code to something appearing on a physical screen looks like this:

Why this distinction actually matters

This isn't a pedantic technical detail. It's the reason React Native apps can achieve native performance and a native look and feel where hybrid WebView apps often can't fully: scrolling, animations, and standard controls are the platform's own, not an approximation drawn by a browser rendering engine. It's also why React Native has real, first-class access to native device APIs — camera, contacts, sensors, notifications — because the components and the bridge between your JS and the platform are built for exactly that purpose, not retrofitted onto a web page.

None of this makes React Native strictly "better" than a WebView-based hybrid approach in every case — a content-heavy app that's basically a website might be perfectly served by a WebView, and it's a much smaller lift. But if the goal is an app that feels genuinely native — native scrolling physics, native controls, tight integration with device capabilities — that's precisely the gap React Native exists to close.

Why this course teaches without a live preview

Every JavaScript and React lesson you've seen so far in this catalogue has had a Playground you could actually run, because a browser can genuinely execute plain JS and genuinely render real React DOM output. Neither is true for React Native's core components. There is no honest way to render a real View or Text inside a browser tab — a browser doesn't have a native UIView or Android View to draw. The only way to fake a "live" React Native preview in a browser would be to render ordinary divs that merely look like the native output, which would be actively misleading about what the code does on a real device or simulator.

So this track does something different: every lesson gives you real, correct, complete code, and asks you to read and reason about what it does, the same way you'd read a diff during code review before ever running it. That's a legitimate and common way senior engineers actually work with unfamiliar code — and it's the only honest option here.

What to remember

• React Native keeps React's component model, JSX, and hooks exactly as you know them — only the render target changes.
• Your JSX describes native platform components, not HTML; there's no DOM and no browser involved in the rendered app.
• A WebView-based hybrid app renders actual HTML in an embedded browser — a fundamentally different, more limited approach that React Native was built to move past.
• The native rendering is what gives React Native native performance, native feel, and direct access to native device APIs.
• This track has no live "run it" preview for RN-specific code, because faking one with browser divs would misrepresent what the code actually renders on a device.