# Expo vs Bare React Native

Source: Dev.to

Overview

Expo has evolved from a “managed only” solution to a full toolkit that can still eject to a bare workflow when needed. Below is a comparison of Expo vs. bare React Native as of 2025‑2026.

Expo

Pros

• EAS Build – Cloud builds without requiring Xcode or Android Studio locally. Signing and provisioning are handled automatically, which is great for CI and developers who don’t want to maintain native toolchains.
• EAS Submit – Push builds to TestFlight and Google Play (internal or production) directly from the CLI. Works seamlessly with EAS Build for a commit‑to‑store pipeline.
• Expo SDK – Provides APIs for camera, maps, notifications, updates, and more through a consistent JavaScript interface, often reducing the amount of native code you need to write and upgrade.
• Over‑the‑air updates – EAS Update lets you ship JavaScript (and asset) changes without a full store release, useful for hot‑fixes and A/B tests.
• Documentation & DX – Well‑written docs and a smooth CLI (npx expo start). Fast Refresh and the dev client make iteration fast.
• Custom dev client – You can add native modules while still using EAS Build and most Expo tooling, so you’re not locked out of native code.

Cons

• Native control – Very custom native behavior or bleeding‑edge native APIs may require patches, forks, or config plugins. Usually manageable, but adds complexity.
• Bundle size & abstraction – Expo adds some runtime overhead. For most apps this is fine, but highly constrained environments may be affected.
• Learning curve – Teams accustomed to bare React Native need to learn EAS and the Expo workflow.

When to choose Expo

• For most new React Native apps, especially when you want to avoid the overhead of native toolchains.
• Use a custom dev client when you need native modules not included in the default SDK.
• Stick with the managed workflow when the app stays within Expo’s supported surface.

Prebuild

prebuild generates (or updates) the ios/ and android/ folders from your Expo configuration.

• What it does – Reads app.json / app.config.js and the list of config plugins, then creates native Xcode and Android projects. Plugins can add permissions, native dependencies, or custom native code (e.g., expo-camera, expo-notifications).
• When it runs – In EAS Build, prebuild runs automatically before each build unless you’ve committed the native folders and use a profile that skips it. Locally you can run:

npx expo prebuild          # generate or refresh native projects
npx expo prebuild --clean  # regenerate from scratch (useful after changing plugins or config)

• Managed vs. “bare‑ish” – In a managed workflow you typically don’t commit ios/ and android/; EAS Build regenerates them each time. In a custom dev client or “bare‑ish” workflow you might run prebuild once, commit the native folders, and edit them manually. You can continue to maintain those folders or re‑run prebuild to re‑apply changes (preferably using config plugins for reproducibility).

• Why it matters – prebuild lets you add native modules while still leveraging EAS Build and Expo tooling, avoiding the binary choice between “no native code” and “fully manual native projects.”

Bare React Native

Pros

• Full control – Every native file belongs to you. You can modify anything, add any library, and fine‑tune the native projects exactly as needed.
• No Expo layer – Slightly smaller runtime footprint; no Expo runtime or config plugins.
• Existing projects – Many codebases start bare. Maintaining a bare setup can be simpler than migrating to Expo.

Cons

• Build & signing – You must manage Xcode/Android Studio, certificates, provisioning profiles, and CI yourself, which adds time and potential frustration.
• Updates – Upgrading React Native and native dependencies is entirely your responsibility. Expo abstracts much of this work.
• No built‑in OTA – You can integrate a solution like CodePush, but there’s no native EAS Update equivalent.

When to choose bare

• When the app requires native behavior that Expo doesn’t support or would need heavy patching.
• When the team already has a stable bare workflow and prefers to stay with it.
• When you need to align with an existing bare codebase.

Choosing Between Expo and Bare

• New app, standard needs – Start with Expo (managed or custom dev client) and use EAS Build + Submit. Switch to bare only if you encounter a blocker.
• Heavy native requirements or existing bare codebase – Stay with or migrate to a bare workflow when the need for control outweighs the convenience of Expo.

2026 Outlook

Expo is now production‑ready and widely adopted. The old notion that “Expo means you can’t use native code” is outdated. Choose the approach that matches your app’s requirements and your team’s comfort with native tooling, rather than relying on legacy stereotypes.