DEV Community: Debojit Das

Local Builds vs. EAS Cloud: When to Use Which?

Debojit Das — Tue, 16 Jun 2026 09:13:00 +0000

When you look at your terminal history, you can compile your app in two very distinct ways using EAS:

Cloud: eas build --platform ios --profile production
Local: eas build --platform ios --profile production --local

Both commands yield a production-ready .ipa or .aab file. But one runs on a remote server farm, while the other spins up your laptop fans until they sound like a jet engine. Why should you choose one over the other? Let’s break down the technical trade-offs.

Why You Should Build Locally (The Local Advantage)

Building locally means compiling the code right on your own hardware (like a MacBook or a dedicated mini-server). Here is why this route is incredibly powerful:

Zero Queue Times: The free EAS cloud tier places you in a shared public queue. During peak developer hours, you might wait 15 to 30 minutes just for your build to start. Local builds execute instantly the second you hit enter.
Bypassing Internet Bandwidth Limits: A cloud build requires uploading your entire packed project to Expo's servers. If you are working on a connection with slow upload speeds, uploading a project packed with assets can take forever. A local build stays right where it is.
Infinite Free Builds: You are completely limited by your own hardware. You can build 50 binaries a day without worrying about resource credits or billing thresholds.

Why You Must Consider the Cloud (The Cloud Advantage)

Despite the convenience of local builds, the cloud version is often the safest, most reliable bet for production. Here is why:

The Shared Vault Security: Cloud builds read variables straight from your cloud dashboard (eas env). Local builds strictly obey your .gitignore, meaning you must constantly ensure your .env.local files are perfectly in sync or risk compiling an app with missing or completely blank environment variables.
Cross-Platform Independence: You cannot compile a native iOS .ipa file on a Windows machine. If you are building cross-platform apps and don't own an expensive Mac mini server to handle iOS code signing, the EAS cloud is your only viable path forward.
Clean Slate Reproducibility: Your local machine accumulates configuration cruft over time. A cloud build runs on a sterile, standardized virtual machine instance. If a cloud build passes, you know with 100% certainty that your code is globally reproducible.

The Cheat Sheet Matrix

Scenario	Preferred Approach	Why?
Rapid Internal Testing	Local Build	Instant execution, no cloud queue delay.
Final App Store / Play Store Release	Cloud Build	Clean cache, handles production `eas env` perfectly.
Developing on Windows/Linux	Cloud Build	Mandated to compile the iOS binary.
No Internet / Low Upload Speed	Local Build	Bypasses massive source code archive uploads.

[ignore keywords: "eas build local vs cloud", "how to run eas build locally", "compile react native app without mac", "advantages of local mobile app builds", "expo build environment configuration"]

How to Maximize Profit Out of EAS (And When to Buy the Subscription)

Debojit Das — Tue, 16 Jun 2026 09:10:46 +0000

As an indie hacker building an app ecosystem, every single dollar matters. When you look at Expo’s pricing page, jumping from the Free tier to the On-Demand or Production plans can feel like a steep commitment.

However, you can stay on the EAS Free Tier for an incredibly long time if you optimize your workflow correctly. Let’s break down how to get maximum value for zero dollars, and the exact moment your business dictates buying a subscription.

1. The Free Tier Optimization Blueprint

Expo's free tier gives you a generous allowance of cloud builds and free OTA update bandwidth. To maximize your profit margins, follow these rules:

Don't Waste Cloud Build Slots on Bugs: Never trigger an eas build to test if a feature works. Use a local release simulator build (npx expo run:ios --configuration Release) to catch syntax errors or missing environment variables on your own machine.
Keep Your Assets Lean: EAS Update allows a massive amount of free data transfer, but it counts bytes. Compress your images, use SVG icons instead of massive PNGs, and host large assets (like onboarding videos) on external storage instead of embedding them directly in your app bundle.

2. When to Move to On-Demand (Pay-As-You-Go)

You do not need a monthly subscription to get out of the free build queues. If your app is growing and you find yourself constantly waiting 20 minutes behind other developers in the free cloud build queue, you can transition to On-Demand billing.

For a few dollars per build, you can buy high-priority slots that jump you straight to the front of the line. This is ideal when you are actively scaling up TestFlight testing or pushing crucial launch updates.

3. The Turning Point: When to Buy the $29/mo or $99/mo Plan

