Expo project structure skill

Folder structure for a new Expo app.

by expo·MIT license·★ 2,657 Stars on the repo·GitHub ↗

Use now

Files of Expo project structure

expo/main1 file shown
SKILL.md
Show the full text115 lines

Expo Project Structure

A starting skeleton for a new Expo app — one with no committed folder structure yet.

Apply only to new projects. If the app already has a layout, follow its existing conventions and leave files where they are — a default to start from, never a standard to enforce or migrate toward. When unsure whether a project is new, ask before moving anything.

The whole layout, assembled from the rules below:

├── assets/
├── scripts/
├── src/
│   ├── app/                       # Expo Router routes ONLY — every file is a route
│   │   ├── api/                   #   server API routes, grouped here
│   │   │   ├── user+api.ts
│   │   │   └── settings+api.ts
│   │   ├── _layout.tsx
│   │   ├── _layout.web.tsx         #   platform-specific layout
│   │   ├── index.tsx
│   │   └── settings.tsx
│   ├── components/                 # reusable UI: button, card, table…
│   │   ├── table/                  #   complex component → folder + index.tsx
│   │   │   ├── cell.tsx
│   │   │   └── index.tsx
│   │   ├── bar-chart.tsx
│   │   ├── bar-chart.web.tsx        #   platform-specific variant
│   │   └── button.tsx
│   ├── screens/                    # screen bodies that route files render
│   │   ├── home/
│   │   │   ├── card.tsx            #   used only by Home — not shared
│   │   │   └── index.tsx           #   rendered by src/app/index.tsx
│   │   └── settings.tsx
│   ├── server/                     # server-only helpers used by app/api
│   │   ├── auth.ts
│   │   └── db.ts
│   ├── utils/                      # standalone helpers + colocated tests
│   │   ├── format-date.ts
│   │   └── format-date.test.ts
│   ├── hooks/                      # reusable hooks: use-theme.ts…
│   ├── constants.ts
│   └── theme.ts
├── app.json
├── eas.json
└── package.json

src/ and src/app

