A mobile app is not one screen, it is a stack of screens the user pushes onto and pops off of, tabs they switch between, and modals that appear over whatever was already there — and unlike a web app, there is no browser giving you back-button semantics, URL-based history, and address-bar navigation for free. React Navigation exists to give React Native that missing layer: a navigator that tracks which screens are mounted, in what order, and how the platform's native back gesture, hardware back button, and deep links all map onto moving through that stack.
Getting navigation wrong is not a cosmetic problem — it shows up as screens that do not unmount when a user expects them to (silently leaking their state and their effects), back gestures that land somewhere the user did not intend, and deep links that open the app to the wrong place or a broken navigation state entirely. This lesson covers the actual patterns: stack, tab, and drawer navigators and when each is the right shape; typed params so a screen cannot be pushed with the wrong shape of data; and the screen focus lifecycle that governs when a screen should actually do work versus sit dormant in the background of the stack.
Analogy🏏Cricket
🏏 Think of it like cricket: A stadium's crowd-flow design for a major final routes spectators through a very specific sequence — ticket gate, then concourse, then their seating block, then their actual seat — and every one of those transitions is deliberately structured, not left to chance. A spectator who wants to leave their seat to get food follows a known path back to the concourse and can find their way back to the exact same seat afterward, because the venue's structure preserves where they were. If the venue had no defined flow — gates opening directly onto random parts of the stadium with no consistent path back — fifty thousand people would be lost and disoriented within minutes, unable to reliably retrace how they got anywhere or get back to where they started. Just as the stadium's crowd-flow design gives every spectator a predictable path forward and a reliable way back, a navigator gives every screen transition a predictable forward path and a reliable way back to where the user came from. Just as the venue's structure is planned in advance, before a single spectator arrives, an app's navigation structure — which screens are stacks, which are tabs, which appear as modals — has to be planned deliberately, not improvised screen by screen as features get added. The insight is that navigation is not a feature bolted onto an app after the screens exist, it is the structural skeleton that determines whether fifty screens feel like one coherent app or fifty disconnected experiences.
🏏 Showing the Cricket analogy — a Cricket version isn’t available for this concept yet.