Building for iOS and Android historically meant two separate codebases in two separate languages — Swift or Objective-C on one side, Kotlin or Java on the other — which means every product decision has to be implemented, reviewed, and shipped twice by two different sets of engineers who rarely read each other's code. A button's tap target gets fixed on iOS in one sprint and quietly stays broken on Android for three more, not because anyone is careless, but because there was never one place that change had to happen.
A small team cannot credibly promise feature parity across both platforms under that model — they either delay one platform's release, or split an already-small team into two smaller ones that stop reviewing each other's work, and the two apps drift further apart with every release. React Native exists to remove the "which platform waits" decision entirely by letting one team write the application logic once, in JavaScript or TypeScript, and have that single codebase drive genuinely native UI on both platforms at once.
Analogy🏏Cricket
🏏 Think of it like cricket: During a bilateral series, fans watch the same match through two entirely different presentation layers — the broadcaster's television graphics package and the stadium's giant screen replay system — and for years many grounds ran these as two independently operated systems, with one operator typing the score into the TV graphics computer and a second operator, on a different console, typing the same score into the stadium screen a few seconds later. When the two systems drifted — a boundary logged on the TV graphics before the stadium screen caught up, or a wicket shown as "out" on one display and still "not out" on the other for a few tense seconds — nobody trusted either display fully, and ground staff spent as much time reconciling the two feeds as producing them. Modern grounds instead feed match data from one canonical scoring system that both the broadcast graphics and the stadium screen consume as clients, so a wicket appears, correctly, on both surfaces from the same authoritative update the instant it happens. Just as one canonical scoring feed driving two different display surfaces keeps them in agreement by construction, one JavaScript codebase driving two native UI trees keeps an iOS build and an Android build from silently drifting apart the way two independently maintained native codebases eventually do. Just as the two grounds staff running separate consoles were not being careless — the drift was a structural property of having two independent sources of truth — two native teams building the same feature twice will structurally drift even with the best intentions. The insight is that consistency across two output surfaces is not a discipline problem to manage harder; it is an architecture problem solved by having exactly one source of truth feed both.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.