EAS Build Q3 2022 - Expo Changelog

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.

{
  "cli": {
    "appVersionSource": "remote"
  },
  "build": {
    "preview": {
      "distribution": "internal"
    },
    "production": {
      "autoIncrement": true
    }
  },
}

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).

Get started with remote versions and learn more about app version management.
Remote versions work great with the new appVersion runtime version policy. Learn more.
Shout out to @jnybgr for increment.build — this was a popular alternative to local auto incrementing versions and an inspiration for this feature.
Should we enable remote versions by default on all new projects? Let us know what you think on Twitter: Expo

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.

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.

Learn more in “Build lifecycle hooks”

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.

Learn more in “Running E2E tests on EAS Build”

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!

Learn more in the EAS Metadata Introduction or skip ahead to the Getting Started guide.

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.

Watch a demonstration video in the pull request that adds this feature.

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.

Learn more about iOS App Extensions on EAS Build.

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.

Join us on Discord to discuss this post.