When to Eject from Expo: A Strategic Guide for React Native Apps

By Sahil Chaudhary · Last updated Oct 19, 2026

Expo has revolutionized React Native development, enabling rapid prototyping and streamlined builds. However, as mobile applications evolve and demand highly specialized features, teams often face a pivotal decision: whether to remain within Expo’s managed workflow or transition to a bare React Native project. This guide demystifies the process, offering a clear framework for when and how to make this strategic architectural shift, ensuring your app can integrate custom native code and achieve its full potential.

TL;DR: Ejecting from Expo (now primarily via npx expo prebuild) becomes necessary when your React Native app requires deep native customization, integration of specific third-party SDKs not supported by Expo's config plugins, or direct control over native project files. While it introduces more complexity, it unlocks unparalleled flexibility for advanced features and performance optimizations.

Key takeaways

• Ejecting from Expo is a strategic move, not a default, driven by specific native code requirements.
• Modern ejection is done via npx expo prebuild, generating standard iOS and Android project directories.
• The primary motivation for ejecting is the need to write or integrate custom native modules (Swift/Kotlin/Java/Obj-C).
• Ejecting increases development complexity, requiring native environment setup and maintenance expertise.
• Evaluate your needs against a decision matrix that considers custom features, build control, and team resources.

Understanding the Expo Ecosystem

Expo provides a powerful set of tools and services designed to accelerate React Native development. Its managed workflow abstracts away much of the underlying native complexity, allowing developers to focus purely on JavaScript. Key components like EAS Build and EAS Update streamline compilation, signing, and over-the-air updates, making it an excellent choice for rapid development and smaller teams.

The managed workflow excels by providing a consistent, pre-configured native environment. It handles native module linking, build configuration, and provides a wide array of built-in APIs through the Expo SDK. This abstraction layer is a significant advantage, reducing setup time and minimizing platform-specific errors. However, this very abstraction can become a limitation when an application's requirements extend beyond what the Expo SDK and its config plugins can offer.

Why Consider Ejecting from Expo? Core Motivations

The decision to move away from Expo’s managed workflow is typically driven by a clear need for capabilities that only direct native access can provide. These motivations often arise as an application matures and requires deeper integration with the device's operating system or highly specialized third-party services.

Need for Custom Native Modules

Perhaps the most common reason to eject is the requirement to write custom native modules. While Expo offers a comprehensive SDK, there will inevitably be scenarios where a specific hardware feature, a proprietary algorithm, or a unique UI component needs to be implemented in Swift/Objective-C for iOS or Java/Kotlin for Android. This includes:

• Integrating with very niche hardware peripherals (e.g., specific payment terminals, industrial sensors).
• Developing highly optimized, performance-critical components that require direct access to native threads or memory management.
• Implementing complex background tasks that demand specific OS-level permissions or lifecycle management not exposed by Expo.

Integrating Highly Specific SDKs

Many third-party SDKs, especially those for enterprise security, advanced analytics, or unique hardware, are designed with direct native integration in mind. While Expo's config plugins can bridge many gaps, some SDKs may have intricate native setup requirements, custom build phases, or rely on specific native project structures that are difficult or impossible to configure within the managed workflow. Examples include certain machine learning inference engines, highly customized biometric authentication systems, or specific DRM solutions.

Fine-Tuning Native Build Configurations

A bare React Native project grants full control over the native build systems (Xcode for iOS, Gradle for Android). This control is crucial for:

• Applying custom build flags or compiler options for specific performance optimizations.
• Integrating unique dependency management strategies beyond CocoaPods and Gradle's standard usage.
• Modifying advanced linker settings or resource bundling behaviors.
• Ensuring compliance with highly specific enterprise security policies that dictate how native binaries are compiled or linked.

Accessing Experimental React Native Features

While Expo works diligently to support the latest React Native advancements, there can be a lag, particularly with experimental features like certain aspects of the React Native New Architecture (Fabric and TurboModules). If your project absolutely needs to leverage these bleeding-edge features immediately, or requires specific configurations of them not yet exposed by Expo, then ejecting provides the direct access necessary.

The Ejection Decision Matrix: When to Make the Leap

Deciding when to eject is a strategic trade-off. It's not about whether Expo is "good enough," but whether your project's unique requirements outweigh the benefits of the managed workflow. Use the table below to evaluate your needs.

When NOT to Eject from Expo

Ejecting from Expo is a significant commitment. It's crucial to understand when this approach is unnecessary or even detrimental. If your application's requirements are fully met by the Expo SDK and its ecosystem of config plugins, there is little to no benefit in ejecting. The managed workflow offers faster development cycles, simpler maintenance, and a more streamlined deployment process. For projects focused on rapid iteration, smaller teams, or those not requiring deep native integrations, sticking with Expo Managed is the more efficient and cost-effective choice. Don't eject preemptively; wait until a concrete, unresolvable native requirement emerges.

The Ejection Process: From Managed to Bare Workflow

The term "eject" historically referred to a command that would create ios and android directories from an Expo project. In 2026, the modern and recommended approach is to use npx expo prebuild, which is designed to be a non-destructive way to generate these native project files while keeping your Expo configuration intact.

