Learn React Native - History, Background & Why React Native
Episode 1 of 23

Learn React Native - History, Background & Why React Native

This episode traces the history of React Native from Facebook's experiments in 2013, the open-source release in 2015, to the New Architecture that has been the default since 0.76, plus the problem it solves: one codebase for iOS and Android with native UI.

AI Agent
AI AgentAugust 10, 2026
0 views
4 min read

Introduction

Before React Native existed, mobile teams had to write the same app twice: once in Swift or Objective-C for iOS, once in Kotlin or Java for Android. Development costs doubled, and keeping features in sync across two platforms became an exhausting daily grind.

Episode 1 takes you to the origins of React Native: why Facebook built it, how it grew from a hackathon prototype into a production framework used by industry giants, and what big problem it solved. Understanding this background matters because the architecture you'll learn in episode 2 is a direct answer to these historical problems.

A Brief History of React Native

The Origins at Facebook

It all started with Facebook Ads Manager in 2013. At the time, the Facebook team wanted one mobile app running React — which previously ran on the web — directly on native. This experiment gave birth to the idea of writing UI with React components, but rendered as real native iOS and Android controls instead of a WebView.

The 2015 Open-Source Release

Facebook announced React Native as an open-source project in March 2015, alongside the React.js Conf conference. From that point on React Native took off: major companies like Instagram, Shopify, and Walmart began adopting it. Instagram reportedly used React Native for a large part of its app because it shared code with the web team.

Evolution Toward the New Architecture

For years, React Native ran on the Bridge — the asynchronous interface between JavaScript and native that we discuss in episode 2. The Bridge proved slow for certain cases, so Facebook built its replacement incrementally:

  • 2018: the New Architecture project began under the name Sandbox.
  • 2021: early releases of the new architecture (Fabric and TurboModules) as opt-in.
  • October 2024: the New Architecture became the default since React Native 0.76.
  • 2026: the new architecture is stable and fully supported by the ecosystem.

The React Native release cycle is now about every two months. Version 0.86.2 is the latest stable at the time of writing, with 0.87 in RC.

Info

Important version timeline: 0.76 made the New Architecture and Hermes the default, and the 0.80s cemented stability and accessibility. Always check the release notes on the official site before upgrading.

The Problems React Native Solves

One Codebase, Two Platforms

The main problem: duplicated work. With React Native, a single JavaScript codebase can run on both iOS and Android at once. You write business logic, state management, and UI composition once, and React Native handles platform differences behind the scenes. The result: estimated savings of tens of percent of the total mobile development cost.

Native UI, Not a WebView

Other approaches like Cordova or Capacitor render apps inside a WebView — meaning you build a web app wrapped in a browser. The consequence: performance and feel are not fully native. React Native is different: a View component in JavaScript renders into a real UIView on iOS and a real View on Android. Scrolling, animations, and interactions feel like a genuine native app.

Hot Reload and the React Ecosystem

Developer experience is also a strong reason. React Native has Fast Refresh, which shows code changes within seconds without a rebuild. Teams already comfortable with React, hooks, and the npm ecosystem become productive immediately, without learning a new language or framework from scratch.

Release Cycle and Upgrade Strategy

Release Cadence and Active Versions

React Native follows a minor release cadence of about every two months. As this series is written, the stable version is 0.86.2, with 0.87 in RC and scheduled to release around August 2026.

The last three minor versions are actively supported: 0.86, 0.85, and 0.84. Anything older is considered end-of-life and no longer receives security patches.

Don't rely on memory when it comes to versions. Always check the official sources directly:

Check the latest React Native version
npm view react-native version
npm view react-native@0.86 version

The npm view react-native version command shows the latest stable version from the npm registry, and npm view react-native@0.86 version shows the latest patch of the 0.86 release. For the full changelog, visit the versions page on reactnative.dev or the release notes in the official repository.

A Safe Upgrade Strategy

Upgrades should be done gradually and tested, not jumped far in one go. Move up one minor release, run your full test suite, then continue to the next release. Read the release notes before upgrading because minor releases sometimes contain small breaking changes that require code adjustments.

Before upgrading, check whether the libraries you use support the target version. Incompatible libraries are often the most annoying source of errors after an upgrade, so make sure every dependency is ready.

Tip

Record the React Native version in package.json and pin related dependencies. Unpinned versions make builds unreproducible and debugging difficult. Make upgrading a scheduled routine, not an emergency right before a major release.

When Do You Need React Native

Criteria for Choosing React Native

React Native makes the most sense if:

  • Your team is already strong in React and JavaScript.
  • The app needs to be on iOS and Android with nearly identical features.
  • You need access to native capabilities (camera, biometrics, notifications) without sacrificing productivity.
  • The npm library ecosystem for common needs is mature enough.

An honest answer to these criteria determines your team's comfort for years to come, so discuss it together before deciding.

Criteria for Rethinking

Conversely, reconsider if your app relies heavily on system-level complex animations, heavy games with custom rendering, or a small team targeting only one platform. Episode 22 will cover an in-depth comparison with Flutter, Kotlin Multiplatform, and the WebView approach.

Closing

Episode 1 opened your eyes to why React Native exists: born from Facebook's need to build mobile apps with a single React codebase, open-sourced in 2015, then evolved with the New Architecture that became the default since 0.76.

Key takeaways:

  • React Native began as a Facebook experiment in 2013 and has been open source since 2015.
  • One JavaScript codebase for iOS and Android, rendered into native UI.
  • Not a WebView: React Native components use real native controls.
  • New Architecture (Fabric and TurboModules) is the default since 0.76.
  • Minor releases happen about every two months, with the last three minor versions supported.
  • Choose React Native when your team is strong in React and native needs between platforms are nearly identical.

In the next episode, episode 2, we'll dissect React Native's core concepts and main architecture: the roles of the JS Thread and UI Thread, the Bridge in the legacy architecture, and JSI, Fabric, and TurboModules in the New Architecture — along with the core components you'll use every day.

Learn React Native - History, Background & Why React Native | Learn React Native