Building Production Apps with Expo in 2026: A Startup's Guide

Codixus Team01/07/2026

You are a founder deciding how to build your app, and somewhere in your research a developer told you the same thing everyone said in 2020: Expo is fine for a prototype, but you will have to eject before you ship anything serious. That advice is out of date, and acting on it will cost you weeks of native setup you do not need. We build our own App Store and Play Store apps on Expo, and client apps too, so this is not theory. It is how production ships.

This guide walks through what Expo actually is in 2026, where it stops, and why an Expo development build is the right default for most startup apps. Just the decisions you will face and how we make them.

The "only for prototypes" myth is dead

The old criticism had a real basis. Years ago, if you wanted a native library that Expo did not bundle, you were stuck. Your choices were to ship inside the sandboxed Expo Go app with a fixed set of native modules, or to "eject" into a bare React Native project and hand-manage the iOS and Android folders yourself. That fork is where the reputation came from.

That fork is gone. The thing that killed it is the development build. A development build is a debug build of your own app that includes the expo-dev-client library, which means it is a real native binary you control, not a shared playground. Expo's own docs are blunt about the difference: Expo Go is a pre-built app with a fixed set of native libraries, while a development build is a customizable native app you create yourself. Any native library you want, you add. There is nothing to eject from because you are already in your own project.

Development builds replaced the managed vs bare debate

You will still see old blog posts framing the choice as "managed workflow vs bare workflow." Skip that framing. The modern model is Continuous Native Generation, or CNG. Instead of creating the native ios and android directories once and babysitting them forever, those folders are generated on demand from your app config and a set of config plugins whenever you build or debug. You keep the configuration in version control. You do not keep the generated native code.

Upgrading React Native by hand across two native platforms is one of the most painful chores in mobile work, because your custom edits fight the upgrade at every step. With CNG, the native project is disposable and regenerated, so upgrades become a config change instead of a merge conflict marathon. That single property is why we default to it for apps we plan to maintain for years, not weeks.

EAS Build: your release pipeline without building one

Getting a signed iOS binary onto a device is the part that scares first-time founders, and fairly so. Certificates, provisioning profiles, keystores, Xcode versions, and a Mac in the loop. EAS Build is a hosted service that builds your iOS and Android app binaries in the cloud, which takes most of that off your plate. You do not need a Mac to produce an iOS build, or a hand-wired CI server on day one.

In practice this is why we can put a TestFlight build on your real hardware by the end of week two. The binary comes out of EAS, gets submitted, and you are holding the actual app instead of a slideshow. That early hardware test is the single best de-risking move in an app build, because simulators lie about performance, permissions, and payments. Every serious project we run treats a real-device build in the first two weeks as non-negotiable.

EAS Update: ship a fix without waiting for review

The second half of the pipeline is over-the-air updates. EAS Update lets your app update its own non-native pieces, meaning your JavaScript, styling, and images, without a fresh app store submission. A typo in a paywall, a bad copy string, a layout that breaks on one screen size: you push a fix and users get it, without a multi-day review queue between you and the correction.

There is a hard line here that you must respect, and the docs draw it clearly. OTA updates cover JS, config, and assets. They do not cover a change to native code or native dependencies, a change to app permissions, or an Expo SDK version bump. Anything that needs a new binary needs a new EAS Build and a new store submission. Treat OTA as a scalpel for small fixes and product tweaks, not as a way to dodge App Store review for real feature work. Founders who blur that line eventually get a rejection, so we keep native and OTA changes in separate buckets from the start.

If you are still weighing the framework decision itself, our take on the trade-offs lives in React Native vs Flutter, and if you want honest numbers before you commit, read how much it costs to build a mobile app. Or if you would rather talk it through with people who ship this stack weekly, Book a 30-min studio call and we will map your idea to a plan.

When you still drop into a native module

Expo is not magic, and pretending otherwise sets you up to be surprised. There are cases where you write or wrap native code. The most common ones we hit are a niche SDK with no maintained Expo config plugin, a hardware or Bluetooth integration with tight platform APIs, or a performance-critical path where you want to control the native thread directly.

