Fixing Slow Expo EAS Build Times on the Free Tier

According to recent industry benchmarks in mobile DevOps, build pipeline latency is a primary contributor to developer churn, with teams reporting that waiting more than 15 minutes for a build to complete can reduce daily deployment frequency by up to 40% (Source: DORA State of DevOps Report). For developers relying on Expo Application Services (EAS) to manage their React Native build lifecycles, the free tier often becomes a bottleneck. When your project grows beyond a simple template, the shared infrastructure provided by the free tier can lead to significant queue times and slow execution speeds.

This article provides a deep dive into the technical reasons behind build latency in the Expo ecosystem and offers actionable strategies to optimize your configuration. We will explore how to manage dependencies, prune build artifacts, and structure your repository to minimize the time your project spends in the EAS queue.

Understanding the Expo EAS Build Infrastructure

EAS Build operates by spinning up ephemeral virtual machines to compile your React Native code. In the free tier, these machines are shared resources. When you trigger a build, your request enters a global queue. If the demand for compute resources is high, your build will wait for an available worker node. This is the most common cause of perceived slowness that is entirely outside of your control. The official expo.dev documentation clarifies that free-tier builds are subject to queue priority, meaning your build will always be deprioritized in favor of paid plans.

Beyond queueing, the build process itself consists of several distinct stages: provisioning the environment, installing dependencies (npm install or yarn install), running pre-build scripts, executing the native compilation (Gradle for Android, Xcode for iOS), and finally bundling the application. If your node_modules folder is bloated or if you are running unnecessary build-time scripts, the compilation phase will drag significantly. The key to optimizing this is to treat your build environment as a lean production machine rather than a development environment.

Optimizing Dependency Resolution

One of the most frequent causes of slow build times is the overhead associated with dependency resolution. Every time a build starts, EAS must fetch your package.json, resolve the dependency tree, and download every package from the registry. If you have a large number of development dependencies (devDependencies) that are not strictly required for the final production binary, you are wasting time and bandwidth. Always ensure that your package.json correctly separates production dependencies from dev dependencies.

Furthermore, use a lockfile consistently. If you are using yarn, ensure yarn.lock is present; if npm, ensure package-lock.json is committed. This prevents the build server from spending time re-calculating dependency versions or resolving conflicting sub-dependencies. A critical optimization is to use npm ci instead of npm install in your CI/CD configuration. The npm ci command is specifically designed for automated environments, as it is strictly deterministic and significantly faster because it bypasses the dependency tree verification process required by a standard install.

Leveraging EAS Build Cache Effectively

EAS Build supports caching to speed up subsequent builds. By default, the service caches node_modules and other common directories. If you frequently change your dependencies, you might be invalidating this cache unnecessarily. You can explicitly configure your eas.json to control which directories are cached. Excessive cache invalidation forces the build machine to download and install everything from scratch, which is the single biggest performance killer in the pipeline.

To verify that your cache is working, check the build logs for Restoring cache messages. If you see that the cache restoration is failing or being skipped, investigate your eas.json configuration. You should also ensure that your .gitignore file is correctly configured to prevent non-essential files from being uploaded to the build servers. Uploading unnecessary files increases the time taken for the initial project payload transfer, which is a major factor in total build time.

Minimizing Native Compilation Overhead

The native compilation phase, particularly for iOS via Xcode, is inherently resource-intensive. If your project includes a massive number of native modules, the build server will spend a disproportionate amount of time compiling C++ and Objective-C/Swift code. To mitigate this, consider using Expo Modules rather than traditional React Native linkable modules. Expo Modules are pre-compiled or structured to be more build-friendly within the EAS ecosystem.

Additionally, avoid running heavy tasks during the prebuild or postinstall hooks. If you have scripts that perform image optimization, code generation, or linting during these phases, move them to a separate CI step or execute them locally before pushing your code. Every second spent running a script on the build server is a second added to your total build time. Keep your build environment as simple as possible to ensure that the primary focus of the virtual machine is the final binary compilation.

Strategic Asset Management

Large assets, such as high-resolution images, videos, or massive JSON data files, can significantly inflate your bundle size and increase the time it takes for the build server to package your application. If your application relies on large assets, consider moving them to a remote CDN and fetching them at runtime. By reducing the size of the binary that must be compiled and signed, you reduce the time required for the final packaging stage.

If you must include assets in your bundle, ensure they are optimized. Use tools like sharp or other image compression utilities locally to reduce the file size before committing them to your repository. The build server should not be responsible for processing or compressing your assets. By pre-processing these items, you ensure that the build process remains focused solely on merging your JavaScript bundle with the native shell.

Branching and Environment Configurations

It is common practice to use different eas.json profiles for development, staging, and production. If your development profile is configured to include debug symbols, source maps, or additional logging, these will increase build times. Ensure that your production profile is strictly optimized for performance. You can disable source maps and debug symbols in your production build configuration within eas.json to shave off valuable minutes.

Furthermore, avoid triggering builds on every single commit. Use a CI/CD strategy that only triggers an EAS build when a pull request is merged to the main branch or when a tag is pushed. If you use a continuous integration tool like GitHub Actions, you can coordinate these triggers to avoid unnecessary build cycles. This not only saves you time in the queue but also ensures that you are only using your limited resources for meaningful deployment attempts.

Reviewing Build Logs for Bottlenecks

When a build feels sluggish, the first step is to analyze the build logs. EAS provides detailed timestamps for each step of the build process. Look for phases that take an unusually long time. For example, if the Install dependencies step takes 10 minutes, you know exactly where the problem lies. If the Build phase is the bottleneck, you may need to look at your native code complexity.

By identifying the specific phase causing the delay, you can apply targeted optimizations. Do not guess where the time is being spent; use the data provided in the build dashboard. If you notice that the queue time is consistently long, it is a clear indicator that the shared infrastructure is under heavy load, and there is unfortunately no technical fix for this other than optimizing your project to be as fast as possible once it finally starts.

The Role of Expo Prebuild

Using expo prebuild locally can help you catch potential issues before they reach the EAS servers. If you can successfully run npx expo prebuild on your local machine, you have a better understanding of what the build server is doing. This process generates the native folders (android and ios). If the generation process is slow locally, it will be slow on the server.

By debugging locally, you can resolve issues with dependency conflicts or configuration errors without waiting for the EAS queue. This proactive approach is essential for maintaining a fast development loop. When you commit your changes with a clean, pre-built environment, you reduce the risk of the build server failing due to configuration drift or environment-specific issues.

Further Resources

Optimizing your build pipeline is an ongoing process that requires balancing developer convenience with production performance. As your project evolves, periodically revisit your eas.json and dependency tree to ensure that your build remains efficient. [Explore our complete Software Development directory for more guides.](/topics/topics-software-development/)

Addressing build latency on the free tier requires a disciplined approach to dependency management, caching, and asset handling. By focusing on the factors you can control—such as using deterministic lockfiles, optimizing assets, and minimizing native compilation overhead—you can significantly improve your build times despite the limitations of shared infrastructure. While the free tier will always be subject to queueing, these optimizations ensure that your project is ready to compile as efficiently as possible the moment a worker node becomes available.