Expo Go vs Development Build: How to Know Which One You Actually Need

Expo Go is a free, pre-built app that Expo publishes to both stores with only the core Expo SDK's native modules baked in. It opens instantly and is genuinely useful for the first few days of a project, but it cannot run any native code you did not put there yourself. A development build is your own private copy of that same app, compiled through EAS Build with expo-dev-client and every native module your project actually uses linked into the binary. The rule that decides which one you need: if a library ships its own iOS or Android folder, or its setup instructions mention a config plugin or npx expo prebuild, Expo Go cannot run it, and you need a development build before you can test that feature on a real device.

Expo Go is one shared binary, the same app for every Expo project on earth, published once by Expo to the App Store and Google Play. It ships pre-compiled with the modules that are part of the core Expo SDK. Open it, scan a QR code, and your JavaScript bundle loads inside that shared container over the network. There is no build step on your end, which is exactly why it feels instant and why it is the right tool for the first stretch of a project.

The limitation is the same thing that makes it fast. Expo Go cannot execute native code it does not already contain. Install a third-party package that ships its own native iOS or Android code, and Expo Go will not actually load that native side. Depending on the library, you get a clear error, a silent no-op, or a crash on the exact line that touches the native module. None of that means your code is wrong. It means you asked a shared, unmodified binary to run code it was never compiled with.

A development build is a version of Expo Go compiled specifically for your project. You produce one by running an EAS Build with the development profile from eas.json, and under the hood it runs expo prebuild to regenerate native ios/ and android/ project folders straight from your app.json and installed packages, then compiles those into a real binary. That binary includes expo-dev-client, so you keep the same QR-code and fast-refresh workflow you had in Expo Go, plus every native module your project actually declares.

App Store Launch Club members call this the Native Trigger List: the specific categories of feature that force a development build. If your app touches any of these, budget for the extra build step before you start wiring it up, not after Expo Go throws an error you cannot explain.

If none of these apply yet, Expo Go is still the faster loop and there is no reason to add a build step early. The moment your app needs one of them, switch, and expect that switch to happen before your first submission on almost every real app.

The practical order is to start a fresh project in Expo Go, working from the Claude Code desktop app on your Mac, and build the first screens, navigation, and layout there while the loop is instant. The terminal is optional for most of this; Claude Code can run the Expo commands for you and read back what happened.

The moment your build hits the first item on the Native Trigger List, ask Claude Code to configure a development profile in eas.json and run the build. It can set up the eas.json file, add the right config plugin entries to app.json for the library you just installed, and run eas build --profile development for the platform you are testing on, then read the build log back to you if something fails. That keeps the switch from Expo Go to a development build a five-minute detour instead of a half-day stall, and it is the same pattern covered in [how to debug your Expo app when it breaks on a real device](/blog/how-to-debug-expo-app-on-device) and [the EAS build guide for Expo apps](/blog/eas-build-guide-for-expo-apps).

A development build is a testing tool, not what you ship. The same eas.json also holds a production profile, which strips out expo-dev-client and produces the real, store-ready binary. You submit the production build. The development build's only job is proving, on a real device, that the native feature you just added actually works before Apple or Google ever sees it.

This is also part of what keeps a fast build from feeling thin. An app that only ever ran in Expo Go tends to stop at the features Expo Go can show you, which is one path into the kind of minimum-functionality rejection covered in [Guideline 4.2: How to Fix Minimum Functionality in a Claude Code + Expo App](/blog/app-store-rejection-guideline-4-2). Getting comfortable with development builds early is what makes push notifications, offline caching, and real device integration a normal part of the build instead of a scramble the week before submission. [How to ship your first app in 7 days with Claude Code](/blog/ship-your-first-app-in-7-days-with-claude-code) and [the TestFlight beta testing guide for Expo apps](/blog/testflight-beta-testing-guide-for-expo-apps) cover the stages on either side of this one.