When you run npx expo prebuild, Expo analyzes your app.json or app.config.js and generates the necessary native project files (Xcode for iOS, Gradle for Android) in your project root. This process respects your existing Expo configuration and any config plugins you might be using, translating them into native code. This allows you to incrementally add custom native modules or modify native settings while still leveraging parts of the Expo ecosystem if desired.

npx expo prebuild --platform all

Executing this command will create the ios and android directories. You can then open these projects in Xcode or Android Studio respectively. Your JavaScript code remains the same, but you now have direct access to the native environment to add new native modules, link libraries manually, or customize build settings. It's important to understand that while prebuild gives you native projects, you are still technically within the Expo ecosystem, just in a "bare workflow" configuration. This means you can still use some Expo tools like EAS Build, but for native changes, you'll compile and manage the native projects directly.

Post-Eject Considerations: Managing a Bare React Native Project

Transitioning to a bare React Native project introduces new responsibilities:

• Native Development Environment: You'll need Xcode (macOS only) for iOS development and Android Studio for Android, fully configured with SDKs and build tools.
• Dependency Management: For iOS, you'll manage native dependencies via CocoaPods. For Android, it's typically Gradle. Ensure all react-native libraries are correctly linked (autolinking handles most modern modules).
• Build System Integration: Learn to navigate Xcode workspaces and Android Gradle projects. Debugging native crashes, managing signing certificates, and configuring build variants become part of your routine.
• Versioning and Upgrades: Upgrading React Native versions can sometimes involve manual updates to native project files, requiring careful attention to release notes.

These tasks require a team with solid iOS and Android native development expertise, which is a key factor in the decision to eject. For teams without this specialized knowledge, consider partnering with experts in React Native development who can manage this complexity.

Navigating Native Modules and Platform Channels

Once in a bare workflow, the primary mechanism for JavaScript to communicate with native code is through Native Modules (React Native) or Platform Channels (Flutter). In React Native, a native module is a set of functions implemented in Swift/Objective-C or Java/Kotlin that can be invoked from JavaScript. This allows you to expose device-specific APIs or performance-critical logic to your React Native application.

For instance, creating a custom image processing filter might involve:

1. Writing the image manipulation logic in Swift/Kotlin.
2. Exposing a method from this native code to JavaScript using React Native's bridge.
3. Invoking this method from your React Native component.

The ongoing evolution of React Native's New Architecture, specifically Fabric (for UI components) and TurboModules (for native modules), aims to improve the performance and maintainability of this bridge. While still maturing, these technologies underscore the increasing importance of robust native integration for high-performance mobile applications.

Performance and Maintenance Trade-offs

Ejecting from Expo is a trade-off that impacts performance and maintenance in several ways:

• Increased Build Complexity and Times: Native builds are inherently more complex and time-consuming than Expo's managed builds. CI/CD pipelines will need to be configured to handle Xcode and Gradle builds, potentially increasing build server resource usage.
• Larger Team Overhead: Maintaining a bare React Native project often requires team members with dedicated iOS and Android native development skills. This can increase staffing costs and expand the knowledge base required for project success.
• Gains in Performance and Optimization: The direct access to native threads, memory management, and GPU can unlock significant performance gains for specific, demanding features. You can fine-tune every aspect of the native environment, leading to highly optimized experiences that might be difficult to achieve within an abstracted framework.
• Impact on OTA Updates: While Expo's managed workflow allows seamless Over-the-Air (OTA) updates for JavaScript and asset changes, a bare workflow typically limits OTA updates to only JavaScript logic. Any change to native code (e.g., adding a new native module, updating an SDK that modifies native files) requires a full app store submission and review process.

FAQ

What is the "bare workflow" in Expo?

The bare workflow is an Expo configuration where you have full control over the underlying native iOS and Android project files. It's typically created using npx expo prebuild, allowing you to add custom native code or specific native SDKs not supported by Expo's managed environment, while still potentially using some Expo tools like EAS Build.

Can I go back to Expo managed after ejecting?

Technically, no. Once you generate the native project files and start making direct native modifications, reverting to the fully managed workflow is not straightforward. You would essentially need to start a new Expo managed project and migrate your JavaScript code, losing any native-specific changes you made.

Does ejecting affect app performance significantly?

Ejecting itself doesn't inherently make an app faster or slower. It grants you the ability to implement highly optimized native code, which can lead to performance improvements for specific tasks. However, it also introduces complexity, and poorly managed native code can negatively impact performance. The key is the control it provides, not an automatic performance boost.

Is npx expo prebuild the same as eject?

npx expo prebuild is the modern equivalent and preferred method. Historically, expo eject was a command that created native projects and removed Expo-specific configurations. prebuild is designed to be less destructive, generating native projects while allowing you to maintain your Expo configuration and potentially continue using some Expo services like EAS Build in a bare workflow context.

Ship Your Mobile App with Krapton

Navigating the complexities of mobile app development, especially when balancing cross-platform efficiency with native power, requires deep expertise. Whether you're building a new application from scratch or optimizing an existing one, Krapton's team of senior engineers can guide your mobile app development strategy. We specialize in architecting robust React Native and Flutter applications, from initial concept to successful app store deployment. If you're considering a transition to a bare React Native workflow or need to integrate sophisticated native features, we have the experience to ensure a smooth, high-performance outcome. Ship your mobile app with Krapton — book a free consultation with Krapton today.