16 — Mobile with React Native — One Paradigm, Real Native Components

"React running inside a webview" was my React Native misunderstanding, and it missed the bridge entirely. The model that corrected it: React Native doesn't render web DOM. It uses React's component model and reconciliation, but the host platform is the device's real native UI toolkit, not a browser. [1][2] The same tree-diffing, hooks, and composition I use on the web produce genuinely native iOS and Android screens, because the bridge translates React's render tree into native view calls.

The key difference from web React

On the web, React renders to DOM elements — <div>, <span>, <button>. In React Native, there is no DOM. React renders to native primitives: View, Text, Image, ScrollView. These map, under the hood, to UIView on iOS and android.view.View on Android — the actual platform widgets. The implications:

• No HTML, no CSS. There's no <div>; I use <View>. There's no CSS; layout is done with a subset of Flexbox via the style prop. The way of thinking is "Flexbox everywhere," which is a real adjustment from the cascade.
• Real native components. A <Text> is a native label, a <ScrollView> is a native scroll container. Animations, gestures, and accessibility use the platform's own implementations, not polyfills.
• The bridge. React logic runs in a JavaScript thread; the native UI runs on the platform's main thread. The bridge shuttles updates between them. (The newer architecture — Fabric/New Architecture — reduces this overhead, but the conceptual split remains.)

// React Native — no DOM, native primitives instead
import { View, Text, Pressable, StyleSheet } from 'react-native';

function Card({ title, onPress }) {
  return (
    <Pressable style={styles.card} onPress={onPress}>
      <Text style={styles.title}>{title}</Text>
    </Pressable>
  );
}

const styles = StyleSheet.create({
  card: { padding: 16, backgroundColor: '#fff', borderRadius: 8 },
  title: { fontSize: 16, fontWeight: '600' },
});

The component shape is familiar — props, composition, hooks all carry over — but the primitives and styling model are different. That's the transfer cost.

What carries over from web React

This is the real value proposition. Because React Native is React, the parts of the React way of thinking I built on the web transfer directly [1][2]:

• Components, props, state. The functional-component-and-props model is identical.
• Hooks. useState, useEffect, useReducer, custom hooks — all work the same. (Effects reach native APIs instead of browser APIs, but the shape is unchanged.)
• Reconciliation and the tree model. The same render-and-commit cycle drives updates.
• State management and data fetching. Zustand, TanStack Query, Apollo — these are platform-agnostic and work in React Native unchanged.

What does not carry over: anything DOM-specific. Routing uses a different library (React Navigation, not React Router). Styling is the Flexbox-via-style-prop model, not CSS/Tailwind. Form libraries differ. The web frontend tooling (CSS-in-JS, headless UI libraries) doesn't apply. So the transfer is the React core, not the web ecosystem around it.

When React Native is the right call

The decision is rarely "native vs web" in the abstract — it's about the team and the target. React Native's pitch is one paradigm (and often one codebase) across iOS and Android, with the React knowledge a web team already has. For a team that's strong in React and needs both platforms, that's a large productivity win — write the app once, ship to both stores, share business logic and state management with a potential web version.

The cases where it's not the right call: when an app needs deep platform-specific integration (heavy AR, complex camera pipelines, bleeding-edge platform APIs), the bridge can become a bottleneck, and going fully native (Swift/Kotlin) gives more control. For most product apps — lists, forms, navigation, media — React Native covers the ground well, and the gap to fully-native has narrowed sharply with the New Architecture.

How I use this

React Native is my answer when the target is genuinely mobile-first and a single team needs to cover both iOS and Android — the React way of thinking transfer is real, and the productivity of one codebase is hard to beat for typical product apps. The cost I budget for: re-learning the primitives (View/Text instead of div/span), the Flexbox-only styling model (no Tailwind, no cascade), and a separate routing library (React Navigation). The React core — components, hooks, reconciliation, state management, data fetching — carries over intact, which is why a web React dev can become productive in React Native in days rather than weeks. For web-only targets, none of this applies; React Native is specifically the mobile answer, not a general-purpose one.

References

[1] Meta, "React Native — learn once, write anywhere," reactnative.dev, 2024. [Online]. Available: https://reactnative.dev/

[2] Meta, "React Native — getting started," reactnative.dev, 2024. [Online]. Available: https://reactnative.dev/docs/getting-started

[3] freeCodeCamp, "React Native course for beginners," YouTube, 2024. [Video]. Available: https://www.youtube.com/watch?v=ZBCUegTZF7M