React Native Navigation Patterns: Building Multi-Screen Apps

Your first React Native screen is easy. The second one changes everything.

The moment you add screen two, you inherit a whole category of decisions: how does the user get there, how do they come back, does the header travel with them, should there be a tab bar, what happens on the Android back button, and does a swipe-from-left gesture pop the screen or open a drawer? These are not visual questions. They are navigation pattern questions, and getting them wrong is why so many prototype apps feel off even when every individual screen looks clean.

This guide is a practical walkthrough of the react native navigation patterns you will actually reach for when building multi-screen apps — stack, tabs, drawer, and modals — plus how to nest them, pass state between them, and (if you use RapidNative) how to describe the navigation you want in plain English and get it generated correctly on the first try.

The navigation shell is what makes disconnected screens feel like one app — Photo by Rob Hampson on Unsplash

What are react native navigation patterns?

React native navigation patterns are reusable ways of moving a user between screens in a React Native or Expo app. The four you will use in over 95% of apps are stack navigation (push/pop with a back button), tab navigation (persistent bottom bar), drawer navigation (side menu), and modal navigation (screens that slide up over the current screen). Real apps nest these together — for example, a bottom tab layout where each tab has its own stack.

Most React Native apps use the React Navigation library or the newer file-based Expo Router, which is built on top of React Navigation. Both offer the same primitives; they differ mainly in how you define your routes.

The four patterns you will actually reach for

1. Stack navigation

Stack navigation is the default push/pop model, exactly like the browser history but for screens. You push a new screen onto the top of the stack; the back button (or a left-edge swipe on iOS) pops it back off. The header travels with the top screen and typically shows a back arrow automatically.

Use it when: the user is drilling down into detail — feed → post → comments → user profile → their other posts. Anything that follows a "parent → child" content hierarchy is a stack.

Common mistake: trying to fake stack behavior with setState and conditional rendering. You lose the built-in back button, gesture, transition animation, and header. Use a real navigator.

In React Navigation you would use createNativeStackNavigator for iOS-native transitions and Android's default animations, giving you the platform-correct feel for free.

2. Tab navigation

Bottom tabs give users a persistent home base. Tapping a tab switches sections; tapping the same tab twice usually returns to that section's root. The tab bar stays visible while you navigate inside a section, which is why almost every social, e-commerce, and productivity app uses this pattern.

Use it when: your app has 3–5 top-level areas that are equally important and unrelated — Feed, Search, Post, Notifications, Profile.

Common mistake: using more than 5 tabs. Beyond that, users cannot scan the icons quickly and one tab always becomes "everything else." Consolidate into a menu or drawer instead.

Also: tabs should never lose their scroll position or drilled-in state when you switch tabs. If your Search tab resets to the top every time you leave and come back, users notice, and it feels broken.

A well-designed bottom tab bar is the single highest-leverage navigation decision in most consumer apps — Photo by Rodion Kutsaiev on Unsplash

3. Drawer navigation

A side drawer is a hidden menu you swipe or tap open from the left (or right). It exposes secondary destinations without cluttering the main screen.

Use it when: you have a small number of primary destinations (fits in tabs) plus a longer tail of secondary destinations — Settings, Help, Feedback, Legal, Sign Out, Switch Team, Archived Items, Preferences. Drawers are also a good fit for B2B and admin-style apps where deep navigation matters more than thumb reach.

Common mistake: using a drawer as your primary navigation. Drawer items are hidden by default, and hidden means unused. If a destination matters, it belongs in tabs.

4. Modal navigation

Modals slide up from the bottom (or fade in) and cover the current screen. Unlike stack push, a modal is understood as a temporary interruption you will explicitly dismiss.

Use it when: you need a focused, self-contained task — compose a message, capture a photo, sign in, confirm a checkout. Modals also work well for filters, share sheets, and quick pickers.

Common mistake: using a modal for anything the user might want to navigate away from without finishing. Modals imply commitment; a nested stack does not.

A decision framework: which pattern for which screen?

