{"id":"l-rn-5-3","courseId":"react-native-apps","lang":"en","kind":"lesson","summary":"Configure Trailhead’s identity and versions, create development, preview and production builds with EAS Build, send them to TestFlight and Google Play with EAS Submit, and prepare for app review.","html":"

So far Trailhead has run through Expo Go and development builds, with your laptop serving the JavaScript. Real users need something else: an app that installs from a store, starts without a dev server, and is signed so their phone trusts it. EAS Build makes those builds in the cloud, so you don’t need a Mac for iOS, and EAS Submit uploads them to the stores.

\n

Identity and versions in app.json

\n

Before the first build, settle a few fields:

\n
app.json
{\n  \"expo\": {\n    \"name\": \"Trailhead\",\n    \"slug\": \"trailhead\",\n    \"version\": \"1.0.0\",\n    \"scheme\": \"trailhead\",\n    \"icon\": \"./assets/images/icon.png\",\n    \"ios\": { \"bundleIdentifier\": \"com.example.trailhead\" },\n    \"android\": { \"package\": \"com.example.trailhead\" }\n  }\n}
\n

The bundle identifier (iOS) and package name (Android) are your app’s permanent identity in the stores. Change them after publishing and the store sees a different app: no updates for existing users, no reviews carried over. Use a reverse domain you control.

\n

There are two kinds of version. version is what users see (“1.0.0”); you raise it for each public release. Each upload also needs a unique, increasing internal number (the iOS build number and Android version code). Let EAS manage those for you, as shown below.

\n

Build profiles

\n

Install the CLI, sign in to your Expo account and generate the config:

\n
Terminal
npm install -g eas-cli\neas login\neas build:configure
\n

That creates eas.json with three profiles:

\n
eas.json
{\n  \"cli\": { \"appVersionSource\": \"remote\" },\n  \"build\": {\n    \"development\": { \"developmentClient\": true, \"distribution\": \"internal\" },\n    \"preview\": { \"distribution\": \"internal\" },\n    \"production\": { \"autoIncrement\": true }\n  },\n  \"submit\": { \"production\": {} }\n}
\n\n

Then build:

\n
Terminal
eas build --platform android --profile preview\neas build --platform all --profile production
\n

The build runs on EAS servers; the CLI prints a link to the logs and, at the end, to the build itself.

\n
\n Source code goes through eas build to a signed binary. Preview builds go to testers by link. Production builds go through eas submit to TestFlight or a Google Play testing track, then app review, then release.\n \n code\n \n \n eas build\n \n \n preview → testers\n \n \n eas submit\n \n \n TestFlight\n / track\n \n \n review\n → live\n
From source to the stores
\n

Credentials

\n

Every installable build is signed. iOS needs a distribution certificate and provisioning profile; Android needs an upload keystore. EAS can generate these, store them, and reuse them for every build; the CLI asks the first time. For iOS you need a paid Apple Developer Program membership; for Google Play, a one-time developer registration fee. Treat the Android keystore with care: EAS keeps it for you, but if you manage your own and lose it, updating the app gets painful.

\n

Submitting to the stores

\n

First create the app’s record in App Store Connect and in Google Play Console. Then upload the latest production build:

\n
Terminal
eas submit --platform ios\neas submit --platform android
\n

On iOS the build goes to App Store Connect, where it becomes available in TestFlight for testers after processing. On Android it lands on a testing track (internal by default); EAS needs a Google service account key to upload for you. You can combine both steps with eas build --auto-submit.

\n\n

Getting through review

\n

Both stores review apps, Apple more strictly. You’ll fill in a store listing (name, description, screenshots for required device sizes), a privacy policy URL, and privacy details: Apple’s App Privacy section and Google Play’s Data safety form, which must match what Trailhead actually collects, such as location and photos.

\n\n

Reviews usually take from a few hours to a couple of days. Once approved, you choose when to release. Then the cycle repeats for every native change: new version, build, submit, review. For JavaScript-only fixes there’s a faster path, which is the final lesson.

\n","toc":[{"id":"sec-1","text":"Identity and versions in app.json","level":2},{"id":"sec-2","text":"Build profiles","level":2},{"id":"sec-3","text":"Credentials","level":2},{"id":"sec-4","text":"Submitting to the stores","level":2},{"id":"sec-5","text":"Getting through review","level":2}],"takeaways":["A release build compiles the native app, bundles and minifies your JavaScript, and signs it with credentials the stores trust.","The iOS bundle identifier and Android package name are permanent once you publish; choose them deliberately.","eas.json profiles describe builds: development for your dev client, preview for testers, production for the stores.","eas submit uploads a production build to App Store Connect or Google Play; testers get it through TestFlight or a testing track before review.","Most first rejections come from crashes, vague permission text, missing privacy details or no demo account for a sign-in-only app."],"further":[{"title":"EAS Build","url":"https://docs.expo.dev/build/introduction/"},{"title":"Configure EAS Build with eas.json","url":"https://docs.expo.dev/build/eas-json/"},{"title":"EAS Submit","url":"https://docs.expo.dev/submit/introduction/"},{"title":"App Store Review Guidelines","url":"https://developer.apple.com/app-store/review/guidelines/"}],"quiz":[{"q":"

After Trailhead is on the App Store, a teammate wants to change the iOS bundle identifier to match a new company name. What happens if you do?

","options":[{"text":"The store treats it as a brand-new app, so existing users don’t get the update and your reviews and ratings stay with the old listing.","why":"Correct. The bundle identifier (and Android package name) is the app’s permanent identity in the stores."},{"text":"The App Store renames the listing automatically after review.","why":"Display names can change; identifiers can’t. A new identifier means a new app."},{"text":"Nothing, as long as the version number goes up.","why":"Versions order releases of the same app. A different identifier isn’t the same app."}],"answer":0},{"q":"

You want five hikers in your club to try Trailhead before it goes to the stores, installing it from a link. Which build fits?

","options":[{"text":"A development build, since it has the dev menu for feedback.","why":"Development builds need your Metro server running to load JavaScript, so testers can’t use them on their own."},{"text":"A production build installed from the App Store.","why":"Production builds go through store review and public release; that’s the step after testing."},{"text":"Expo Go with your project’s QR code.","why":"Expo Go can’t include Trailhead’s native configuration, like its URL scheme and permission strings, and testers would need your dev server."},{"text":"A preview build with internal distribution, shared through the link EAS gives you.","why":"Correct. Internal distribution is designed for this; on iOS, testers’ devices must first be registered for ad hoc builds."}],"answer":3},{"q":"

What does autoIncrement in the production profile take care of?

","options":[{"text":"It raises the user-facing version, like 1.2.0 to 1.3.0, on every build.","why":"The user-facing version is yours to choose; autoIncrement handles the internal build number."},{"text":"It bumps the iOS build number and Android version code for each build, which the stores require to be unique.","why":"Correct. Each upload needs a higher build number even when the visible version stays the same."},{"text":"It increments the Expo SDK version on each build.","why":"SDK upgrades are deliberate changes to your dependencies, never automatic."}],"answer":1}],"exercise":{"kind":"order","items":["set-identity","configure","preview","production-build","submit","store-test","review","release"],"title":"Put Trailhead's first release in order","prompt":"

Trailhead 1.0.0 is feature-complete and tested. Arrange the steps of its first release to the App Store and Google Play in the order you’d do them.

\n","hints":["You can’t build anything until the app knows its permanent identity and EAS knows which profiles exist.","Testers see a preview build before anything goes to the stores.","Store review happens after the production build has been uploaded and checked on real phones."],"explanation":"

Identity comes first because it’s permanent, then eas build:configure creates the profiles every later command uses. A preview build lets real hikers find problems before the stores are involved. The production build is uploaded with eas submit, checked once more as a real release build through TestFlight or the internal track, and only then sent for review with the listing, privacy details and demo account in place. Release is the last, deliberate step: approval doesn’t have to mean shipping that minute.

\n","checkLabels":{},"itemText":{"set-identity":"Set ios.bundleIdentifier, android.package and version in app.json","configure":"Run eas build:configure to create eas.json with build profiles","preview":"Make a preview build and share it with a few hikers through internal distribution","production-build":"Run eas build --platform all --profile production","submit":"Run eas submit to upload the builds to App Store Connect and Google Play","store-test":"Install the TestFlight and internal-track builds on real phones and walk through the main flows","review":"Complete the store listing, privacy details and demo account, then submit for review","release":"Release the approved version to users"}},"words":661,"readMinutes":3}