Keep app code under src/ to separate it from config files. Expo Router supports both app/ and src/app/ out of the box — to switch, move the folder and restart the bundler. The default template aliases @/* to ./src/* in tsconfig.json.

src/app is routes-only: every file there becomes a route, so nothing else belongs in it. Everything below lives in sibling folders.

components/ — reusable UI

Generic, reused UI (button, card, table) with one named export each. Name files in kebab-case (bar-chart.tsx), matching the default create-expo-app template. When a component grows, give it its own folder with the root in index.tsx and colocate its private sub-components beside it — the import path (@/components/table) stays unchanged.

screens/ — screen bodies

Because app/ files must be routes, complex screen UI that isn't reused has no home there. Once a screen grows big enough to need breaking out to separate components, put it in screens/ and let each route just render its screen:

import { Home } from "@/screens/home";

export default function HomeScreen() {
  // route-specific concerns only — e.g. read url params here
  return <Home />;
}

Colocate a screen's private components inside its folder (screens/home/components/). A bonus: the same screen can render under multiple routes.

server/ + app/api/ — separate server code

Appending +api to a file in app/ makes it a server API route. Server code is different from frontend code — it runs in a Node-like server environment (deployed with EAS Hosting or on third-party services) and can read secret env vars (process.env.X, not just EXPO_PUBLIC_*). Keep it apart:

  • Group all routes under app/api/ → /api/user, /api/settings. This colocates them and avoids collisions (e.g. a /user screen and a /user route).
  • Put shared server-only helpers in src/server/.
  • Consider ESLint rules that fence +api files and server/ off from frontend-only checks.

Platform-specific code

Small differences: use Platform.select / Platform.OS. For larger ones, split into platform files instead of inline if/else — bar-chart.tsx + bar-chart.web.tsx, imported extension-free (@/components/bar-chart); Metro picks the right file per target.

  • Props must be identical across variants.
  • A default file (no platform extension) is always required — make it a no-op if the component is single-platform.
  • Supported extensions: .ios, .android, .native, .web.

Colocate styles and tests

  • Styles: keep the StyleSheet.create({ ... }) object at the bottom of the component file rather than in a separate .styles file.
  • Tests: put format-date.test.ts next to format-date.ts (preferred over a separate __tests__/ folder) so tested files are obvious at a glance.

AI and config files

Agent instructions live at the repo root — AGENTS.md / CLAUDE.md, with project skills under .claude/. Other config and assets stay outside src/: app.json / app.config.ts, eas.json, package.json, assets/, and scripts/.


Based on Expo app folder structure best practices by Kadi Kraman. For src/ precedence and alias mechanics, see the Expo docs.

Submitting Feedback

If you encounter errors, misleading or outdated information in this skill, report it so Expo can improve:

npx --yes submit-expo-feedback@latest --category skills --subject "expo-project-structure" "<actionable feedback>"

Only submit when you have something specific and actionable to report. Include as much relevant context as possible. If an AI agent repeatedly failed or the user had to take over an Expo task, load the expo-skill-feedback skill and follow its eval-candidate flow instead of reusing the command above.

1---
2name: expo-project-structure
3description: Folder structure for a new Expo app. Use when scaffolding or laying out a new Expo project with Expo Router, or deciding where a file should live in one. For new projects only — never restructure an existing app to match.
4version: 1.0.0
5license: MIT
6---
7 
8# Expo Project Structure
9 
10A starting skeleton for a **new** Expo app — one with no committed folder structure yet.
11 
12**Apply only to new projects.** If the app already has a layout, follow its existing conventions and leave files where they are — a default to start from, never a standard to enforce or migrate toward. When unsure whether a project is new, ask before moving anything.
13 
14The whole layout, assembled from the rules below:
15 
16```
17├── assets/
18├── scripts/
19├── src/
20│ ├── app/ # Expo Router routes ONLY — every file is a route
21│ │ ├── api/ # server API routes, grouped here
22│ │ │ ├── user+api.ts
23│ │ │ └── settings+api.ts
24│ │ ├── _layout.tsx
25│ │ ├── _layout.web.tsx # platform-specific layout
26│ │ ├── index.tsx
27│ │ └── settings.tsx
28│ ├── components/ # reusable UI: button, card, table…
29│ │ ├── table/ # complex component → folder + index.tsx
30│ │ │ ├── cell.tsx
31│ │ │ └── index.tsx
32│ │ ├── bar-chart.tsx
33│ │ ├── bar-chart.web.tsx # platform-specific variant
34│ │ └── button.tsx
35│ ├── screens/ # screen bodies that route files render
36│ │ ├── home/
37│ │ │ ├── card.tsx # used only by Home — not shared
38│ │ │ └── index.tsx # rendered by src/app/index.tsx
39│ │ └── settings.tsx
40│ ├── server/ # server-only helpers used by app/api
41│ │ ├── auth.ts
42│ │ └── db.ts
43│ ├── utils/ # standalone helpers + colocated tests
44│ │ ├── format-date.ts
45│ │ └── format-date.test.ts
46│ ├── hooks/ # reusable hooks: use-theme.ts…
47│ ├── constants.ts
48│ └── theme.ts
49├── app.json
50├── eas.json
51└── package.json
52```
53 
54## `src/` and `src/app`
55 
56Keep app code under `src/` to separate it from config files. Expo Router supports both `app/` and `src/app/` out of the box — to switch, move the folder and restart the bundler. The default template aliases `@/*` to `./src/*` in `tsconfig.json`.
57 
58`src/app` is **routes-only**: every file there becomes a route, so nothing else belongs in it. Everything below lives in sibling folders.
59 
60## components/ — reusable UI
61 
62Generic, reused UI (button, card, table) with one named export each. Name files in **kebab-case** (`bar-chart.tsx`), matching the default `create-expo-app` template. When a component grows, give it its own folder with the root in `index.tsx` and **colocate** its private sub-components beside it — the import path (`@/components/table`) stays unchanged.
63 
64## screens/ — screen bodies
65 
66Because `app/` files must be routes, complex screen UI that isn't reused has no home there. Once a screen grows big enough to need breaking out to separate components, put it in `screens/` and let each route just render its screen:
67 
68```tsx
69import { Home } from "@/screens/home";
70 
71export default function HomeScreen() {
72 // route-specific concerns only — e.g. read url params here
73 return <Home />;
74}
75```
76 
77**Colocate** a screen's private components inside its folder (`screens/home/components/`). A bonus: the same screen can render under multiple routes.
78 
79## server/ + app/api/ — separate server code
80 
81Appending `+api` to a file in `app/` makes it a server **API route**. Server code is different from frontend code — it runs in a Node-like server environment (deployed with EAS Hosting or on [third-party services](https://docs.expo.dev/router/web/api-routes/#hosting-on-third-party-services)) and can read secret env vars (`process.env.X`, not just `EXPO_PUBLIC_*`). Keep it apart:
82 
83- Group all routes under `app/api/` → `/api/user`, `/api/settings`. This colocates them and avoids collisions (e.g. a `/user` screen and a `/user` route).
84- Put shared server-only helpers in `src/server/`.
85- Consider ESLint rules that fence `+api` files and `server/` off from frontend-only checks.
86 
87## Platform-specific code
88 
89Small differences: use `Platform.select` / `Platform.OS`. For larger ones, split into platform files instead of inline `if/else` — `bar-chart.tsx` + `bar-chart.web.tsx`, imported extension-free (`@/components/bar-chart`); Metro picks the right file per target.
90 
91- Props must be identical across variants.
92- A default file (no platform extension) is always required — make it a no-op if the component is single-platform.
93- Supported extensions: `.ios`, `.android`, `.native`, `.web`.
94 
95## Colocate styles and tests
96 
97- **Styles:** keep the `StyleSheet.create({ ... })` object at the bottom of the component file rather than in a separate `.styles` file.
98- **Tests:** put `format-date.test.ts` next to `format-date.ts` (preferred over a separate `__tests__/` folder) so tested files are obvious at a glance.
99 
100## AI and config files
101 
102Agent instructions live at the repo root — `AGENTS.md` / `CLAUDE.md`, with project skills under `.claude/`. Other config and assets stay outside `src/`: `app.json` / `app.config.ts`, `eas.json`, `package.json`, `assets/`, and `scripts/`.
103 
104---
105 
106Based on [Expo app folder structure best practices](https://expo.dev/blog/expo-app-folder-structure-best-practices) by Kadi Kraman. For `src/` precedence and alias mechanics, see the [Expo docs](https://docs.expo.dev/router/reference/src-directory/).
107 
108## Submitting Feedback
109If you encounter errors, misleading or outdated information in this skill, report it so Expo can improve:
110```bash
111npx --yes submit-expo-feedback@latest --category skills --subject "expo-project-structure" "<actionable feedback>"
112```
113Only submit when you have something specific and actionable to report. Include as much relevant context as possible.
114If an AI agent repeatedly failed or the user had to take over an Expo task, load the expo-skill-feedback skill and follow its eval-candidate flow instead of reusing the command above.
115 

Discussion

Alternatives

`expo-overview` — router & shared rules for Expo / EASEntry point and router for every Expo or EAS task. Load this skill first — before writing code and before choosing another expo-* / eas-* skill — when the request, PRD, or spec mentions Expo, EAS, Expo Go, or an expo-* package, or the project has an `expo` dependency in `package.json`. Within that gate it also covers app specs and designs to implement (tabs, stacks, maps, lists, navigation, building from a screenshot), and phrasings like 'implement a mobile app', 'make my app look native', 'add navigation', 'fetch some data', 'upgrade my SDK', 'add Expo to my existing native app', 'ship to the App Store', or 'I'm new to Expo, where do I start'. A fully specified request (SDK pinned, libraries named, layout given) still routes through here — the shared setup rules still apply. Do NOT load it when neither signal is present: a bare React Native project with no `expo` dependency is not Expo work. Detects the real goal, routes to the right expo-* / eas-* skill, and owns the shared setup rules.Coding · MITAdd an App Clip to an Expo AppAdd an iOS App Clip target to an Expo app. Use when the user mentions App Clip, AASA, apple-app-site-association, appclips, smart app banner, or wants to ship a lightweight iOS Clip invoked from a URL alongside their parent app.Coding · MITApp Store DeploymentBuild and submit iOS and Android apps with EAS to TestFlight, the App Store, or Google Play. Supports Expo and other React Native projects, plus existing native apps. Use for eas.json setup, release pipelines, signing, app versions and build numbers, store submissions, and listing metadata. For Expo websites and API routes, use eas-hosting; for adding React Native screens to a native app, use expo-brownfield.Coding · MITDesigning with SleekUse when the user wants to design a mobile app or UI screens, when they mention their Sleek (sleek.design) projects, or when implementing Sleek designs in code (HTML, React Native, SwiftUI).Coding · MIT