Layout nodes

Layout nodes wrap the pages beneath them. Use a layout for structure several pages should share rather than repeat — navigation, headers, shells, and providers that need to survive a route change. On the Structure tab a route declares a layout over everything below it with a single mark, so a layout is a property of the tree rather than a box drawn beside it.

Nesting

Layouts nest, so a page inherits every layout above it in the tree. That matches how the App Router composes layouts around a route: the outermost layout renders first and each nested one renders inside it. A layout node maps to app/<path>/layout.tsx, alongside the pages it wraps, and a (group) segment lets sibling routes share a layout without that grouping appearing in their URLs.

Because a layout persists across navigations within its subtree, it is also the right home for state that should not reset when a user moves between sibling pages — a media player, a wizard's progress, an open sidebar.

In the graph

Layouts belong to the Routes view with pages, so both appear on the same board and can be arranged together. A guarded layout generates a real role check like a guarded page does — and because the layout wraps everything beneath it, that one check protects the whole subtree in the generated code, following the guard behaviour described in security concepts.

Scaffolding emits layouts outermost-first in its build order, ahead of the pages they contain, so each page is implemented inside shells that already exist.

Other targets

Other targets keep the idea under a different name — on Mobile a layout becomes an Expo Router _layout.tsx navigator, the file that decides whether its children stack, tab, or drawer. Terminal and Extension projects have shallower trees, but shared wrapping works the same way.