Local vs Cloud Builds in Expo: What expo prebuild and eas build Really Do

Introduction

There’s a lot of confusion around terms like Prebuild, Dev Client, EAS Build, and Continuous Native Generation (CNG). I remember the confusion I used to have myself especially when trying to understand the difference between EAS cloud builds and local builds.

For a long time, I assumed that a local build was the same thing as the CNG process. I kept asking myself:

• What is the logic behind each build?
• What’s the real difference between cloud builds and local builds?
• What do you actually gain from using EAS Build versus building locally?

At some point, the questions got even more confusing:

• Was EAS Build ignoring my native code?
• And where did CNG fit into all of this?

The confusion didn’t come from the tools themselves, it came from not understanding how they connect.

Once I finally understood what CNG really is, how Prebuild fits into it, and how both local builds and cloud builds rely on the same native generation system, everything clicked.

So before comparing cloud builds and local builds, let’s first talk about CNG.

What is Continuous Native Generation (CNG)?

When I was learning React Native, I remember a time when CNG was not really a thing yet. Building an app that included native modules often meant ejecting from your project whether you were using Expo or React Native CLI. Once you ejected, you were suddenly responsible for configuring native code manually.

Does this look familiar? 😅 The old managed vs bare workflow era…

expo eject

expo eject --eject-method=bare

Or even better, the interactive prompt where you had to choose:

• Bare workflow (eject)
• Managed workflow (stay)

Working with native modules meant editing things like:

• AndroidManifest.xml
• Gradle files
• iOS Info.plist
• platform-specific permissions and setup

On top of that, some libraries only supported older OS versions, and getting them to work correctly with your app could be frustrating. Upgrading React Native or adding new native functionality often felt risky, because one wrong change could break the entire build.

Then CNG came in and changed the workflow completely.

Continuous Native Generation (CNG) is Expo’s approach to managing native code in a React Native app. Before CNG, native projects were usually created once and then manually maintained for the entire lifetime of the app. Over time, this made native code fragile, hard to upgrade, and difficult to reason about.

Instead of treating native projects as something you create once and protect forever, CNG treats them as short-lived, generated artifacts. Native projects are created only when needed such as during development, debugging, or building and they are generated from a standard template plus a set of configuration rules.

With CNG, developers don’t maintain the native projects themselves. They maintain the instructions for how those native projects should be created.

Those instructions live in:

• app.json or app.config.js
• config plugins provided by libraries or written by the developer

When Expo needs native code, it:

• Starts from a clean native template
• Applies the configuration and config plugins
• Generates the Android and iOS projects
• Builds the app

At this point, we now know what CNG is and why it exists. It’s the system responsible for generating native projects in a predictable and repeatable way.

CNG itself doesn’t build your app it prepares the native code that builds depend on. Tools like Prebuild, local dev builds, and EAS cloud builds all rely on this same native generation process.

With that foundation in place, we can now clearly compare local builds and EAS cloud builds, understand what each one actually does, and see how CNG fits into both.

Local Builds vs EAS Builds

Before comparing local builds and EAS builds, it’s important to clarify what we actually mean by “local build” because this is where a lot of confusion starts 😅.

When I say local build, I’m referring to building your native app on your own machine, where the Android and iOS projects (/android and /ios) are generated locally and compiled using your local environment.

That usually looks like this:

• Native projects are generated locally
• You can open Android Studio or Xcode
• You can run and debug the app directly on your machine

Now, to make things a little more confusing (because of course 😄), we also have:

eas build --local

Which allows you to run the EAS Build pipeline locally, instead of on Expo’s servers.

So now we have:

• local builds using npx expo prebuild + npx expo run:*
• local builds using eas build --local
• cloud builds using eas build

At first glance, this can make it feel like there are many different build systems. But here’s the key point:

All of these builds rely on the same underlying system: Continuous Native Generation (CNG).

Whether you build locally or in the cloud, native projects are always generated using CNG. The difference between these workflows is not how native code is generated it’s where the build runs and what the workflow is optimized for.

With that in mind, we can now clearly break down the differences between local builds and EAS cloud builds, and understand when each one makes sense.

Local Builds (Dev Client Builds)

When we talk about local builds in Expo, we’re usually referring to building and running the app on your own machine, with native projects generated locally. This is the workflow most developers use during active development and debugging.

Local builds are powered by Prebuild, which is Expo’s implementation of Continuous Native Generation (CNG).

when you run:

npx expo prebuild

Expo generates the native Android and iOS projects (/android and /ios) from your app configuration and installed libraries. These native projects are created so your React Native code can be compiled and run as a real native app.

Once the native projects exist, you can run the app locally using.

Android:

npx expo run:android

IOS

npx expo run:ios

This compiles and launches the app using your local Android or iOS development environment, allowing you to debug the app, inspect logs, and even open the project in Android Studio or Xcode.

A quick but important note about modifying native files

Because the native projects are generated by Prebuild, modifying them manually comes with a tradeoff.

If you later run:

npx expo prebuild --clean

Expo will delete and regenerate the native projects. Any manual changes made directly inside /android or /ios can be lost.

That’s why Expo encourages developers to use config plugins instead of editing native files directly. Config plugins are functions that apply native changes automatically during Prebuild, making those changes repeatable and safe.

EAS Build (Cloud Builds)

While local builds are great for development and debugging, they’re not always ideal for packaging, distributing, or shipping apps. This is where EAS Build comes in.

EAS Build is Expo’s cloud-based build service. Instead of compiling your Android or iOS app on your machine, the entire build process runs on Expo’s servers, producing installable artifacts like APKs, AABs, or IPAs.

At its simplest, running:

eas build --platform all

Uploads your project to EAS Build, where it is compiled in a clean, consistent environment for both Android and iOS.

How EAS Build works with CNG

This is where a lot of confusion usually comes from.

EAS Build does not replace Continuous Native Generation (CNG). It uses it.

• If your project does not have /android and /ios folders, EAS Build will run Prebuild (CNG) in the cloud to generate them.
• If your project already has /android and /ios, EAS Build will use those native projects as they are and will not regenerate them.

Either way, native code is still prepared using the same CNG system. The difference is simply where the process runs and who compiles the app.

What EAS Build is really good at

EAS Build is optimized for distribution and automation, not daily iteration. It shines when you need to:

• build production-ready binaries for app stores
• share builds with testers using internal distribution links
• avoid local Android or iOS environment setup
• ensure consistent builds across a team
• automate builds using CI or EAS Workflows
• manage signing credentials without manual setup

Because builds run in the cloud, every build starts from a clean environment, reducing “works on my machine” problems.

The key takeaway

EAS Build focuses on packaging, distribution, and automation.
Local builds focus on fast iteration and debugging.
Both rely on the same CNG system underneath.

Once you understand that, the relationship between local builds, cloud builds, and native code becomes much easier to reason about.