At Expo we care about speed. Speed of iteration, speed of development, speed of the app, and also the speed of your app's builds. To keep it minimal it we employ numerous mechanisms:

• we use best available infrastructure for the job (like Apple Silicon),
• VMs come with useful tools preinstalled so you don't need to wait for them to install,
• we maintain proxy cache servers for Node.js, NPM and CocoaPods for faster and more reliable downloads

…but we’re always searching for ways to get faster…

The CocoaPods cache server is good, but what if we could serve Pods from the local filesystem rather than the network?

In the first half of November we added “warm” CocoaPods cache to every Mac VM image. It includes popular remote Pods that your app may need.

The cache is created by building different Expo apps on a single worker and uploading the resulting ~/Library/Caches/CocoaPods to the cloud. When building VM templates we include that directory in the resulting image, so your builds run faster and don't rely on the network.

In total the cache comes close to 5 GB and saves, on average, a minute from your iOS build time. For a blank new app this means “Install Pods” took 1:37 before and now it takes a whopping 12 seconds.

Another way you could speed up your builds is custom caching. By configuring cache property in eas.json, you can tell EAS which directories you would like to be automatically saved and restored. Read more at “Custom Caching”.

Build logs can be difficult to parse and it can be even harder to find and resolve the root cause for those errors. To make build errors easier to resolve, we're introducing a feature that adds annotations to build errors that highlight reasons and fixes for commonly seen build errors. Build Annotations can be spotted on both build and submission logs.

So if your build or submission fails, look out for the blue speech bubble in your logs in case we have any suggestions on resolving it.

When you want to build a preview version of your app to test out some changes, it can be tedious to manually go through the process of running EAS CLI to build your app after pushing or pulling down the latest changes from your repository. You have to find the right branch or tag to pull down, install EAS CLI, log in, choose the right build profile, and run the build command locally.

With Automatic GitHub builds, we eliminate all of those manual steps. By setting up build triggers, your project is automatically built whenever you push updates to GitHub, ensuring that your latest builds are up to date with your codebase.

The steps are simple. Just link a repository on expo.dev, add a build trigger, and push to your repository. If you've run a build on EAS before, this will be a smooth process. (If you haven't run a build you can learn how to create your first build here.)

You can customize build triggers for branches, pull requests, and Git tags. For example, running an iOS production build when main gets pushed or creating an Android development build when any pull request with a source branch matching feature/* gets updated.

We decided to develop and ship Automatic Github builds because we want developers focused on business logic and shipping beautiful applications, not developing and maintaining a complex CI/CD system.

This feature is now in preview for EAS subscribers, with general availability slated for 2024. There are many more improvements to come!

Learn more about how to get set up with our GitHub builds guide.

Expo Orbit for macOS makes it faster and easier to install and run builds from EAS or elsewhere, and to run Snack projects on simulators and physical devices.

The current process for installing builds from EAS (Android device/emulator, iOS simulator, iOS device) and running Snack projects on simulators is more manual than it needs to be. You can use eas build:run and select a build for Android devices/emulators or iOS simulators, or you can download the archive, extract it, and drag and drop it to the simulator/emulator. For Snack projects, additional steps include installing Expo Go in the simulator through the CLI, logging in, and selecting the Snack from a list.

To improve this, in August 2023 we released Orbit as an experiment intended to speed up development builds and Snack projects. The goal was to make these steps as seamless as possible, aligning with the user-friendly experience that Expo offers. The community feedback was very positive and we decided to move forward with this project.

Expo Orbit v1 is a macOS menu bar app designed to make your development workflow even faster, allowing you to:

• List and launch simulators, including the ability to run Android emulators without audio

• Install and launch builds from EAS to your simulators and real devices with just one click

• Launch Snack projects in your simulators by clicking a button

• Install and launch apps from local files using Finder or just drag and drop a file into the menu bar app. Orbit supports any Android apk, simulator compatible .app, or ad-hoc signed apps

• See pinned projects and quickly launch your latest builds

You can download Orbit via Homebrew or directly through GitHub.

brew install expo-orbit

At this point in time, Orbit is compatible only with macOS but we have exciting plans to integrate it further into the Expo ecosystem and add even more features.

Try out Expo Orbit now, explore its capabilities, and share your feedback. Your input will shape the future of this tool and guide us on where to take it next.

One month ago, on September 11th, Node 16 reached end-of-life and it no longer receives any form of support. For that reason, effective November 27th, 2023, we will migrate the default Node version from 16 to 18 on all EAS Build images. We have already updated the latest image accordingly.

In the process of doing the Node.js upgrade, we will also drop our Ubuntu 18 images, because they do not support Node 18. The lowest available Ubuntu version will be 20.

The default Node version on EAS Build tracks the current maintenance LTS (see: Node.js releases). This is common practice for similar hosted services.

If you aren’t ready to make any changes yet and want to ensure that you remain on Node 16 after the effective date of the upgrade: you can explicitly lock your builds to Node 16 by adding the following to your build profiles: "node": "16.18.1".

To prepare your app for the upgrade (recommended), you can do the following:

• Use Node 18+ locally: It’s likely that your project already runs on Node 18 or higher — most developers are already using a recent version on their local machines. If not, update to Node 18 or greater on your local development machine, then ensure your dependencies install successfully and your app runs.
• Opt in early to Node 18 on EAS Build
  • Set "image": "latest" on your build profiles, or, alternatively, "node": "18.18.0" to install Node 18 on your currently used image.
• Switch to Ubuntu 20+ for Android builds on EAS Build
  • Ubuntu 18 is used by default on SDK 45 (released May 5, 2022, it includes React Native 0.67) and older, so you are likely already using Ubuntu 20+ for your Android builds — unless you explicitly specify ubuntu-18.04-jdk-8-ndk-r19c or ubuntu-18.04-jdk-11-ndk-r19c as your build image.
  • If you haven’t specified an image and you want to know which is used for your project: find a recent build and look at the “Spin up build environment phase” - you will find a log similar to Using image "ubuntu-20.04-jdk-11-ndk-21.4.7075529" based on "ubuntu-2004-focal-v20220823".

Most apps are unlikely to experience any issues as a result of this change; however, in some cases, projects may not build. For example, you may encounter dependencies that are incompatible with Node 18.

To keep your builds green, we encourage developers to either lock down the Node version, or prepare for the change / opt-in early, as suggested above.

If you are still unsure how to proceed, we recommend you ask questions in our 💬 Discord community.