Skip to main content

Navigation

Navigation is product architecture. It determines how the user moves through the application, how analytics are captured, and how deep links or notifications bring users back into context.

Design the route model first​

Before writing stacks and tabs, document:

  • Primary app sections.
  • Entry points from onboarding, authentication, and notifications.
  • Which flows can be interrupted and resumed.
  • Which screens can be deep-linked directly.

Teams usually need:

  • One source of truth for route names.
  • Typed route parameters.
  • Central deep-link configuration.
  • A clear boundary between top-level navigators and feature-level navigation logic.

Common app shells​

Authenticated shell​

This usually contains the main tab structure, app-wide providers, and user-specific entry points.

Anonymous shell​

Keep onboarding, sign-in, sign-up, and recovery flows isolated so authenticated navigation does not become entangled with identity transitions.

Full-screen tasks such as checkout, permission rationale, or media capture should be documented separately from the default navigation shell.

Deep linking​

Deep-link support should be planned from the start, even if it is not immediately public. At minimum:

  • Define canonical routes.
  • Map notification payloads to valid destinations.
  • Handle missing data or expired links safely.
  • Preserve analytics context for attribution.
  • Route names duplicated in multiple files.
  • Screen components reaching directly into parent navigator internals.
  • Auth logic mixed into random screens rather than controlled at the shell level.
  • Deep-link rules hardcoded in notification handlers without route ownership.

Performance considerations​

Navigation affects perceived speed. Pay attention to:

  • Initial route complexity.
  • Heavy providers mounted above every screen.
  • Re-render cascades when navigation state changes.
  • Overloaded screen components that fetch too much on focus.

Observability​

Instrument navigation so you can answer:

  • Where users drop from key flows.
  • Which deep links fail.
  • Which screens load slowly.
  • Which transitions produce crashes or broken back behavior.

Team rule​

Navigation should feel obvious in the codebase. If engineers cannot explain how a new screen becomes reachable, the route model is not documented well enough.

Next, define state management.