Mobile Navigation: Stack, Tab, Drawer & Deep Linking

Q: When should I use stack vs tab vs drawer navigation?

Use a stack for hierarchical, drill-in flows (list → detail → edit). Use tabs for a few co-equal top-level sections users switch between freely (Home/Search/Profile). Use a drawer for secondary or less-frequent destinations (settings, help) that don't deserve permanent tab space. Most apps combine them — commonly tabs as the root with stacks inside each tab, and a stack wrapping everything for full-screen pushes.

Q: How do I handle deep linking?

Define a URL-to-screen mapping (React Navigation's linking config or go_router routes) and register your URL scheme/universal links in the native config (AndroidManifest intent-filters, iOS associated domains). Then a URL like myapp://profile/123 resolves to the right screen with parsed params. Set this up early — it influences how you name routes and structure params, and retrofitting it is disruptive.

Mobile Navigation Patterns

Mobile navigation differs fundamentally from the web: there's no URL bar, users expect platform-specific gestures (iOS swipe-back, Android hardware back), and screens form stacks and tabs rather than pages. Getting navigation right is core to an app feeling native — and getting its state right (so it never drifts out of sync) is core to it not breaking.

The vocabulary is small and shared across frameworks: stack for hierarchical flows, tabs for parallel top-level sections, drawer for secondary destinations, and modals for focused tasks — plus deep linking so external URLs open the right screen.

TL;DR

Stack navigation for hierarchical flows.
Tab navigation for top-level sections.
Drawer for secondary actions.
Deep linking for external entry points.

Quick Example

React Navigation — a stack pushes and pops screens, passing params along:

Navigation Types & Platform Differences

Stack — push/pop screens (Login → Home → Profile).
Tab — bottom/top tabs for parallel sections.
Drawer — side menu for settings, help.
Modal — overlays for focused tasks.

💡 Respect platform conventions: iOS uses swipe-from-left to go back and slides modals up; Android has a hardware/gesture back button and a left drawer. Navigation libraries handle most of this for you.

React Navigation

A very common structure is tabs nested inside a stack — so a detail screen pushes over the whole tab bar:

Flutter Navigation

A bottom navigation bar switches the displayed screen via state:

Deep Linking

Map external URLs to screens so myapp://profile/123 opens the right place:

In Flutter, go_router's path params handle the routing; you also register the URL scheme in the native manifests (e.g. an Android intent-filter).

Best Practices

Keep navigation state predictable — let the library own it; avoid global singletons that desync.
Match platform conventions — swipe-back on iOS, hardware back on Android.
Use nested navigators deliberately (tabs-in-stack) rather than deeply tangled trees.
Set up deep linking early — it affects route structure and is painful to retrofit.
Pass minimal params — IDs, not whole objects; fetch details on the destination screen.

Common Mistakes

Duplicating navigation state in global state

Passing large objects as route params

FAQ

How is mobile navigation different from web routing?

The web has a single URL representing the current page and a linear history; mobile apps have multiple navigation structures at once — a stack of screens within a tab, within a drawer — plus platform gestures (iOS swipe-back, Android hardware back) and no visible address bar. Navigation libraries model these nested stacks and platform behaviors, which is why you use React Navigation or go_router rather than treating it like web routing.

When should I use stack vs tab vs drawer navigation?

Use a stack for hierarchical, drill-in flows (list → detail → edit). Use tabs for a few co-equal top-level sections users switch between freely (Home/Search/Profile). Use a drawer for secondary or less-frequent destinations (settings, help) that don't deserve permanent tab space. Most apps combine them — commonly tabs as the root with stacks inside each tab, and a stack wrapping everything for full-screen pushes.

How do I handle deep linking?

Define a URL-to-screen mapping (React Navigation's linking config or go_router routes) and register your URL scheme/universal links in the native config (AndroidManifest intent-filters, iOS associated domains). Then a URL like myapp://profile/123 resolves to the right screen with parsed params. Set this up early — it influences how you name routes and structure params, and retrofitting it is disruptive.

Should navigation state live in my global state manager?

No — let the navigation library own route state as the single source of truth. Mirroring the current route into Redux/Provider invariably leads to the two drifting out of sync, producing wrong-screen renders and broken back behavior. If other code needs to react to navigation, subscribe to the navigator's state or use its hooks rather than duplicating it.