EAS Build
Compiling your React Native project into a real Android APK or iOS IPA using EAS cloud infrastructure — no local build tools required.
When you're ready to move beyond Expo Go — to test native features, share the app with beta testers, or prepare for store submission — you need a real compiled binary. EAS Build handles this in the cloud, which means you don't need Android Studio, Xcode, or any local build tools installed on your machine.
The process: you run one command, EAS uploads your code to its cloud servers, compiles it there, and gives you a download link for the finished APK or IPA.
The "Why First" Scenario
You've completed the EduTrack partner app's KYC document upload flow. It works in Expo Go — the camera opens, the photo is taken, the image appears in the form.
But when you try to trigger a push notification from the admin panel to alert the partner that their KYC was approved — nothing happens. The notification fires in the Supabase dashboard but the partner's phone never receives it.
Push notifications in their full form — using Apple's APNs and Google's FCM directly — don't work in Expo Go. You need a real build to test them.
EAS Build creates that real build. Once the partner installs your APK, push notifications work exactly as they will in production.
Build Profiles
Before running your first build, you need to understand build profiles. EAS uses profiles to define what kind of build to create. Your project's eas.json file (created when you run eas build:configure) defines these profiles.
| Profile | Who installs it | What it produces | Use case |
|---|---|---|---|
development | Only you, on your device | A custom version of Expo Go with your native modules | Testing native features you've added |
preview | Your team and beta testers | A standalone app, not in the store | Internal testing before store submission |
production | Anyone who downloads from the store | A store-ready binary (AAB for Android, IPA for iOS) | App Store / Play Store submission |
For this workshop, you'll use preview for testing and production for store submission.
Configuring EAS in Your Project
Navigate to your project root in the terminal
Run the EAS build configuration command
EAS CLI asks a few questions:
"Which platforms would you like to configure?" Select All — this sets up both Android and iOS configuration even if you're only building Android right now.
"Do you want to use the recommended EAS project configuration?"
Select Yes. This creates a sensible default eas.json.
Look at the generated eas.json
After configuration, you'll see a new file in your project root:
The preview profile with "distribution": "internal" means: build the app for internal distribution (download directly, not through the store). This is what you want for testing.
Your First Android Build
Run the Android preview build
Handle the Android keystore prompt
EAS CLI will ask:
Press Y (Yes).
What is a keystore? An Android keystore is a file containing a cryptographic signing key. Every Android app must be signed with a key — it's how Google verifies the app came from you and not someone else. EAS stores this keystore securely on its servers so you never lose it.
This keystore is permanent for your app. Once you publish an app to the Play Store with a specific keystore, all future updates must use the same keystore. If you lose it, you cannot update the app — you'd have to publish it as a brand new app with a new listing. EAS manages this automatically and backs it up for you.
Never manually delete your keystore from the EAS credentials system. If you're in a test project that you'll never publish, this doesn't matter. For EduTrack, keep the keystore managed by EAS.
The build starts
After the keystore is configured, EAS uploads your project code to its cloud servers. You'll see output like:
The cursor spins while your build is in the queue and being processed.
Monitor the build
Open the link EAS printed in your browser. The Expo dashboard shows real-time build logs. You can see each step:
Total time: 5–15 minutes on the free plan (varies based on queue wait time and project size).
Download the APK
When the build finishes, the Expo dashboard shows a "Download" button and a QR code. You can also download from the link EAS printed in your terminal.
The downloaded file is [project-name].apk — typically 30–80 MB for a typical React Native app.
Installing the APK on an Android Phone
An APK downloaded directly is called a "sideloaded" app — installed outside the Play Store. Android has a security setting to prevent this by default. You need to allow it once.
Send the APK to your Android phone
Options:
- Email it to yourself and open on your phone
- Upload to Google Drive and open on your phone
- Connect your phone via USB and copy the file
- Scan the QR code from the Expo build dashboard directly on your phone
When you try to open the APK, Android shows a warning
The message varies by Android version:
- Older: "For your security, your phone is set to block installation of apps from unknown sources"
- Newer: "Your phone is not allowed to install unknown apps from [browser/files app]"
Allow installation from this source
Tap "Settings" in the warning dialog. Enable "Allow from this source" for the app you're installing through (Chrome, Files, Gmail, etc.).
Install the APK
Go back and tap "Install". Android installs the app — it takes 10–30 seconds.
Find the app on your phone
Your app appears in the app drawer like any other app — with its icon and name from app.json. Open it and test.
The sideloading setting only needs to be enabled once per source app. If you install via Gmail, you enable it for Gmail — future APKs received via Gmail install without the warning. This is safe for internal testing — only install APKs from people you trust.
Your First iOS Build
iOS builds require an Apple Developer account ($99/year). Without one, you cannot install the build on a real iPhone or submit to the App Store.
If you have an Apple Developer account:
Run the iOS preview build
Answer the Apple credential prompts
EAS CLI guides you through connecting your Apple Developer account. It will ask for your Apple ID and team ID. EAS then automatically:
- Creates an App ID in your Apple Developer account
- Creates a distribution certificate (the iOS equivalent of an Android keystore)
- Creates a provisioning profile that allows the app to run on your registered test devices
This is the part where iOS is more complex than Android — Apple has multiple layers of credentials that EAS manages for you automatically.
The build runs on EAS cloud macOS servers
EAS Build's iOS builds run on Mac servers in the cloud — you don't need a Mac on your desk. The compilation uses Xcode running on EAS's infrastructure.
Download the IPA when done
The IPA file is the iOS equivalent of the APK. You cannot install it directly on an iPhone like an APK on Android — Apple requires going through TestFlight.
Understanding Android APK vs AAB
You'll hear both terms. They serve different purposes:
| Format | Full name | Used for | Size |
|---|---|---|---|
| APK | Android Package | Direct installation on devices | Larger — includes all device configurations |
| AAB | Android App Bundle | Play Store submission only | Smaller — Google splits it by device |
The preview profile produces an APK (for direct install). The production profile produces an AAB (for the Play Store). The EAS CLI handles which to produce based on the profile — you don't choose this manually.
Production Build (For Store Submission)
When you're ready to submit to the Play Store:
This produces an AAB file suitable for Play Store submission. The process is identical to the preview build — just a different profile flag.
For iOS App Store:
This produces an IPA configured for App Store submission.
Checking Build Status and History
This shows your recent builds with their status, platform, profile, and download links. Useful when you've triggered a build and want to check if it's finished without opening a browser.
What You Have Now
A real Android APK installed on your test device — not running in Expo Go, but as a genuine standalone app. You can verify features that don't work in Expo Go, test the real user experience, and share it with Subhash or beta testers for review.
The next step is understanding how to submit this build to the app stores when you're ready to go live.