Changelog

New updates and improvements to Expo and EAS.

Build time reduced by 40%

M1 workers on EAS Build

M1 workers for iOS builds are now generally available. On a simple yet non-trivial app, build times for the exact same codebase improved from ~15 minutes 30 seconds to ~9 minutes just by switching from Intel to M1 workers. That’s a ~40% reduction in build times!

We’ve seen a similar effect on other projects, but every app is different and you’ll just have to try it for yourself to find out.

You can opt in to M1 workers today in a matter of seconds by adding the resourceClass field in your eas.json.

EAS Build improvements

We also released a collection of features to improve the experience of working with builds:

  • eas build:resign allows you to swap the ad hoc provisioning profile of an existing build without re-running the full build. This means you can add a teammate's device to your ad hoc provisioning profile and re-generate the internal distribution build in about a minute.
  • eas build:run downloads a simulator build from EAS' servers and runs it directly on your simulator/emulator. This makes testing your app a snap.
  • You can now sign up for email notifications for build and submission successes and failures through your account settings.
  • You can now view the code changes associated with a build or update by connecting your GitHub repository to your Expo app. After connecting your repository, click the commit hash on a build/update details page to view the commit on GitHub.
  • Updated the ”Running E2E tests on EAS Build” guide to include information about how to run E2E tests for Android apps, which is now possible on EAS Build. The guide demonstrates integration with Detox, but you can adapt it to any tool you like — such as Maestro.
  • Manage your secrets with Doppler with their new guide.

Expo Router V1 release candidate

With the new Expo Router V1 release candidate, screens are automatically generated by creating files in your project.

You can focus on building the content of your screens rather than wrestling with all the boilerplate required to compose screens together. Take advantage of basic routes, layout routes, dynamic routes, group routes, and shared routes that work universally out of the box.

Get started with the expo-router docs.

Expo Image V1 beta

Expo image rendering avif, heic, webp, svg, png, jpeg files

expo-image is designed for speed, and it brings modern image formats to your universal apps.

  • Supports AVIF, WebP, SVG, APNG, HEIC, and ICO. (JPEG, PNG, and GIF too, of course!)
  • Disk and memory caching using the battle tested and performant libraries SDWebImage and Glide under the hood.
  • Supports blurhash, a compact representation of a placeholder for an image.
  • Smoothly transitions between images when the sources change (this is configurable).
  • Runs on Android, iOS, and web.

Get started with the expo-image docs.

EAS Update code signing

We added end-to-end security to EAS Update with code signing. This feature adds an extra layer of security and eliminates an entire class of man-in-the-middle attacks. Learn more.

Automatically increment versions in CI and across branches using the remote version source

The autoIncrement field in eas.json used to be based on local values only. Here’s how it worked: EAS CLI would read the version field, such as the iOS build number from Info.plist or app.json, then increment that value and write it back to the file it was read from. This only really works if you commit the incremented value every time, so it wasn’t a great fit for building on CI and it was a pain to keep in sync when building from different Git branches. We’ve introduced the concept of a “remote app version source” to solve for these limitations.

autoIncrement field in eas.json

Using this configuration, builds for the preview profile will read the version from the remote source, and builds for the production profile will increment and then use that version.

The appVersionSource field in eas.json allows you to switch between using local versions (as described above) or remote versions. Here’s how it works: the app version is stored on Expo’s servers rather than locally in files like Info.plist or app.json, and EAS CLI sends a request to increment the version before you run a build. If a build profile isn’t configured to increment the version, then it will only read it from Expo’s servers.

EAS CLI displaying buildNumber configuration

EAS CLI will print a log indicating the version that is incremented, along with the former and new values.

Currently the remote version source configuration is supported with buildNumber and versionCode properties. We prioritized these fields because developers typically use an automatic version scheme for them (monotonically increasing integers, commit count, and epoch time are all common). The version field often serves a marketing purpose, or communicates information about the changes from the previous version (eg: semantic versioning).

Retry failed builds and submissions directly from the website

