Expo Go is somebody else's app running your JavaScript. A development build is your app.

What does Expo say the difference actually is?

Expo splits any React Native app into two halves and the whole subject makes sense once you hold them apart. The native app is the thing installed on the device. It contains the compiled native code of every library the project depends on, plus the icon, the name and the splash screen. The JavaScript bundle is your screens and your logic. In a shipped app there is one bundle, called main.js, packaged inside. In development that bundle is served live off your machine and reloads as you type.

Expo Go is a pre-built native app. Expo's own words: it works like a playground and it cannot be changed after you install it. The native half was decided by Expo, built by Expo and uploaded to the stores by Expo. You are supplying the other half. The sentence that explains every limitation on this page is Expo's own: only APIs and libraries that were bundled in the native app can be used.

A development build is the same arrangement with the native half handed back to you. It is your project compiled, with the expo-dev-client library installed, which Expo says augments the built-in React Native development tooling. You get network request inspection and a launcher screen that lets you point the app at different development servers, which is how two people on a team share one build. The dev menu opens with Cmd and D, or Ctrl and D, or by shaking the phone.

Expo documents three ways to produce that build and is explicit that all three produce the same thing. Locally with Expo CLI, using Android Studio or Xcode on your own machine, which needs no Expo account. On EAS servers in the cloud, which needs no native toolchain and can make iOS builds from Windows or Linux. Or the same EAS build run on your own machine with a local flag, where EAS still handles credentials and signing. The difference between them is where the compiler runs and what you had to install first, not what comes out.

Expo, development builds FAQ, page dated 3 September 2026, read 17 October 2026

What can Expo Go not run?

Expo publishes the list, under a heading that says what cannot be done in Expo Go and why, and the why is always the same. The native app is immutable once installed. Five entries follow from that.

Native libraries that are not already inside Expo Go. Expo works the example through carefully, and it is worth following because the failure is confusing the first time. Install a package with native code and both halves land in node_modules. Your JavaScript bundle uses only the JavaScript half. That bundle reaches Expo Go and calls into native code that is not there. Expo's example of a library that works is react-native-webview, which is bundled in Expo Go. Its example of one that does not is react-native-firebase, where the new bundle hot reloads and then errors immediately. Expo states there is no way to get the native code into Expo Go unless it was in the bundle Expo uploaded to the stores.

Your app icon, your app name and your splash screen. You can ship all three from a project you only ever opened in Expo Go, and they will be correct in the store build. You just cannot look at them while you work. Expo Go draws a splash screen that is your icon on a solid colour, which it calls a dev-only emulation to give you a rough idea, and it cannot run SplashScreen.setOptions to animate anything. These assets ship with the native bundle.

Remote push notifications, meaning the ones sent from a server to the phone. Notifications the app raises itself do work in Expo Go. Expo's reasoning for the split is that a push service has to be tied to your own notification certificates, and making it work in Expo Go tends to confuse people later about why production behaves differently. Then App Links on Android and Universal Links on iOS, both of which need a two-way association in which the native app carries the linked website's URL. The native app is not yours to edit, so the association cannot be made.

And the fifth, which is the one that stops people before they even reach the other four. Each build of Expo Go supports exactly one Expo SDK version, and the project's version has to match. The expo dependency in package.json is what sets the project's version, so that one line tells you which Expo Go you need. On Android, on the Android Emulator and on the iOS Simulator you pick a matching build from expo.dev/go and install it. On a physical iPhone the answer is less comfortable, and it is the next section.

Can you still install Expo Go on an iPhone?

This is where the usual advice has gone stale, so it is worth being exact. Expo's troubleshooting page for the SDK mismatch error, dated 3 September 2026, says Expo Go on the Apple App Store stops at SDK 54, and that SDK 55 and later are not available there. The expo-dev-client reference page currently points at the sdk-58 source tree, so a project created today sits four releases past that ceiling. The free download route that every older tutorial assumes is not available for a current project on a real iPhone.

What Expo tells you to do instead, for SDK 54 and above on a physical iPhone or iPad, is build Expo Go yourself. The command is eas go, and the output is distributed through your own TestFlight internal team, which Expo says needs an Apple Developer Program membership. The setup page spells out the rest: install TestFlight, open App Store Connect, add your own Apple ID as an internal tester, accept the email invitation. There is a further step people miss. On a physical iOS device, Expo Go opens a project from a development server only when Expo CLI and Expo Go are signed in to the same Expo account.

Read that path back and notice what it costs. To use the free playground on your own iPhone you now need a paid Apple membership, a TestFlight distribution and a build you compiled. That is the whole price of a development build, spent on getting someone else's app onto your phone instead of your own. Apple's enrollment page, read 17 October 2026, puts the Apple Developer Program annual fee at 99 USD, in local currency where available, and it belongs in your view of what an app costs to maintain whichever loop you choose, because publishing to the App Store needs it anyway.

Older projects are worse off, not better. For SDK 53 or earlier Expo says you cannot install an older version of Expo Go on a physical iOS device at all. Your options are to upgrade the project, use an Android device, use the iOS Simulator, or create a development build. Three of those four are real work, and one of them is the thing you were trying to avoid.

The other platforms are still easy, and that asymmetry is useful to know before you plan a day. Expo Go for Android comes from the Google Play Store, although Expo notes the Play version can also lag behind a new SDK release. On the Android Emulator and the iOS Simulator, Expo CLI installs Expo Go for you when you press A or I at the development server prompt. And for a development build, Expo says compiling locally with Expo CLI is the only way to install one on an iPhone without a paid Apple Developer account, while every EAS build that runs on an iPhone device needs a paid account for signing.

Expo, project is incompatible with this version of Expo Go, page dated 3 September 2026, read 17 October 2026

How much slower is a development build to live with?

Much less than the fear suggests, because the slow part happens once. The usual objection is that a development build means waiting for a compiler every time, and Expo is direct that this is not how it works. The native directories are reused on later runs. When you change only TypeScript or JavaScript, there is nothing to rebuild and you start the server with npx expo start, exactly as you would for Expo Go.

Expo names three events that do force a recompile. Installing or updating a library that contains native code. Changing your app config, meaning app.json. Upgrading your Expo SDK version. When one of those happens you run npx expo prebuild --clean to regenerate the native android and ios directories, then build again. Expo also notes you never need to run prebuild by hand the first time, because both expo run and eas build do it for you when no native directories exist.

Put a week of real work against that list and the picture changes. Screens, copy, state, navigation, data fetching and bug fixing are all JavaScript and cost nothing. Adding a library with native code is a recompile, and so is a one-line change to app.json, which is the one that surprises people, so batch your config edits. Expo is candid that building from scratch takes long enough that you will be tempted to switch tasks and lose focus. That is an argument for doing it once on a Monday, not for avoiding it.

Two details worth planning around. An iOS Simulator build installs only on simulators and an iOS device build only on devices, so if you want both you need two builds and, per Expo, a separate EAS profile for the simulator one. And neither loop tells you anything trustworthy about speed, because both serve a development bundle over your network rather than the single main.js bundle that ships. If somebody asks you about app startup time, do not answer from either one.