Here is the shortcut I use before writing any code (or before writing any prompt for RapidNative):

This is the single most useful thing to internalize: navigation type follows the user's intent, not the visual design.

Nesting: how real apps combine navigators

Almost no real app uses a single navigator. The typical shape looks like this:

• Root: Stack — holds the auth screens and, once signed in, hands off to the app.
  • Auth Stack: Welcome → Sign In → Sign Up → Forgot Password.
  • Main: Tabs
    • Home tab: Stack — Feed → Post → Comments.
    • Search tab: Stack — Search → Results → Detail.
    • Notifications tab: Stack — List → Detail.
    • Profile tab: Stack — Profile → Settings → Sub-settings.
  • Global modals — Compose, Onboarding, Sign In prompt.

The rule of thumb: every tab gets its own stack. That way each tab remembers where the user was, and drilling down inside a tab does not affect the other tabs. Modals live at the root (or above tabs) so they can appear over anything.

If you are using Expo Router, this maps almost 1:1 to the file structure:

app/
  (auth)/
    _layout.tsx    // auth stack
    sign-in.tsx
    sign-up.tsx
  (tabs)/
    _layout.tsx    // tabs layout
    index.tsx
    search.tsx
    profile.tsx
  post/
    [id].tsx       // detail screen inside home tab's stack
  compose.tsx      // presented as a modal at root

The (tabs) folder is a route group with its own layout, and [id].tsx is a dynamic route. This file-based approach is what RapidNative-generated projects use — the official Expo Router docs go deep on the notation.

Passing state between screens

Once you have multiple screens, you need to hand data across them. There are three main ways, in the order you should reach for them:

1. Route params — the simplest. navigation.navigate('Post', { postId: '123' }), then read it inside the screen with useLocalSearchParams (Expo Router) or route.params (React Navigation). Best for identifiers, not full objects.
2. A shared store — Context, Zustand, Redux, or Jotai. Any state that more than one screen cares about (auth user, cart, current filters, theme) lives here. This is what most RapidNative-generated apps use for cross-screen state.
3. Callback params — pass a function through params to run when a child screen completes. Useful for "pick something and return it," but avoid overusing this pattern; it makes the navigation graph hard to reason about.

Anti-pattern to avoid: cramming the entire app state into params. Route params get serialized into the URL for deep linking, so anything non-trivial breaks. Keep params tiny.

Deep linking, the back button, and the details that make an app feel real

Three things quietly separate a prototype from a real app:

• Deep linking — tapping yourapp://post/123 (or a universal link like https://yourapp.com/post/123) opens the app directly on that screen with the correct back stack. Both React Navigation and Expo Router support this via a linking config; Expo Router does it automatically from your file structure.
• The Android hardware back button — must pop the stack, close the modal, or exit the app in that order. React Navigation handles this correctly by default if you are inside a real navigator. This is another reason not to fake stack navigation with state.
• Safe areas — headers should sit below the notch and tab bars above the home indicator. Wrap your app in a SafeAreaProvider and let the navigators handle insets.

Deep linking, back button behavior, and safe areas are invisible when done right — and screaming when done wrong — Photo by Kelly Sikkema on Unsplash

Prompting RapidNative to generate the navigation you want

RapidNative turns natural-language prompts into working React Native and Expo apps, and it makes navigation choices based on what you describe. If you are vague, it will default to a sensible layout — usually bottom tabs plus per-tab stacks. If you want a specific structure, name it.

Here are three prompting patterns that consistently work:

Pattern 1 — Say what kind of app it is. RapidNative recognizes app archetypes and picks matching navigation.

Prompt: A food delivery app with a Home feed of restaurants, a Search screen, an Orders tab, and a Profile tab. Tapping a restaurant opens its menu, and tapping a menu item opens a customization screen.

That gives you: 4 bottom tabs, each with its own stack, restaurant detail pushed onto the Home stack, item customization pushed onto the restaurant detail.

