| name | expo-core |
| description | Shared reference for the Expo cluster: EAS (Build/Submit/Update/Hosting), app config + config plugins, the Expo Go vs dev-client vs prebuild/CNG spectrum, SDK version policy, and Expo Router structure. USE WHEN configuring an Expo app, planning an EAS release, or upgrading the SDK — the platform model every Expo spoke shares. Pairs with react-native-core for the underlying RN runtime. |
| cluster | expo |
| version | 1.0.0 |
Expo Core
Shared model for the expo cluster. The Expo spokes all sit on these concepts — keep them
consistent here. For the React Native runtime beneath Expo (New Architecture, Reanimated,
navigation), see react-native-core.
1. EAS — the cloud backbone
- EAS Build — cloud native builds (iOS/Android) without local Xcode/Android Studio. →
expo-cicd-workflows
- EAS Submit — upload builds to App Store / Play Console. Needs store credentials.
- EAS Update — OTA JS/asset updates to installed apps, keyed to a runtime version. Only JS — native changes still need a new build. →
expo-deployment
- EAS Hosting — host Expo Router API routes / web. →
expo-api-routes
2. App config & config plugins
- Config lives in
app.json / app.config.js / app.config.ts (the .ts form allows dynamic/env-driven config).
- Config plugins modify native project files at prebuild time — prefer them over hand-editing
ios//android/ so the native side stays reproducible.
expo-tailwind-setup and many libraries ship plugins; register them in plugins: [].
3. The managed ↔ bare spectrum (know where you are)
| Mode | Native dirs | Use |
|---|
| Expo Go | none | Fastest start; only Expo SDK modules, no custom native. |
| Dev client | generated | Custom native modules while keeping the Expo workflow. → expo-dev-client |
| Prebuild / CNG | generated from config | "Continuous Native Generation" — ios//android/ are build artifacts, regenerated from config + plugins. The recommended default. |
| Bare | committed & hand-edited | Full control; you own native upgrades. One-way from managed. |
Reach for a dev client the moment you need a native module Expo Go lacks.
4. SDK version is the source of truth
- An Expo SDK version pins a specific React Native version and a matched set of native deps. Don't mix versions across that boundary.
- Upgrade via
upgrading-expo (the expo install --fix / upgrade flow), not ad-hoc npm install.
- Runtime version governs which OTA updates a build will accept — bump it when native changes.
5. Expo Router (app structure)
File-based routing under app/; layouts via _layout.tsx, native tabs/stacks, typed routes,
and server API routes (+api.ts). UI patterns → building-native-ui; server → expo-api-routes.
6. Native modules
Author native modules/views with the Expo Modules API (Swift / Kotlin / TS DSL) → expo-module.
This is the supported path to native code while staying in the Expo/CNG workflow.
7. Shared guardrails
- SDK version is canonical — it pins RN + native deps; upgrade through the official flow.
- Prefer config plugins over manual native edits (keeps prebuild reproducible).
- EAS Update ships JS only; native changes require a new build + runtime-version bump.
- Confirm store credentials/identifiers before EAS Submit.
- Managed → bare is effectively one-way — state it before ejecting.
- For RN-runtime concerns (Reanimated, gestures, New Architecture, navigation internals), defer to
react-native-core.
