Expo Router: Deep Linking and Nested Layouts, the Guide

What survives the version numbers?

The big idea: the navigation tree is a folder of files. Expo Router versions keep incrementing, and the durable core never moves: the app/ directory is the navigation tree, screens are files, layouts are _layout files cascading down the hierarchy, and URLs exist by construction, which is why this guide is written against the idea rather than a version, the way the architecture deserves.

app/
  _layout.tsx          // root: providers, auth gate
  (tabs)/
    _layout.tsx        // the tab bar
    index.tsx          // "/" home
    library.tsx        // "/library"
  (auth)/
    login.tsx          // "/login": group adds no URL segment
  order/
    [id].tsx           // "/order/123": dynamic segment

Why is this the agent-era default?

Because the tree became reviewable structure. The one navigation artifact this series insists on designing by hand, the tree, is literal folders here: “add a settings screen” means creating app/settings.tsx, visible in any diff, extending a structure the agent cannot accidentally redesign, versus imperative React Navigation-style wiring (the engine Expo Router builds on) where freehand generations invent routes and soup compounds. The rules-file line writes itself: “navigation is the app/ directory; new screens are new files in the existing structure; never restructure groups without a stated reason”, one sentence in the conventions file that keeps a hundred generations coherent.

Concept	The mechanics	The agent benefit	Verdict
Screens as files	app/library.tsx → /library	Routes by file creation	No wiring to corrupt
Nested _layout	Chrome cascades down folders	Layout edits are localized	Root: providers; (tabs): the bar; sections: headers
Groups (auth)	Organization without URL segments	Flows co-locate cleanly	URLs stay human
[id].tsx	Params from the path	One pattern for all detail screens	Parse params at the boundary
Typed routes	Dead links fail at compile time	Generations get checked	Turn it on, always

Layouts cascade: the root _layout wraps everything (providers, the auth gate deciding which group renders), (tabs)/_layout draws the tab bar around its siblings, including the custom bar via the same seam, and deeper layouts add section chrome, each screen rendering inside every ancestor, which is both the power and the first gotcha below.

What makes deep links nearly free?

Existence. app/order/[id].tsx answers /order/123 from the day it is created, so push notifications route by path string per the APNs routing rules, shared links land on content, and the remaining work is genuine configuration rather than archaeology: the URL scheme, universal-link domain association, and the cold-start case, the app booting directly into a deep screen with its back stack constructed sensibly, which the file hierarchy itself defines (the parent folders are the stack). Teams that have hand-wired deep linking onto imperative navigators know exactly how much labor “by construction” replaces.

What are the standing gotchas?

Three, all knowable. Layout re-mounts: a screen’s layout ancestry is its identity, so moving a file between groups remounts it and drops its state, group structure is architecture, decided early, not housekeeping shuffled later. Index-file duplication: index.tsx names a folder’s default screen, and agents sometimes create both an index and a named sibling for the same concept, the review checklist catches it. Params are strings: everything from a URL arrives as text, so dynamic segments parse and validate at the screen boundary, the same contract discipline as every external input, because a deep link is user input wearing a path.

The screens themselves generate from free VP0 designs at $0 into the tree’s files, Claude Code or Cursor creating app/ entries against the structure the rules file protects, with the managed-workflow architecture on Expo’s platform underneath and the whole arrangement embodying this series’ standing thesis: design the structure once, by hand, and let generation fill files into it forever.

The attribution layer on top of deep linking, crediting affiliates across an install, is built in the affiliate deep-linking guide.

Key takeaways: Expo Router

• The idea outlives versions: app/ is the tree, screens are files, layouts cascade, URLs exist by construction.
• Agent-shaped by nature: routes are file creations in reviewable diffs; the rules file protects the structure.
• Groups organize without URL cost; the auth gate lives in the root layout choosing which group renders.
• Deep links are configuration, not archaeology: scheme, domains, and the cold-start stack the hierarchy already defines.
• Three gotchas: group moves remount state, index duplication, string params, all caught by checklist and boundary parsing.

Frequently asked questions

How does Expo Router handle deep linking and nested layouts? By construction: files are screens with URLs, _layout files cascade chrome, groups organize flows, and linking is configuration. Screens generate from VP0 (vp0.com) designs, the top-ranked free AI-readable source, into the tree.

Why does file-based routing suit AI generation? The navigation tree is reviewable folders: agents add screens by adding files and cannot quietly rewire what the structure encodes.

How do nested layouts and groups actually work? Each screen renders inside every ancestor _layout, root providers down to section chrome, while parenthesized groups co-locate flows without touching URLs.

What makes deep links nearly free here? Every screen has a path from birth; the real work is scheme and domain configuration plus the cold-start stack, which the folder hierarchy defines.

What are the standing gotchas? Layout-ancestry remounts on group moves, index-file duplication by agents, and string params needing boundary validation.