React Native (RN) is a framework that lets developers write apps once and run them on both iOS (iPhones) and Android. Sounds magical, right? But under the hood, there’s a lot of wizardry happening to make this possible.
Let’s break it down, step by step.
1. The Problem RN Solves
Normally, iOS and Android apps speak completely different “languages.”
- iOS apps speak Swift or Objective-C
- Android apps speak Java or Kotlin
Before React Native, if you wanted your app on both platforms, you basically had to build the same thing twice, like doing your taxes in two different countries at the same time. Painful.
React Native says: “Hey, write in JavaScript—the language web developers already know, and I’ll handle translating it to what the phone understands.”
2. How It Used to Work (The Old Way)
Originally, React Native used something called the bridge. Think of it as a translator sitting between two people who speak completely different languages.
- Your code is written in JavaScript (easy for web devs).
- The JavaScript runs in its own little world called a JavaScript engine.
- Whenever your app needs to display something, like a button, or fetch data, the JS engine sends a message across the bridge to the phone’s native code.
- Native code (Swift/Java) handles the actual work, drawing things on screen, accessing the camera, etc.
- The results get sent back across the bridge to JS.
Problem: This bridge was slow for complex apps. Imagine ordering food through a translator who walks back and forth carrying messages for every tiny thing. It works, but if you want a smooth 60 FPS experience, it can choke.
3. How It Works Now (The Modern Way)
React Native has evolved. The bridge still exists, but now there’s direct compilation and new architectures:
a) Fabric (New UI Layer)
- React Native now talks to the native UI in a smarter, asynchronous way.
- Instead of messaging every tiny change one by one, it schedules changes in batches. Think of it like ordering your entire meal at once instead of one forkful at a time.
- This makes animations smoother and apps faster.
b) JSI (JavaScript Interface)
- Previously, JS lived in a separate world. Now, with JSI, JS can directly call native functions without going through the slow bridge.
- It’s like having the translator suddenly become a polyglot who understands both languages perfectly and speaks instantly.
c) TurboModules
- In the past, every native feature had to go through the bridge. Now, modules can be lazy-loaded and accessed directly, so they only “wake up” when needed.
- Faster startup, less memory usage.
4. What Does This Mean for Developers and Users?
For Developers:
- Less frustration with laggy updates between JS and native code.
- Can write more complex animations and UI interactions without the dreaded “jank.”
- Easier to maintain one codebase that feels native on both platforms.
For Users:
- Smoother apps, less battery drain.
- Faster launch times.
- Animations that don’t make you feel like your phone’s having a seizure.
5. Analogy to Make Your Brain Happy
Old RN: JS is a tourist. Wants a burger. Asks a translator. Translator goes to the kitchen, grabs burger, comes back, repeats for fries, soda, napkins… painfully slow if there’s a lot to order.
New RN: JS is now a multi-lingual chef. Orders can be spoken directly to the kitchen, batches are prepped efficiently, and the meal arrives hot and fast.
6. TL;DR for the Lazy Brain
- React Native = write JS once, run everywhere.
- Old RN = slow bridge, everything had to walk messages back and forth.
- Modern RN = JSI + Fabric + TurboModules = direct communication, smarter scheduling, faster apps.
The result: apps that look and feel native, without the headache of writing twice.
Top comments (0)