React Native Explained: One Codebase, Two App Stores

#reactnative #mobile #beginners #programming

Introduction

Building a mobile app traditionally meant two teams, two languages, two codebases: Swift for iOS (the Swift post) and Kotlin for Android (the Kotlin post). React Native, created at Meta, offers a different deal: write the app once in JavaScript and React, and ship it to both stores. It is not a web page in a wrapper — it renders genuinely native interface elements, which is why apps built with it feel like real apps.

Components, not web tags

If you know React (the React post), React Native feels familiar — same component model, same state, same hooks — but the building blocks are mobile primitives instead of web tags:

import { View, Text, TouchableOpacity } from "react-native";
function WelcomeScreen() {
  return (
    <View>
      <Text>Welcome back, Sara</Text>
      <TouchableOpacity onPress={() => console.log("Pressed")}>
        <Text>Get started</Text>
      </TouchableOpacity>
    </View>
  );
}

View becomes a native view, Text becomes native text, and TouchableOpacity becomes a native touchable element — on iOS and Android alike. Styling uses a JavaScript subset of CSS (flexbox layout, which the Flexbox post covered), so web developers transfer their skills rather than starting over.

The bridge and native modules

JavaScript can't do everything alone — camera access, Bluetooth, push notifications all live in the native platform. React Native handles this through native modules: small pieces of Swift/Kotlin code exposed to JavaScript, so your app calls a JavaScript function and the native side does the platform work. Most common needs already have community modules, and the modern architecture (with the new Fabric renderer and TurboModules) has made this bridge far faster than the early versions. When an app needs deep platform-specific behaviour, teams write that one screen natively and keep the rest shared — a pragmatic middle ground.

The honest trade

React Native is not magic: very graphics-heavy apps (games, complex animations) and apps needing the newest platform features on day one may still be better fully native. Updates to iOS and Android occasionally require framework updates before new APIs are available. But for the large middle of apps — business apps, social apps, content apps — one team shipping to both stores, with over-the-air updates via tools like Expo, is a decisive advantage. Expo, the common starting point, removes most native setup entirely for beginners.

Takeaway

React Native turns React skills into real native apps on both platforms, components map to native elements rather than web pages, and native modules cover the platform-specific gaps. One codebase, two stores — with a clear-eyed view of where fully native still wins.

Originally published at https://practicaldevblog.blogspot.com/2026/10/react-native-explained-one-codebase-two.html

DEV Community