There are three specific thresholds where buying a flat monthly EAS subscription becomes mathematically profitable:

Team Collaboration: If you scale your business and bring in other stakeholders—like a business manager, designer, or public relations lead—managing a shared pipeline requires advanced team controls and automated workflows.
Heavy Build Volume: If you are managing multiple apps simultaneously and deploying weekly, paying a flat subscription beats paying individual on-demand fees.
Enterprise Features / Custom Certificates: If you need dedicated concurrency (running multiple builds at the same exact time) or require specific compliance architectures, the subscription pays for itself in time saved.

Summary

Start completely free. Guard your free tier bandwidth by optimizing assets and testing your release binaries locally. Only let real user traction or queue frustration dictate your spending.

[ignore keywords: "Expo EAS pricing optimization", "How to use Expo free tier in production", "When to upgrade to EAS paid plan", "Expo OTA update bandwidth limits", "Maximize profit mobile app development"]

Why Use Expo EAS in the First Place? (The Honest Truth)

Debojit Das — Tue, 16 Jun 2026 09:07:11 +0000

When you are a solo developer or running a tiny dev shop, your most valuable asset isn't your code—it's your time.

For a long time, the standard workflow for building a React Native app looked like this: you open your terminal, type cd android && ./gradlew bundleRelease && cd .. for Android, and then spend another 20 minutes clicking through Xcode archives on a Mac to ship to iOS. It works, it's free, and it feels comfortable.

So why on earth should you disrupt your setup to migrate to Expo Application Services (EAS)? Is it just a shiny tool, or does it actually change the game?

Let’s talk about why EAS is practically mandatory for modern mobile developers.

1. The Matrix of Native Dependencies

When you build a standard React Native app locally, you are managing a fragile house of cards: the exact version of CocoaPods, the specific Android Gradle Plugin, your local Java JDK version, and the version of Xcode installed on your machine. If any of these drift out of sync, your build breaks, and you waste three hours on StackOverflow.

EAS abstracts this entire nightmare away using EAS Build. It spins up temporary, perfectly configured container instances in the cloud to compile your .ipa and .aab files. Your local machine's clutter can no longer poison your production bundle.

2. Over-The-Air (OTA) Updates: The Ultimate Safety Net

Imagine shipping an update to TestFlight or the App Store, and five minutes later, your analytics show that a rogue null pointer is crashing the app for 100% of your users.

Without EAS, you have to write a patch, re-compile the app, submit a new build, and pray that Apple or Google approves your emergency review within 24 hours.

With EAS Update, you fix the JavaScript file locally and push an OTA update in seconds:

eas update --branch production --clear-cache

The next time the app opens on a user's phone, it silently downloads the fix. You just saved your launch week without waiting for App Store approval.

3. Apple/Google Credentials Managed on Autopilot

If you’ve ever had to manually generate an iOS Provisioning Profile, configure a distribution certificate, or handle push notification keys in the Apple Developer Portal, you know how painful it is. EAS automates this completely. The first time you run a build, it securely asks for your developer login, hooks up the credentials, and links them perfectly to your cloud profile.

Summary

You don't use EAS just to build binaries; you use it to buy your peace of mind. It turns a manual, error-prone DevOps pipeline into a standardized, bulletproof execution system.

[ignore keywords: "Why use Expo EAS build", "Expo EAS vs manual Xcode archive", "Benefits of Expo OTA updates", "React Native cloud build pipeline", "Is Expo EAS worth it for solo developers"]

The Bulletproof Guide to Setting Up Expo EAS & OTA Updates (Without the Tears)

Debojit Das — Tue, 16 Jun 2026 08:26:17 +0000

Setting up Expo Application Services (EAS) and Over-The-Air (OTA) updates for the first time feels like unlocking a developer superpower. The promise is incredible: ship bug fixes directly to your users' phones instantly, completely bypassing the App Store review process.

But if you set it up incorrectly, that superpower quickly turns into a nightmare of instant crashes, poisoned update channels, and the dreaded White Screen of Death (WSOD).

I recently navigated this minefield while building a production React Native app using Supabase and RevenueCat. I learned the hard way that the gap between local development and cloud builds is filled with hidden traps.

If you are setting up EAS and expo-updates from scratch, this step-by-step guide will ensure you get it right on the very first try.

Step 1: Master Your Environment Variables

