# The Designer's Case for File-Based Routing in React Native

* * *

## tags: react-native, expo, mobile-development, design, developer-experience seoTitle: "File-Based Routing in React Native: A Designer's Case" seoDescription: "."

Most posts about Expo Router are written for engineers. This one is for designers who work with engineers, or for design-forward founders trying to pick a stack. Here's why file-based routing changed how I collaborate on React Native apps.

## Why designers should care about routing

Routing sounds like an engineering concern, and traditionally it is. But the choice of routing library shapes:

*   How fast a new person (designer, PM, contractor) can read what an app does.
    
*   How quickly a design change turns into a shipped screen.
    
*   Whether the design system stays consistent across the app or drifts screen-by-screen.
    

File-based routing improves all three.

## Reading a codebase without asking

Open any Expo Router project's `app/` folder. You immediately see the app's information architecture:

```plaintext
app/
  index.tsx
  settings.tsx
  (tabs)/
    home.tsx
    discover.tsx
    profile.tsx
  post/
    [id].tsx
    new.tsx
```

That IS the app's map. No engineer has to explain "we use React Navigation with a nested stack inside a tab navigator, and the modals are configured over here in `AppNavigator.tsx`." The folders are the map.

> For a new designer joining a project, this alone saves days of ramp-up.

## Prototype to shipped: the path shortens

Traditional React Native workflow:

1.  Designer ships a Figma frame for a new screen.
    
2.  Engineer creates the file, wires it into the navigator, updates the routes file, updates any deep-link config, tests all of that.
    
3.  Designer reviews.
    

Expo Router workflow:

1.  Designer ships a Figma frame for a new screen.
    
2.  Engineer creates `app/that-screen.tsx`. That's it: the URL, deep link, and navigation are configured.
    
3.  Designer reviews.
    

The wiring step is gone. In practice this shortens the design-to-shipped-review loop by hours per screen. Over a launch cycle with 20 to 30 screens, that's real time.

This is also why AI-native builders lean on the same convention. [RapidNative](https://rapidnative.com/?utm_source=hashnode&utm_medium=blog&utm_campaign=designers-case-file-based-routing-react-native) generates Expo apps with file-based routing out of the box, so a screen described in plain language lands in the project already wired: no navigator surgery afterward.

## Design-system-friendly layouts

`_layout.tsx` files are React components that wrap everything below them. That means:

*   **Fonts, theme, color-mode context** all live in `app/_layout.tsx` and every screen inherits them.
    
*   **Tab bar styling** lives in `app/(tabs)/_layout.tsx` and every tab inherits it.
    
*   If your design system needs "every screen in the auth flow has a specific header treatment," `app/(auth)/_layout.tsx` is the one place to enforce it.
    

Compare that to imperative navigation, where tab-bar styling is often duplicated across screens or fought about in code reviews.

> The layout file turns a design-system rule into a single enforceable location instead of a convention you hope everyone follows.

This structure is one reason generated codebases stay legible. When a tool like [RapidNative](https://rapidnative.com/?utm_source=hashnode&utm_medium=blog&utm_campaign=designers-case-file-based-routing-react-native) scaffolds theme and layout files at the top of the tree, every screen it adds later inherits the same tokens instead of accumulating one-off styles.

## What still needs a designer's push

File-based routing doesn't fix everything. Two things I still push for on every Expo Router project:

1.  **A design tokens file next to the router.** Even a `src/design/tokens.ts` counts. Colors, spacing scale, typography scale. Every custom-styled Button downstream is technical debt.
    
2.  **Documented modal patterns.** Expo Router's modals work, but the when-to-use-a-modal-vs-a-full-screen-vs-a-sheet decision is still a design system question. Document it once, don't relitigate per feature.
    

If you'd rather start from a project where those defaults already exist, [RapidNative](https://rapidnative.com/?utm_source=hashnode&utm_medium=blog&utm_campaign=designers-case-file-based-routing-react-native) ships Expo Router projects with a tokens structure in place, which makes the designer's-push list shorter on day one.

The takeaway: file-based routing isn't just an engineering ergonomics win. It genuinely changes how designers and engineers collaborate on React Native apps. If you're picking a stack for a new project in 2026, this is one of the reasons Expo Router should be the default.