Building and Releasing

Introduction

An app on your computer helps nobody. This final lesson takes you from "it works on my phone" to "people can install it." The steps have many names, but they are a short sequence: build the app files, test them on real devices, submit them to the stores, and update them afterwards.

Build with EAS

EAS (Expo Application Services) is Expo's cloud service. EAS Build builds your app for you, so you can produce an iPhone app without owning a Mac. The docs describe it as "a hosted service that builds app binaries for Expo and React Native projects", and it can also manage your signing credentials, the certificates that prove the app comes from you.

Install the command line tool, sign in, and set up your project:

npm install --global eas-cli
eas login
eas build:configure

eas build:configure creates an eas.json file next to package.json. It holds build profiles: named sets of settings. A new project gets three:

{
  "build": {
    "development": {
      "developmentClient": true,
      "distribution": "internal"
    },
    "preview": {
      "distribution": "internal"
    },
    "production": {}
  }
}

• development: a development build with expo-dev-client, for you, as in the last lesson.
• preview: a release-like build you install directly on test devices ("distribution": "internal" means outside the stores), for friends, testers and your own final checks.
• production: the build you send to the stores.

Run a build with the profile name:

eas build --platform android --profile preview
eas build --platform ios --profile production
eas build --platform all

When it finishes you get a link. For internal distribution on Android that is an installable APK file. For the Google Play Store you upload an Android App Bundle (an .aab file), which the production profile produces. For iPhone, the output is an .ipa file.

Identity and versions

Before releasing, get the identifiers right in your app config. Reread the previous lesson's example; these matter most:

There are three kinds of number, and beginners mix them up:

• version is the number people see: "1.2.0". On iPhone it becomes CFBundleShortVersionString and on Android versionName.
• ios.buildNumber and android.versionCode are the number the store uses to tell one upload from another. The docs say the Google Play one must be a positive integer that you "increment by one for each release." Each upload to a store needs a higher number than the one before. EAS can raise these for you automatically with the autoIncrement option in a build profile.
• bundleIdentifier and package are the app's permanent unique ID. After the first release they must never change, because the stores treat a different ID as a different app.

The icon should be a 1024 by 1024 pixel PNG, as the docs recommend.

Keep secrets out of the app

Anything inside the app bundle can be read by anyone who downloads it. The Expo docs are clear: variables with the EXPO_PUBLIC_ prefix are put into your JavaScript at build time, and "will be visible in plain-text in your compiled application." Use them for settings that are fine to be public, such as a server address.

Never put a secret in an EXPO_PUBLIC_ variable: not a database password, not a private API key. Keep secrets on your server, and make the app talk to your server, which holds them.

Store accounts

To publish you need developer accounts:

• Apple Developer Program for the App Store. It is a paid yearly membership, at the time of writing about 99 US dollars a year.
• Google Play Console for Google Play. It is a one-time registration fee, at the time of writing about 25 US dollars.

Fees and rules change, so check Apple's and Google's own pages before you pay. Both stores also ask for things you should prepare early: a privacy policy at a public web address, screenshots, a description, an age rating, and a form describing what data your app collects. Apps that collect accounts or personal data are reviewed more closely.

Submit

EAS Submit uploads the build for you:

eas submit --platform android
eas submit --platform ios

A few facts from the docs:

• For Google Play you must create the app in Play Console before your first submission.
• For a brand new Android app, the default submission goes to the internal testing track first. To reach the public, finish the store listing in Play Console and promote the release.
• For iPhone, if the app is not in App Store Connect yet, EAS can create it after you sign in with your Apple ID.

After you submit, the store reviews your app. Apple's review usually takes a day or two. Google's can take longer for new accounts. A rejection comes with a reason, and you fix it and submit again.

Updating without the stores: EAS Update

Waiting for a store review to fix a typo is slow. EAS Update can send changes to users' phones over the air. The docs say it lets an app receive fixes "between app store submissions by updating JavaScript, styling, and images."

npx expo install expo-updates
eas update:configure
eas update --channel production --message "Fix login button alignment"

Know the limits. An update can change JavaScript, styling and images, and so cover bug fixes, text changes and screen layouts. It cannot change native code, native libraries, app permissions or the Expo SDK version. Those need a new build and a store release. To keep an update from reaching a build that cannot run it, Expo uses a runtime version: "updates are only sent to builds with compatible native code."

Updates must still follow the store rules. The docs remind you to "follow the rules of the platforms and app stores you are building for," and changing what the app does in a big way usually needs a new review.

A release checklist

• Tested a release-like build (the preview profile) on a real iPhone and a real Android phone.
• Tested bad network, no network, and denied permissions.
• App name, icon, splash screen, bundle ID and package set correctly.
• Version and build numbers raised.
• No secrets in the bundle, and no leftover console.log noise.
• Privacy policy published, store listing, screenshots and data forms ready.
• A way to see crashes after release.

Try it yourself

Run eas build:configure on a project, then create a preview build for Android and install it on a phone. Raise the build number in your app config, make a visible change, and publish it with eas update. See the change arrive on the phone without a new install.

Summary

• EAS Build makes your app files in the cloud using profiles in eas.json: development, preview for testers, and production for the stores.
• Keep version (what people see), build number or version code (rising with every upload) and the permanent bundle ID or package straight. Never put secrets in EXPO_PUBLIC_ variables.
• Submit with eas submit after setting up store accounts, then use EAS Update for fixes to JavaScript, styling and images, while native changes need a new build.