The good news is that this is now additive, not a fork. You author a native module or a config plugin, keep it in your repo, and it runs through the same prebuild and EAS Build pipeline as everything else. You keep OTA updates, managed upgrades, and the whole workflow. In years on this stack, few apps truly needed hand-written native code, and none needed to leave Expo to get it.

The new architecture is already the default

React Native shipped a rebuilt core, usually called the New Architecture, made up of the Fabric renderer, the JSI layer that lets JavaScript talk to native through C++ instead of the old asynchronous bridge, TurboModules, and the Hermes engine. The headline for you is simple: as of React Native 0.76, the New Architecture is enabled by default in all new projects, and the docs note it has been proven at scale in production apps at Meta.

You do not need to understand the internals to benefit. What you get is faster startup, smoother lists and animations, and a foundation that will keep receiving investment. What you should check is that any native library you depend on supports the New Architecture, because a stale, unmaintained dependency is the most likely thing to hold you back. We audit the dependency list for exactly this before we commit to a build.

Real production concerns, handled up front

Three things trip up teams shipping their first Expo app, and all three are manageable if you plan for them.

App Store review. Expo apps are ordinary native binaries, so they follow the same rules as any other app. Account deletion, clear subscription terms, and honest permission prompts are what reviewers actually flag, not your framework choice. OTA updates are allowed for the non-native tweaks described above, and you stay safe by not shipping feature-level changes that way.

Native dependencies. Before you build a feature on a library, confirm it has a maintained config plugin or an Expo-compatible package. A config plugin is a function that modifies your native project during prebuild instead of you editing Info.plist or AndroidManifest.xml by hand, which keeps the CNG model intact. A dependency without one is a yellow flag worth catching in week one, not week ten.

Config and secrets. Push credentials, subscription keys, and API keys belong in EAS environment configuration, not hard-coded in your JavaScript bundle where a curious user can read them. It is the mistake we see most often in inherited codebases.

Our default, stated plainly

For most startup apps, an Expo development build with EAS Build and EAS Update is the right choice, and the burden of proof is on the exception. It gives you real native capability, cloud builds without a Mac farm, OTA fixes for the small stuff, and painless framework upgrades. You drop to native only for the specific integration that demands it, and you do that without leaving the workflow. This is the exact stack behind our own live apps. If you want a fixed scope and a fixed timeline on it, our React Native development service is built around this pipeline.

FAQ

Is Expo production ready in 2026?

Yes. The old blocker, being trapped in Expo Go with a fixed set of native modules, was solved by development builds, which are real native binaries you fully control. You can add any native library, ship to both stores, and run on the New Architecture. Expo powers a large number of live App Store and Play Store apps, including our own.

Do I still need to eject from Expo?

No, and "eject" is no longer really a concept. With Continuous Native Generation, your native folders are generated from config and config plugins on demand, so you already own your build. When you need custom native code, you add a native module or config plugin inside the same project and keep every benefit of the workflow.

What is the difference between EAS Build and EAS Update?

EAS Build produces the actual signed app binaries for iOS and Android in the cloud, which is what you submit to the stores. EAS Update pushes over-the-air changes to the non-native parts of an already-installed app, meaning JavaScript, styling, and assets. Native changes, permission changes, and SDK bumps require a new EAS Build and a new store submission.

Can Expo apps use the React Native New Architecture?

Yes. As of React Native 0.76 the New Architecture is on by default, and Expo supports it. The one thing to verify is that your native dependencies are compatible, since an unmaintained library is the most common reason a team has to hold back.

When should I choose bare React Native over Expo?

Rarely, and usually for a very specific reason: a deep native integration with no config plugin, or an existing large native codebase you are extending. Even then, most teams are better served by adding a native module inside an Expo project than by giving up managed upgrades and OTA updates. Start with the development build and let a real constraint, not a rumor, push you off it.

Sources

Need this built? Book a 30-min studio call.