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.

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.
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.
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.
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:
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 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.
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.
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.
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:
npm view react-native version
npm view react-native@0.86 versionThe 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.
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.
React Native makes the most sense if:
An honest answer to these criteria determines your team's comfort for years to come, so discuss it together before deciding.
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.
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:
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.