In a real app
The most common confusion, still today, is believing Expo restricts access to native code. That was true in the days of the “managed workflow” and Expo Go; the managed/bare distinction no longer exists. A modern Expo project is a React Native project whose android and ios folders are generated by npx expo prebuild, and into which you add any native library or your own Swift/Kotlin module. Projects with committed native folders are still fine; you only lose automatic regeneration.
What matters in an audit: the SDK version (the expo field in package.json, then npx expo-doctor), the gap between installed versions and expected ones (npx expo install --check), and whether the native folders are generated or hand-maintained. An SDK three versions behind costs far more to catch up than upgrading on each release, because every SDK also brings its React Native version and architecture changes. The SDK 58 changelog mentions, for instance, the new Expo Go limited to SDK 58, precompiled expo-modules-core binaries on Android, and the split of Expo’s iOS sources into Swift Package Manager targets.
EAS is separate: a hosted service with its own pricing, usable without the expo package. A project can use Expo without EAS (local builds or a home-grown CI) or EAS without Expo.
Related terms
Prebuild (Continuous Native Generation)
The Expo command that generates the android and ios folders from app.json and config plugins instead of maintaining them by hand.
Development build
A debug build of your own app that includes expo-dev-client: your native modules, plus a launcher to connect to Metro.
Expo Go
Expo’s sandbox app, with a fixed set of native modules: for learning and prototyping, not for shipping.
EAS Build
Expo’s hosted build service: profiles in eas.json, credentials management, and macOS and Linux runners for iOS and Android.
Expo Router
Expo’s file-based router: every file in the app directory becomes a screen, with deep links and typed routes out of the box.