But an interesting paradigm shock often occurs when engineers implement a custom React Native library component and generate an EAS Development Build. You download the `.apk` or `.ipa`, install it on a physical test device, click the launcher icon, and... it refuses to start without seeking a development server URL.
If we have to compile a native binary via EAS anyway, why does it still depend on a running machine? Are we trapped in a cycle of rebuilding and redeploying native code for every single change?
Let’s unpack the architectural separation of concerns that powers Expo's developer velocity, and look at what happens under the hood when a major JavaScript refactor throws a wrench into the system.
1. The Separation of Concerns: Native Container vs. JS Bundle
To understand why a development build behaves this way, we have to look at a React Native app as two entirely independent layers:
- The Native Layer (The Engine): Written in Java/Kotlin, Objective-C/Swift, or C++. It handles system APIs, primitives, and your custom native C++/Java/Swift libraries.
- The JavaScript Layer (The Brains): Written in JS/TS. It dictates your UI layout, business logic, components, and state management.
When you run an EAS build using the `--profile development` configuration, you are not building a standalone app. You are building a custom-configured native engine.
Think of a Development Build as a bespoke web browser built exclusively for your app. It contains all the complex native plumbing and specialized custom native libraries you added to your project, but it is completely "empty" of your application's actual JavaScript code.
When you launch it on a phone, it mimics a browser hitting a web page: it boots up and asks, "Where is the local Metro Server hosting the JS code?"
2. The Power of the "No-Rebuild" Workflow
It feels counterintuitive at first. If you make a modification, do you have to wait for EAS to compile a new binary? The answer is almost never. This behaviour is a fundamental design choice of the React Native and Expo ecosystems to prioritize developer velocity.
The separation of the engine from the code creates an incredibly fast development cycle:
- Native Library Code Changes (Rare): If you modify the underlying Swift, C++, or Java file of a custom library, yes, the native shell must be updated. You trigger an EAS build, install the new binary container, and tuck it away.
- JavaScript & UI Changes (Frequent): If you add components, change styling, or alter how you call that native library from your TypeScript wrapper, you do not rebuild. Metro hot-updates the bundle over your local network using Fast Refresh in milliseconds.
3. The Refactor Catch-22: Troubleshooting Metro Resolution Errors
Because a Development Build is entirely dependent on the Metro Server to "stream" code to the device, any disruption in the JavaScript bundle mapping will stall your app.
A common scenario occurs when refactoring code to eliminate cyclic import dependencies. Let's say you create a new clean-up file under `app/services/AppActions.ts`, modify your imports, and suddenly hit an angry wall of terminal logs like below:
```
```
[Error: UnableToResolveError Unable to resolve module ./services/AppActions from /App.tsx:
None of these files exist:
* services/AppActions(.ts|.tsx|.js|.json)
> 22 | } from './services/AppActions';
```
Strangely, your phone might still display a functioning app while your server logs scream in terror. Why?
The "Ghost File" Caching Illusion
When you deep-refactor file hierarchies, two things often happen simultaneously:
- Path Discrepancies: If your App.tsx sits at the root and your file is created inside an app/ subfolder, an import path pointing directly to ./services/... instead of ./app/services/... breaks Metro's dependency tree resolver.
- Stale Cache: Your mobile device appears to keep working because it is coasting on a cached copy of the last successful JS bundle compilation.
The application hasn't actually registered your refactored logic. To fix this, you don't need to touch EAS or rebuild the native shell. You simply have to correct the relative import path and purge Metro’s internal memory by restarting the server like below:
```
```
# Force Metro to clear its file-system map and re-scan your project
npx expo start -c
```
Once the bundler cache is wiped clean, it successfully maps your new JS files, updates the tree, and streams the changes to your custom native shell instantly.
4. How Development Compares to Preview & Production Profiles
The core takeaway is that Metro connectivity is an exclusive trait of the development profile. Once you shift into other environments, the architectural model shifts completely.
--
| Feature | development Profile | preview / production Profiles |
|---|---|---|
| Native App Context | An empty engine/shell holding native dependencies. | A self-contained production binary package. |
| JS Bundle Location | Hosted dynamically on your local development machine. | Baked directly into the binary compilation step on the cloud. |
| Runtime Server Requirement | Mandatory. Requires an active Metro server URL connection. | None. Runs 100% standalone off internal device storage. |
| Asset Optimization | Raw assets streamed over local Wi-Fi / ADB tunnels. | Bundled, minified, and pre-compiled into optimized Hermes bytecode. |
| Update Mechanism | Real-time local Fast Refresh. | App Store updates or Over-the-Air (OTA) production runtime networks. |
--
Wrap Up
When working within the Expo ecosystem, treat your local development binary as a long-lived vessel. Build it once with your custom native components, install it on your device, and leave it alone. As long as your native footprints don't change, your entire application delivery lifecycle can happen strictly at the speed of JavaScript.
Just remember: if your imports break and Metro loses its map, your advanced native shell will look back at your computer waiting for directions!