This is where 90% of developers fail on their first EAS build. In local development, your app magically reads your .env file. In the cloud, your .env file is ignored (thanks to .gitignore), leaving your API keys blank and crashing your app on launch.

The Golden Rules of Expo Environments:

The Prefix: Any API key that your frontend React Native code needs to read (like your Supabase URL or RevenueCat Public Key) must start with EXPO_PUBLIC_. If it doesn't, the Metro bundler will actively strip it out of your production build for security.
The Local File: Keep a single .env.local file on your machine for development.

Your .env.local should look like this:

EXPO_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
EXPO_PUBLIC_SUPABASE_ANON_KEY=your-anon-key
EXPO_PUBLIC_REVENUECAT_IOS_API_KEY=appl_your_key

Upload to the Cloud:
Before you ever trigger a build, you must upload these exact variables to the EAS servers so they can be injected into your production app. Run these commands in your terminal:

eas env:create --name EXPO_PUBLIC_SUPABASE_URL --value "https://your-project.supabase.co" --environment production --visibility plaintext
eas env:create --name EXPO_PUBLIC_SUPABASE_ANON_KEY --value "your-anon-key" --environment production --visibility plaintext

Check your work by running eas env:list --environment production.

Step 2: Bulletproof Your `app.json`

EAS runs strict validation checks on your project manifest. If you have sloppy configuration, your OTA updates will be rejected at the 99% mark.