Pattern 2 — Name the pattern explicitly. If you want a drawer, an onboarding flow as a modal, or a specific pattern, ask for it directly.

Prompt: Include a left drawer with Settings, Help, and Sign Out. The initial sign-in flow should appear as a modal on top of the app.

Pattern 3 — Describe the flow, not the pages. Instead of listing screens, describe what the user does. The navigator shape falls out.

Prompt: A three-step onboarding: welcome → pick a goal → enter your name. Then land the user on the main app. The user should not be able to swipe back into onboarding once complete.

RapidNative will typically implement this as a modal onboarding stack that is dismissed and replaced by the main tab navigator on completion — the exact behavior you want. If you want to see this in action without writing anything from scratch, our whiteboard mode lets you sketch the flow and the app generates around it.

Iterating on navigation without regenerating your app

Once the app exists, you rarely regenerate it. You edit. Point-and-edit lets you click a tab bar, a header, or a screen and describe the change: "Add a fifth tab for Wishlist," "Make this drawer open from the right," "Convert this screen to a modal presentation." The generated navigator code updates in place, and the live preview reloads on the next tap.

Common navigation pitfalls (and how to avoid them)

• Too many tabs. Cap at 5. If you have more, promote 3–5 to tabs and put the rest in a Profile-tab settings screen or drawer.
• Modal for a non-committal task. If the user might want to poke around before deciding, that is not a modal — that is a screen.
• Losing tab state on switch. Each tab needs its own stack, and switching tabs must preserve scroll and drilled-in state.
• Hidden primary destinations in a drawer. If it matters, it belongs in tabs. Drawers hide.
• Reinventing the header. React Navigation's headers do 90% of what you need. Configure them via screenOptions rather than replacing them.
• No loading state on the shell. When your app opens, the tabs and header should render immediately even if the content inside is still fetching. Users read the shell to know the app is alive.

People Also Ask

What is the difference between a stack and a modal in React Native?

A stack pushes a new screen onto a horizontal history, with a header, a back button, and a right-to-left slide transition. A modal presents a screen over the current one, usually sliding up from the bottom, and is dismissed as a discrete action rather than "going back." Use a stack for content drill-down and a modal for a self-contained task the user must complete or cancel.

Should I use React Navigation or Expo Router?

For new apps, Expo Router is the modern default — it is built on React Navigation but uses file-based routing that matches the Next.js mental model, gets deep linking almost for free, and is the pattern RapidNative-generated projects use. Stick with plain React Navigation if you are inside an existing bare React Native project or need highly custom navigation containers.

How many screens should a mobile app have?

There is no upper limit — the constraint is the depth of any single flow. As a rule of thumb, keep any drill-down flow within 3–4 pushes before the user needs to reset via a tab tap. Total screen count in a real production app is often 30–100+; navigation patterns exist precisely so this scales without the user feeling lost.

Can AI actually build multi-screen apps with correct navigation?

Yes — but the quality depends on how the tool represents navigation. RapidNative treats navigation as first-class structure in its generation pipeline (see our post on how RapidNative handles navigation and routing) rather than gluing screens together with conditional rendering, which is why it produces working stacks, tabs, drawers, and modals rather than fake ones.

Conclusion

Multi-screen navigation is where React Native apps stop feeling like a demo and start feeling like an app. Get the four patterns right — stack for drill-down, tabs for top-level areas, drawer for secondary destinations, modal for focused tasks — nest them so each tab keeps its state, respect deep links and the Android back button, and pass state through a shared store rather than route params.

If you are using RapidNative, the fastest path is to describe the app in terms of what the user does, name the pattern when you want one specifically, and iterate with point-and-edit rather than rebuilding. You will get a real, exportable Expo project on the other side — not a mock — with navigation that works on device, respects platform conventions, and holds up when your app grows past its first two screens.

Try it: Sketch or describe your multi-screen app on rapidnative.com and watch the navigation get generated in real time. If you want to skip straight to a starting point, our PRD-to-app mode lets you paste a spec and get the full navigator wired up for you.