Builds and submissions can occasionally fail due to intermittent issues such as network timeouts and service outages. Another common source of build failures is invalid but not invalidated caches. We’ve added buttons on build and submissions details pages to make it easy to retry failed builds and submissions, and clear the cache for builds if needed. If a build is initiated with the --auto-submit flag and it fails, then it will still be automatically submitted if the retried build succeeds.

Retrying failed builds on builds page.

New build lifecycle hooks

You can now hook in to builds at the following points: pre-install, post-install, on success, on error, and on complete. Hooks can be used to install tooling (eg: a specific version of CMake), interact with external services (eg: upload sourcemaps), run tests, and anything else you might want to do.

Early support for end-to-end testing on iOS builds

End-to-end tests allow you to simulate a user interacting with your app to test the most important flows through your product. A popular tool for writing end-to-end tests in the React Native ecosystem is Detox. We’ve put together a guide to walk you through running E2E tests with Detox on EAS Build, currently only for iOS.

We plan to continue expand EAS Build to provide first-class support for testing frameworks and workflows. This is just the first small step in that direction.

Beta release of EAS Metadata

EAS Metadata helps you prepare your app for review by uploading most of the required app information using a simple JSON file. It also helps you prevent common pitfalls that may lead to a rejected app submission. This service integrates into EAS Submit and is now available in beta. Give it a try and let us know what you think!

Import devices form the App Store Connect API

If you’re new to EAS Build and you’ve already been building apps for iOS devices, you may already have a number of devices registered in the Apple Developer Portal. You can now import devices from the Apple Developer Portal to EAS Build for your internal distribution builds that use Ad Hoc provisioning.

Affordances for integrating App Extensions on iOS

App extensions let you extend custom functionality and content beyond your app and make it available to users while they’re interacting with other apps or iOS system functionality.

EAS Build is now to automatically handle app signing credentials in bare projects or through the extra.eas.build.experimental.ios.appExtensions key in app.json / app.config.js if the project is generated on EAS Build with prebuild.

Assorted quality of life improvements

  • Git commit message is automatically included in build metadata. The Git commit SHA was always included, but adding the message to the website saves developers then hassle of needing to look the commit up for more context (assuming they write thoughtful commit messages).
Commit message included in build page.

Hover the commit SHA to see the message.

  • Attach messages to builds with the --message flag. These will be displayed on the website and can be inform your future self or team about the purpose of specific builds.
Message as an additional detail on the build page.
  • Show skipped prebuild phase in build logs. This helps developers to notice if they have accidentally submitted a build with ios and android directories when they may have intended to have prebuild run on EAS Build instead.
Prebuild phase skipped on build details.

The "Learn more" link, for your convenience: "iOS build process"

  • Add cli.promptToConfigurePushNotifications to eas.json to give developers the option to opt out of prompts about enabling push notifications on the project for iOS builds. While enabling push notifications is harmless, it is also not necessary for many projects. This option can be set in eas.json through the prompt itself if you choose to persist your selection.
CLI prompt for adding push notificaitons to an expo project
  • Warn when eas-cli is installed locally to project dependencies, suggest using the cli.version field in eas.json to enforce a version for the project instead.
CLI warning for when eas-cli is installed in local dependencies.

The “Learn more” link, for your convenience: “Enforcing EAS CLI version for your project”

  • Now able to sync all iOS Capabilities: EAS Build will automatically sync entitlements with Capabilities for your app on the Apple Developer Portal. Previously this worked for most capabilities, and it now supports all Capabilities that are available for iOS. Learn more in the “iOS Capabilities” reference.

  • In case you missed it: autocomplete and IntelliSense support for eas.json and store.config.json is now available in Expo extension for Visual Studio Code.

Autocomplete in the Expo VSCode Extension.

IntelliSense in eas.json. Notice that all information from the schema is available directly in your editor — supported keys, values, and descriptions. It will be hard to go back to looking up properties in documentation after you have them all available through IntelliSense in Visual Studio Code.