Keep it DRY (Don't Repeat Yourself): Scroll through your app.json. Ensure you do not have duplicate entries in your iOS UIBackgroundModes, Android permissions, or intentFilters.
Lock in the Runtime Version: OTA updates need to know which native binary they belong to. Add a strict runtime version to your app.json:

{
  "expo": {
    "name": "MyApp",
    "runtimeVersion": "1.0.0",
    "updates": {
      "url": "https://u.expo.dev/YOUR-PROJECT-ID"
    }
  }
}

Step 3: Configure `eas.json` Correctly

When you initialize EAS (via eas init), it generates an eas.json file. You need to explicitly tell your production profile to pull down the cloud environment variables you set up in Step 1, and map the build to an update channel.

Edit your eas.json to look like this:

{
  "build": {
    "production": {
      "channel": "production",
      "environment": "production"
    }
  }
}

Note: The "environment": "production" line is the magic link that pulls your eas env keys into the build.

Step 4: The Local Safety Check

Do not skip this step. Waiting 30 minutes in the EAS cloud queue just to discover your app crashes on launch is a brutal loop.

Because you are likely using custom native code, you can compile and test the true production release right on your local machine.

Run this command:

npx expo run:ios --configuration Release

(Or run:android --variant Release)

If the app boots up on your simulator, connects to your database, and doesn't white-screen, your JavaScript and native configurations are rock solid.

Step 5: The First Cloud Build

Now you are ready for the cloud. Trigger your first production build for TestFlight or the Google Play Console:

eas build --profile production --platform all

A Warning About Local Builds: If you try to save queue time by running eas build --local, the EAS CLI will ignore your local .env and will not reach out to the cloud to get your eas env variables. It will build a blank app. Always use the cloud build for your first clean run, or run eas env:pull before attempting a local EAS build.

Step 6: Pushing Your First OTA Update Safely

Once your app is live on TestFlight or the App Store, you will eventually want to push a bug fix over the air.

Unlike eas build (which happens in the cloud), eas update bundles your JavaScript locally on your computer before uploading it. This means it relies entirely on your local terminal's environment variables.

If your Metro bundler has stale cache, it might bundle your app without your EXPO_PUBLIC_ keys, resulting in a "poisoned" update that instantly crashes your users' apps.

The Golden Command for OTA Updates:
Always force Metro to clear its cache when pushing to production so it strictly reads your .env.local file:

eas update --branch production --clear-cache

Provide an update message when prompted, and within seconds, your users will download the fresh, bug-free JavaScript bundle the next time they open the app.

Summary

By moving your client keys to eas env, cleaning up your app.json, and respecting the Metro cache during eas update, you completely eliminate the friction of modern app deployment. You can now build, iterate, and ship OTA updates with total confidence.

[ignore keywords:
"How to set up Expo EAS from scratch"

"Expo OTA updates complete beginner guide"

"How to use environment variables in EAS build"

"Expo runtime version best practices"

"EAS build local vs cloud environment variables"

"How to trigger safe expo updates"

"React Native build production ipa and aab"

"Preventing poisoned OTA updates in Expo"
]

How to Fix React Native EAS Build White Screens and OTA Crashes (A Complete Guide)

Debojit Das — Tue, 16 Jun 2026 07:47:55 +0000

If you are transitioning your React Native or Expo app from traditional local builds to Expo Application Services (EAS) and Over-The-Air (OTA) updates, you might feel like you just gained a superpower.

That is, until you download your app from TestFlight and are greeted by a completely blank white screen. Or worse, the app instantly crashes before it even loads.

I recently migrated an app to EAS and ran into these exact issues. In development, everything worked perfectly. In production, everything fell apart. After hours of parsing system logs, I realized the problems weren't with my code, but with how EAS handles environment variables and OTA updates.

If your Expo app is white-screening or crashing in production, here is the complete, beginner-friendly guide to fixing it.

Part 1: The White Screen of Death (WSOD)

The Symptom

Your app works flawlessly on your local simulator. You build it for iOS or Android, install it on a physical device, and it hangs forever on a blank white screen.

If you plug your phone into your computer and check the device console, you will likely see a fatal JavaScript error that looks like this:

Unhandled JS Exception: [runtime not ready]: Error: EXPO_PUBLIC_SUPABASE_URL environment variable is not set or is empty, js engine: hermes

Or this:

[runtime not ready]: Invariant Violation: "main" has not been registered. This can happen if:
* Metro (the local dev server) is run from the wrong folder.
* A module failed to load due to an error and `AppRegistry.registerComponent` wasn't called.

The Root Cause: The Environment Variable Trap

When you run a local development server, your bundler easily reads your .env file to get your API keys (like your Supabase URL).

But when you build your app for production—whether on Expo's cloud servers or using a local EAS build—your .env file is left behind because it is in your .gitignore. If your app tries to initialize a database connection without those keys, the React tree silently crashes before rendering the UI.

The Fix: Properly Exposing Your Keys

Step 1: Use the EXPO_PUBLIC_ Prefix
EAS has a strict safety mechanism: it will ignore any environment variable that does not start with EXPO_PUBLIC_. This prevents you from accidentally shipping secret admin keys into your public app.
Only client-side APIs should have this prefix.

Change your code and your environment files to look like this:

EXPO_PUBLIC_SUPABASE_URL=https://your-project.supabase.co
EXPO_PUBLIC_SUPABASE_ANON_KEY=your-anon-key

Step 2: Upload Environment Variables to EAS
If you are using Expo's cloud to build your app, you need to securely pass these variables to their servers. Open your terminal and run:

eas env:create --name EXPO_PUBLIC_SUPABASE_URL --value "your_prod_url" --environment production --visibility plaintext

(Repeat this for every client-side variable your app needs).

Once done, verify they were uploaded properly:

eas env:list --environment production

Step 3: Link the Environment in `eas.jsonYou must explicitly tell your build profile to pull down the production variables you just uploaded. Check youreas.json thoroughly. The "environment": "production"` key must exist inside your build object.

{
  "build": {
    "production": {
      "autoIncrement": true,
      "environment": "production"
    }
  }
}

Part 2: The Local Build Caveat (`--local`)

To save on cloud computing costs and avoid queue times, many developers build their .ipa or .aab files locally using the --local flag.

The Trap: If you run eas build --platform ios --profile production --local, EAS isolates your project in a temporary folder. It still ignores your .env file, and because it is offline, it does not fetch the variables you uploaded to the cloud in Step 2. You will end up with another white screen.

The Fix: Before building locally, you need to create an .env.local file in your root directory.

You can either manually copy-paste your variables into it, or—especially if you are collaborating with others—pull them directly from the cloud:

eas env:pull --environment production

Before you waste time building the full .ipa, test your production environment locally on your simulator to ensure no white screens appear:

npx expo run:ios --configuration Release

Once that works, you can safely run your local build:

eas build --platform ios --profile production --local

Part 3: Instant Crashes and Poisoned OTA Updates

The Symptom

You successfully fix the white screen, but after pushing an Over-The-Air (OTA) update using eas update, TestFlight users report the app instantly crashes the millisecond it opens.

If you look at the logs, you might see Apple's system daemon logging a user force-quit after a freeze:

ExceptionCode: "User Initiated Quit (0xDEADFA11)"

Or, when trying to push the update, you get a rejection from Expo:

Manifest Validation Error:
android/intentFilters:must NOT have duplicate items (items ## 0 and 1 are identical)

The Root Cause: Poisoned Bundles & Dirty Manifests

Unlike eas build (which uses the cloud environment), eas update bundles your JavaScript entirely on your local machine. If your local terminal doesn't have the EXPO_PUBLIC_ variables loaded, you will push an update with blank API keys.

Because your app.json has a set "runtimeVersion", every user who opens the app immediately downloads this broken update, overwriting your good code and bricking the app. You have "poisoned" the update channel.

Furthermore, EAS runs strict validation on your app.json during updates. If you have duplicate iOS background modes or Android permissions, the update will fail.

The Fix

1. Clean up `app.jsonEnsure you have absolutely no duplicate entries in yourintentFilters, permissions, or UIBackgroundModes`.

2. Bump the Runtime Version
To escape the poisoned OTA loop, simply sever the link. Open app.json and change your runtime version.

"runtimeVersion": "1.0.1",

3. Clear Cache and Update
Ensure your .env.local file is populated. Then, force Metro to clear its cache and push a clean update to the new runtime version:

eas update --branch production --clear-cache

Finally, build a fresh .ipa or .aab. Because the runtime version changed, it will ignore the old, broken OTA update and boot normally.

The Ultimate Summary Checklist

To never face these issues again, follow this exact order of operations when setting up EAS and OTA updates:

Prefix Client APIs: Ensure all front-end keys start with EXPO_PUBLIC_.
Cloud Sync: Upload them to Expo via eas env:create.
Local Sync: Run eas env:pull --environment production to generate your .env.local file.
Configure eas.json: Ensure "environment": "production" is set in your production build profile.
Clean Manifest: Check app.json for any duplicate arrays or permissions.
Simulate Production: Always run npx expo run:ios --configuration Release locally first.
Build: Run eas build --profile production (add --local if you want to use your own machine's hardware).
Update: When pushing OTA fixes, always use eas update --branch production --clear-cache to prevent stale, broken bundles from deploying.

[ignore keywords:
"React Native TestFlight white screen of death"

"Unhandled JS Exception: [runtime not ready]"

"EXPO_PUBLIC_SUPABASE_URL environment variable is not set"

"Expo app working on simulator but crashing on TestFlight"

"EAS build local env file missing"

"ExceptionCode: User Initiated Quit (0xDEADFA11)"

"Invariant Violation: main has not been registered expo"

"Manifest Validation Error: android/intentFilters duplicate items"
]

DEV Community: Debojit Das

Local Builds vs. EAS Cloud: When to Use Which?

Why You Should Build Locally (The Local Advantage)

Why You Must Consider the Cloud (The Cloud Advantage)

The Cheat Sheet Matrix

How to Maximize Profit Out of EAS (And When to Buy the Subscription)

1. The Free Tier Optimization Blueprint

2. When to Move to On-Demand (Pay-As-You-Go)

3. The Turning Point: When to Buy the $29/mo or $99/mo Plan

Summary

Why Use Expo EAS in the First Place? (The Honest Truth)

1. The Matrix of Native Dependencies

2. Over-The-Air (OTA) Updates: The Ultimate Safety Net

3. Apple/Google Credentials Managed on Autopilot

Summary

The Bulletproof Guide to Setting Up Expo EAS & OTA Updates (Without the Tears)

Step 1: Master Your Environment Variables

Step 2: Bulletproof Your app.json

Step 3: Configure eas.json Correctly

Step 4: The Local Safety Check

Step 5: The First Cloud Build

Step 6: Pushing Your First OTA Update Safely

Summary

How to Fix React Native EAS Build White Screens and OTA Crashes (A Complete Guide)

Part 1: The White Screen of Death (WSOD)

The Symptom

The Root Cause: The Environment Variable Trap

The Fix: Properly Exposing Your Keys

Part 2: The Local Build Caveat (--local)

Part 3: Instant Crashes and Poisoned OTA Updates

The Symptom

The Root Cause: Poisoned Bundles & Dirty Manifests

The Fix

The Ultimate Summary Checklist

Step 2: Bulletproof Your `app.json`

Step 3: Configure `eas.json` Correctly

Part 2: The Local Build Caveat (`--local`)