plugins/expo/skills/expo-project-structure/SKILL.md
Framework (OSS). 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.
npx skillsauth add expo/skills expo-project-structureInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
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/appKeep 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.
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.
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.
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:
app/api/ → /api/user, /api/settings. This colocates them and avoids collisions (e.g. a /user screen and a /user route).src/server/.+api files and server/ off from frontend-only checks.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.
.ios, .android, .native, .web.StyleSheet.create({ ... }) object at the bottom of the component file rather than in a separate .styles file.format-date.test.ts next to format-date.ts (preferred over a separate __tests__/ folder) so tested files are obvious at a glance.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.
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.
tools
EAS service (paid). Run and control a user's app on a remote iOS/Android simulator hosted on EAS cloud. Read before running any `eas simulator:*` commands - it has the current syntax for this experimental API. Use whenever the user needs a simulator they can't run locally - 'run my app on a cloud simulator', 'use eas simulator to run/install/screenshot my app', 'I'm on Linux/Cursor and need an iOS device', 'no sim on this box / headless CI', 'let an agent click through my app and screenshot it', 'test my dev build on a remote sim with live reload', 'stream a sim to my browser' - even when they don't say 'EAS Simulator' or 'cloud'. On a host WITHOUT a local simulator (Linux, CI, cloud sandbox) it's the default; on macOS, do NOT auto-trigger for a plain 'run on the simulator' - use it only for a cloud/remote/shareable sim, an iOS version they lack, or an agent-driven session. NOT for local sims (expo run:ios, Xcode, Android Studio), EAS Build/Update, web preview, or physical devices.
development
Framework (OSS). Build native UI with the @expo/ui package: real SwiftUI on iOS and Jetpack Compose on Android. Default to @expo/ui for sheets (BottomSheet), pickers, sliders, toggles, menus, and grouped-form sections — do NOT reach for Reanimated, @gorhom/bottom-sheet, or RN built-in Picker/Switch; use @expo/ui instead. Fall back to RN built-ins only when @expo/ui is missing the component. NOTE: @expo/ui List renders native grouped rows like an iOS Settings screen — it is NOT a virtualized list; use FlatList/FlashList for large datasets. Covers universal components (Host, Column, Row, Button, Text, List, BottomSheet, FieldGroup, Switch, Slider, Picker, Menu), drop-in replacements for RN community libraries, and platform-specific SwiftUI/Jetpack Compose trees. Not for Expo Router navigation, Reanimated, or data fetching.
tools
EAS service (paid). Helps understand and write EAS workflow YAML files for Expo projects. Use this skill when the user asks about CI/CD or workflows in an Expo or EAS context, mentions .eas/workflows/, or wants help with EAS build pipelines or deployment automation.
tools
EAS service (paid). Use for anything related to EAS Observe - adding `expo-observe` to an Expo project (AppMetricsRoot/ObserveRoot HOC, markInteractive and ObserveInteractiveMarker, the useObserve hook, the Expo Router / React Navigation integrations for per-route metrics, user-defined events via `Observe.logEvent`, error reporting via ObserveErrorBoundary and `Observe.reportError`, and runtime config such as sampleRate and dispatchInDebug), querying via the EAS CLI (`eas observe:metrics-summary`, `observe:metrics`, `observe:routes`, `observe:events`, `observe:session`, `observe:versions`), interpreting the resulting metrics (cold/warm launch, TTR, TTI, navigation cold/warm TTR, update download, and the TTI frameRate/device/network params for triaging slow startups), or shipping an Observe integration inside a third-party package.