"Write once, run anywhere" was never quite true for React Native, and treating it as true is how a screen that looks polished on iOS ships with a keyboard that covers the input field on Android, a shadow that silently does nothing on Android, or a back-navigation gesture that conflicts with the OS's own back button. React Native gives a single component API across platforms, but the two platforms underneath it have genuinely different rendering engines, different input models, different navigation conventions, and different default behaviors — and the abstraction only covers the parts both platforms happen to agree on.
The dangerous version of this gap is not the obvious one, like a component that only exists on one platform — that fails loudly and gets caught immediately. It is the silent divergence: a style property that is accepted without error on both platforms but visibly does nothing on one of them, or a gesture that feels natural on one platform and fights the OS's own conventions on the other, shipped because it was only ever tested on a single platform during development. A team that only ever runs the iOS Simulator during daily development and checks Android once before release is structurally set up to discover these gaps late, expensively, and usually from user reviews rather than from their own testing.
This lesson covers the specific categories of divergence that recur across real React Native apps — shadows and elevation, keyboard behavior, back navigation, and platform-specific styling — not as a checklist to memorize once, but as a set of reasoning patterns for spotting the next platform gap a new feature is about to introduce.
Analogy🏏Cricket
🏏 Think of it like cricket: A touring team preparing to play a Test series in England after a home season entirely in India does not assume the same technique and tactics that worked on a dry, spin-friendly subcontinental pitch will simply transfer unchanged to a green, seam-friendly English wicket — a batsman's grip, stance, and shot selection that scored freely at home can be genuinely exposed by a moving ball and different bounce, and a team that does not specifically prepare for that difference gets caught out in the first Test, not gradually. The format of the game is identical — same rules, same number of overs, same scoring system — but the conditions underneath demand real, specific adaptation that a team assuming universal technique transfer will discover the hard way, expensively, in front of a crowd. Just as a touring team must specifically prepare for how conditions differ across countries rather than assuming technique transfers unchanged, a mobile developer must specifically account for how rendering and interaction conventions differ across iOS and Android rather than assuming a single implementation transfers unchanged. Just as the failure to prepare shows up not as an obvious rule violation but as a batsman getting out to deliveries a well-prepared batsman would have handled, an unhandled platform difference shows up not as a crash but as a screen that quietly behaves wrong on the platform nobody tested. The insight is that a shared format hides real underlying differences, and assuming the format's sameness guarantees behavioral sameness is exactly the gap that catches out a team, or a codebase, that never specifically tested for it.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.