Migrate from Expo Go to a Development Build with AI

Why does Expo Go run out of road?

Because Expo Go is a pre-built app containing a fixed set of native modules, and the moment your project needs a native module that is not in that set, Expo Go cannot run it. This is the wall every growing Expo project hits: you add a library with native code (BLE, a payment SDK, a custom config plugin, anything outside the bundled list) and Expo Go throws an error that no amount of JavaScript fixes. The development build is the answer, and it is not an exit from Expo, it is the grown-up version of the same workflow.

A development build is your own Expo Go: an app you compile that contains exactly the native modules your project uses, with the same fast-refresh JS development loop on top. Expo (the toolchain pulls 6,337,220 weekly downloads, so most RN apps live in this world) designed this on purpose, and understanding that reframes the migration from “leaving Expo” to “upgrading how you run it.”

What actually changes, and what does not?

Less than the anxiety suggests. The mental model shift is the whole task:

Aspect	Expo Go	Development build
Native modules	Fixed bundled set only	Any module your project includes
How you run it	Download Expo Go, scan QR	Build once, install your custom dev client
JS dev loop	Fast refresh	Identical fast refresh
Rebuild needed	Never (it is pre-built)	Only when native deps change
Config plugins	Ignored / limited	Fully applied

The thing people fear, that they are now doing native iOS/Android builds constantly, is wrong: you rebuild the dev client only when native dependencies change, and the day-to-day JS loop is exactly what it was. The real change is one of mindset, your app now has a native layer you own, configured through config plugins and prebuild, the managed-not-bare approach that keeps you out of hand-editing Xcode while still getting custom native code.

How does the AI-assisted migration actually run?

As a short, scoped sequence, not one big leap. An agent (Claude Code, Cursor) is good at the mechanical parts if you keep them mechanical:

1. Install expo-dev-client and confirm the project builds. This is the core step, and often nearly the whole migration for a still-mostly-standard app.
2. Audit native dependencies. Have the agent list every package with native code and check each is config-plugin compatible; the ones that need a plugin are where attention goes.
3. Move app config to the plugin system. Permissions, entitlements, and native settings that Expo Go ignored now belong in app.json/app.config plugins, and the agent translates Info.plist-style needs into config.
4. Build the dev client (EAS Build or local), install it, and verify the previously-failing native module now works.

The agent’s value is the dependency audit and the config translation, the tedious, error-prone parts. What it should not do unprompted is eject to bare workflow; the whole point is staying managed, and the standing rule (never edit the native iOS/Android dirs by hand in a CNG project) is the same one that governs the managed-versus-bare decision. Keep the agent inside config plugins, not native source.

What breaks, and how do you see it?

Three predictable snags. A dependency that has no config plugin and needs manual native setup is the real blocker, found in the audit, not at build time, which is why the audit is step two. A build that fails on a missing entitlement or a misconfigured plugin is the common error, and the fix is in the config, not the JS. And the team-workflow change: everyone now installs the custom dev client instead of Expo Go, and a new native dependency means everyone rebuilds, so the migration includes telling the team, not just the code. When a native module silently does nothing, the diagnosis is the usual verify-what-actually-ran discipline from the empty network tab triage: confirm the module is in the dev client, not assumed.

A development build is also the prerequisite for most of the interesting native work, BLE, payments, custom widgets, so the migration usually unblocks a feature, not just a build. The screens are unaffected; a free VP0 design is the same starting point either way, and the dev-build migration is purely a runtime upgrade beneath them.

Key takeaways: Expo Go to development build

• A development build is your own Expo Go: a compiled app with exactly your native modules, same fast-refresh JS loop on top, not an exit from Expo.
• The day-to-day loop is unchanged: you rebuild the dev client only when native dependencies change, not constantly.
• The migration is mostly install expo-dev-client plus a dependency audit: the agent’s value is auditing native deps and translating config.
• Stay managed, not bare: keep the agent in config plugins and prebuild, never hand-editing native dirs.
• It unblocks features: BLE, payment SDKs, and custom native modules need a dev build, so the migration is usually a feature unlock.

Frequently asked questions

How do I migrate from Expo Go to a development build with AI? Have the agent install expo-dev-client, audit every native dependency for config-plugin compatibility, move permissions and native settings into app config plugins, and build the dev client with EAS or locally, then verify the previously-failing native module works. Keep the agent in config plugins, never ejecting to bare. A free VP0 design is the same starting point throughout.

Is a development build the same as ejecting from Expo? No: a development build stays in Expo’s managed workflow, it is a compiled version of Expo Go containing your own native modules, configured through config plugins and prebuild. Ejecting to bare workflow means hand-managing the native projects, which the development build is specifically designed to let you avoid.

Will I have to rebuild constantly after migrating? No: you rebuild the development client only when native dependencies change. The day-to-day JavaScript development loop with fast refresh is identical to Expo Go, so most work continues without any rebuild at all.

Why does Expo Go stop working for my app? Because Expo Go is pre-built with a fixed set of native modules, so any library with native code outside that set cannot run in it. A development build compiles your own client containing exactly the native modules your project uses, which is the supported way past that wall.

What is the hardest part of the migration? The dependency audit: finding any package that needs native setup with no config plugin, which becomes the real work. Run it early (step two) rather than discovering it at build time, and remember the team must switch from Expo Go to the custom dev client too.