Expo Go Not on the App Store? Move to Development Builds

What happened to Expo Go?

Expo Go builds for SDK 55/56 were never approved on the Apple App Store; Expo's migration notice is dated May 4, 2026. When SDK 56 released on May 21, 2026, Expo Go was unavailable on both the App Store and Google Play, and Expo now positions Go as an education and prototyping tool only, not a development client for real apps.

I found out the way most people did. I updated a client project to SDK 56 the day it shipped, ran npx expo start, scanned the QR code, and my test iPhone could not load the runtime because the Expo Go version on the store only supported SDK 54. The notice itself is terse: a few paragraphs and a link to the development builds docs. No timeline for Go coming back, because it is not coming back as your daily driver.

If you are pinned to SDK 54, the old Expo Go still works for now. But that is a dead end, not a strategy. Expo has been nudging everyone toward development builds since at least SDK 52, and the store situation just removed the choice. The honest framing: this is a forced upgrade, and it is also the upgrade you should have made anyway.

What is a development build, actually?

A development build is your own app binary with the Expo dev tools compiled in: Expo Go without the shared sandbox. It bundles expo-dev-client into an app that has your real bundle identifier, your real native modules, and your real entitlements, while keeping the dev menu, fast refresh, and QR-code launching you are used to.

The shared sandbox was always the problem. Expo Go ships one fixed set of native modules, so the moment you add anything outside that set, a payments SDK, a Bluetooth library, or the Apple Foundation Models bindings I walked through in my on-device AI in React Native piece ↗, your app runs in Go but the behavior no longer matches what you will ship. A development build is the binary you will actually release, just with developer tooling attached.

The real win is not the migration itself. Development builds delete the entire class of "works in Expo Go, breaks in production" bugs, because the binary you develop against is the binary you ship.

In four years of React Native work I can trace several late-stage emergencies back to that gap: push notification config that Go silently faked, a deep-linking scheme that only existed in the sandbox, permissions prompts that behaved differently in the standalone build. All of those are now impossible by construction.

How do I migrate from Expo Go to a development build?

The migration is one dependency, one config file, and one build. Here is the exact checklist I now use in my mobile development service ↗ work, refined across the four apps I have moved since May:

1. Install the dev client. Run npx expo install expo-dev-client. This is the only code change most apps need.


2. Configure EAS. Run eas build:configure if you have never used EAS, then confirm your eas.json has a development profile:

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "development-simulator": {
      "developmentClient": true,
      "ios": { "simulator": true }
    },
    "production": {}
  }
}

1. Register your test devices (iOS). Run eas device:create and open the link on each iPhone you develop on. This enables ad hoc internal distribution without TestFlight.


2. Build. Run eas build --profile development --platform ios (and --platform android). For a team, TestFlight works too, but internal distribution is faster for day-to-day work: EAS gives you an install link and QR code when the build finishes.


3. Install and connect. Open the install link on the device, launch the app, run npx expo start, and scan the QR code from inside the dev build.


4. Verify parity. Open every screen that touches native functionality: camera, notifications, auth redirects. This is your one chance to catch anything Go was papering over.

How do I keep the Expo Go ergonomics I'm used to?

You lose almost nothing. QR-code launching still works exactly as before: the development build registers its own URL scheme, so npx expo start prints a QR code and your dev build opens the bundle directly. Fast refresh, the dev menu, and the element inspector are all identical.

The pieces worth knowing:

• Simulator builds. The development-simulator profile above produces a .app you drag onto the iOS Simulator. Alternatively, npx expo run:ios builds locally and boots the simulator in one command.


• Sharing with clients. This got better, not worse. I send clients the internal distribution link; they install a real binary with the real app icon instead of explaining what Expo Go is. For JS-only iterations after that, EAS Update pushes new bundles to the same build, so a client sees Friday's changes without installing anything.


• Expo Orbit. The desktop app installs any EAS build onto connected devices and simulators with one click. It quietly replaced half of my QR scanning.

How do I set up CI so builds only regenerate on native changes?

The key insight: you only need a new development build when the native fingerprint changes, meaning new native modules, config plugin changes, or an SDK upgrade. JS-only commits do not need a binary. @expo/fingerprint hashes everything that affects the native project, so CI can compare hashes and skip the build when nothing native moved:

jobs:
  dev-build-if-needed:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 22
      - run: npm ci
      - name: Compute native fingerprint
        id: fp
        run: echo "hash=$(npx @expo/fingerprint . | jq -r .hash)" >> "$GITHUB_OUTPUT"
      - name: Check fingerprint cache
        id: cache
        uses: actions/cache@v4
        with:
          path: .fingerprint-built
          key: fingerprint-${{ steps.fp.outputs.hash }}
      - name: Rebuild dev client
        if: steps.cache.outputs.cache-hit != 'true'
        run: |
          npx eas-cli build --profile development --platform all --non-interactive --no-wait
          touch .fingerprint-built

The numbers from my own app make the case. The companion app for my reputation SaaS (owners approve AI review replies from their phone) went through this migration in late May. Since then it has needed exactly three new binaries: the SDK 56 upgrade itself, one new native module, and one config plugin change. Every other change, roughly 30 commits, shipped through the dev server or EAS Update with zero builds.

Which SDK 56 changes will bite during the migration?

Most teams are doing two upgrades at once: the move to development builds and the SDK 56 bump. Three breaking changes account for nearly all the friction I have hit:

The router codemod ran clean on three of my four apps. The fourth had hand-rolled navigation theming reaching into react-navigation internals, and that took an hour to untangle. Roughly half of my app rescue and optimization ↗ engagements start exactly here: an SDK upgrade attempted on a Friday, abandoned halfway, shipped anyway.

What does moving to development builds cost?

For a solo developer, realistically nothing. As of June 2026, the EAS free tier covers around 30 cloud builds a month, and with fingerprint-gated CI I have never used more than six in a month across two apps. Local builds are free and unlimited: eas build --local or npx expo run:ios compile on your own machine.

The comparison for a small team:

• EAS cloud builds: free tier first, then paid plans starting around 19 USD a month with per-build credits beyond that. iOS builds cost more credits than Android. You pay for queue time savings and zero local toolchain maintenance, and Windows or Linux developers can produce iOS builds.


• Local builds: free, but iOS requires a Mac with Xcode, and you own keeping CocoaPods, Xcode versions, and the Android SDK in sync across every machine. For a team of three, that maintenance quietly costs more than the EAS subscription.

The verdict: this is a forced upgrade that genuinely improves your workflow. You trade a 90-minute migration for binaries that match production, builds that only run when native code changes, and a client-sharing story that no longer requires explaining a sandbox app.

Key takeaways

• Expo Go for SDK 55/56 was never approved on the Apple App Store; Expo's migration notice is dated May 4, 2026, and SDK 56 shipped May 21 with Go gone from both stores.


• A development build is your own binary with Expo dev tools compiled in: same QR launching and fast refresh, none of the shared sandbox.


• The migration is one package and one build: expo-dev-client, an eas.json development profile, then internal distribution or TestFlight.


• Gate CI builds on @expo/fingerprint so binaries only regenerate on native changes; my app has needed three builds in three weeks.


• Budget for SDK 56 at the same time: the expo-router decoupling codemod, global expo/fetch, and the iOS 16.4 minimum.