If you started your React Native project in Expo, you've probably come across the word "eject" at some point — usually in an older tutorial, a Stack Overflow thread from a few years back, or a teammate who worked with Expo before 2023. It carries a certain weight in developer conversations, often framed as a scary, one-way door: once you eject, you can't go back, and you lose the tooling that made Expo appealing in the first place.
Here's the good news: that fear is mostly outdated. The bad news is that a lot of teams still make decisions based on it. Let's clear up what ejecting actually means today, when you genuinely need it, and why the decision is far less permanent than it used to be.
"Ejecting" Isn't Really a Thing Anymore
The classic eject command took a managed Expo project and permanently converted it into a bare React Native project, generating the native iOS and Android folders once and handing them over to you for good. From that point on, you lost access to Expo's managed tooling — no more simple cloud builds, no more automatic native project generation. It was final, and that finality is exactly why it developed such a reputation.
That workflow has been replaced by something far more flexible: Continuous Native Generation, usually shortened to CNG. Instead of a single irreversible conversion, your native projects are now generated on demand from your project's configuration, whenever you need direct native access — and can be regenerated again later if your configuration changes. You're not choosing between "stay managed forever" and "go bare forever." You're choosing how much native control you need at any given point in your project's life, with the ability to shift that boundary as requirements change.
In practice, this means the real question isn't "should I eject" — it's "do I need to generate and directly edit my native project folders for this specific requirement." That's a much smaller, much more reversible decision.
When You Genuinely Need Native Access
Even with Expo's expanding SDK and config plugin system, there are legitimate situations where you need to step outside the fully managed workflow:
A required native SDK has no Expo support. Expo's module directory covers most major services — payments, analytics, authentication, push notifications — and even niche needs can often be wrapped as a custom config plugin without touching native code directly. But if you're integrating a highly specialized, proprietary, or very new SDK that genuinely has no wrapper and no plugin path, you may need direct access to the native project to integrate it manually.
You need custom native code for a very specific behavior. Some apps need something Expo's APIs simply don't expose — deep, low-level control over a specific hardware interaction, a custom native UI component with no JavaScript equivalent, or tight integration with an existing native SDK your company already maintains. Config plugins solve most of these cases now, but not all of them.
Your organization has infrastructure restrictions. If your company's security policy prohibits sending source code to third-party cloud build services, you may need full local control over your build pipeline rather than relying on cloud-based build tooling.
You're inheriting or maintaining an existing bare React Native codebase. If a project already has years of native code, custom build configuration, and native modules built directly into the iOS and Android folders, there often isn't a compelling reason to migrate it into Expo's workflow unless you're doing a larger refactor anyway.
When You Don't Need to Go Native — Even If It Feels Like You Do
A lot of "I need to eject" decisions turn out to be solvable without leaving the Expo workflow at all. Before generating your native projects and taking on that maintenance yourself, check these first:
Check Expo's module directory. Most mainstream native functionality — camera, maps, biometrics, notifications, in-app purchases, secure storage — already has official or well-maintained community support built for Expo specifically.
Try a config plugin before assuming you need custom native code. Config plugins can modify native project behavior programmatically, without you manually editing Xcode or Gradle files, and without giving up Expo's cloud tooling.
Use a custom development client instead of a full native generation, if you just need to test a specific native module during development. This gives you native access for testing without committing your whole team to managing native build files long-term.
The Real Cost of Going Native Early
The reason this decision matters isn't ideological — it's operational. Once you're managing native project folders directly, your team takes on responsibility for keeping iOS and Android build configurations current, managing signing and provisioning manually (or continuing to use Expo's cloud build tools alongside your native folders, which many teams still do), and manually applying updates that Expo would otherwise have handled automatically through its managed upgrade path.
None of that is a dealbreaker — plenty of serious, well-run engineering teams manage native projects directly and do it well. But it should be a deliberate trade-off made because a specific requirement demands it, not a default reached for out of habit, outdated advice, or an assumption that Expo "isn't for real apps."
The Bottom Line
The old, permanent version of "ejecting from Expo" mostly doesn't exist anymore. Continuous Native Generation means native access is something you can add when you need it and adjust as your requirements change, not a one-way decision you have to get right the first time. Generate your native projects when a specific SDK, custom native requirement, or infrastructure policy genuinely demands it — and check the module directory and config plugin options first, since most teams need far less direct native access than they initially assume.
If you're planning a React Native or Expo project and want an experienced team to help you figure out exactly how much native access your app actually needs, our developers at CyberSys India, a software development company in Kerala, can help you plan it correctly from day one.
Top comments (0)