Generated banner for Expo Project Structure
Generated logo for Expo Project Structure

Expo Project Structure

ExpoOfficialPublished by Expo

  • Skill
  • Guidelines
  • Software development
  • MIT
  • Low risk

From the author

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.
— the description by Expo

AutoGineer summary

Written by AutoGineer from the skill’s own files, not by the author

This skill provides a recommended directory layout for new Expo applications. It emphasizes separating configuration files from source code, maintaining a clean routes-only structure in the app directory, and using specific patterns for reusable components, screen-specific logic, and server-side API routes. It is intended strictly for new projects to establish a consistent foundation from the start.

What it does

  • Defines a standard directory hierarchy for Expo projects using src/.
  • Separates routing logic from reusable UI components and screen bodies.
  • Provides a strategy for organizing server-side API routes and helpers.
  • Outlines conventions for platform-specific code using file extensions.
  • Encourages colocating tests and styles with their respective components.
  • Establishes a clear separation between project configuration and application source code.

When to use it

  • When initializing a brand new Expo project.
  • When deciding where to place a new file in a project that follows this structure.
  • When you need to organize complex screen UI that has outgrown route files.
  • When implementing server-side API routes within an Expo Router application.

Advantages

  • Promotes consistency across new Expo codebases.
  • Keeps the routing layer clean by separating it from business logic and UI components.
  • Simplifies platform-specific development through file extension conventions.
  • Improves maintainability by colocating related tests and styles.

Usage examples

“How should I structure my new Expo project folders?”
The agent will provide the recommended directory tree, explaining the purpose of folders like src/app, src/components, and src/screens.
“Where should I put my server-side API routes in an Expo Router app?”
The agent will advise placing them in src/app/api/ and using the +api suffix for route files.
“How do I handle platform-specific components in my Expo project?”
The agent will explain the use of file extensions like .web.tsx or .native.tsx to allow Metro to select the correct implementation.

Install

  1. Download the skill as a ZIP:

    https://autogineer.com/agent-skills/expo/expo-project-structure/download
  2. Unzip it into the cross-client skills folder of your project:

    mkdir -p .agents/skills && unzip expo-project-structure.zip -d .agents/skills

Documentation by Expo

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 @expo/agent-cli@latest feedback --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 agent repeatedly fails at an Expo task or the user has to step in, submit a brief report of the task, expected result, and what went wrong using --category evals and the relevant Expo package or command as --subject.

Files

SKILL.md

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 @expo/agent-cli@latest feedback --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 agent repeatedly fails at an Expo task or the user has to step in, submit a brief report of the task, expected result, and what went wrong using --category evals and the relevant Expo package or command as --subject.

Requirements and compatibility

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta

“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.

Needs: Needs Node.js

Security

What our scanner noticed· Low risk

  • Instructions that use the network

A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.

Attribution and licence

Published by
Expo
Publisher
Expo (Official)
Source
expo/skills · plugins/expo/skills/expo-project-structure · commit a9e5bd3
Licence
MIT License (redistribution allowed)
  • LICENSE (added by AutoGineer from plugins/expo/LICENSE)
  • ATTRIBUTION.md (written by AutoGineer)
Synced

AutoGineer is not affiliated with or endorsed by Expo or Expo.

Download ZIP

The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download expo-project-structure.zip