In the Expo ecosystem, EAS (Expo Application Services) has simplified how we handle native builds. Central to this power is the `eas.json` file, which allows you to define different Build Profiles. This guide breaks down the 3 standard configurations -- Development, Preview, and Production -- and maps them to a realistic feature lifecycle.
1. Understanding the Build Configurations
Before diving into the lifecycle, let's define what these profiles actually do:
- Development Configuration
- Primary Purpose: Active coding & debugging
- Key Characteristics: Includes `expo-dev-client`; allows hot updates; debuggable.
- Output Format: `.apk` (Debug)
- Preview Configuration
- Primary Purpose: QA and optionally product/business stakeholders
- Key Characteristics: Identical to production but uses internal distribution; often bypasses stores.
- Output Format: `.apk` (Release-like)
- Production Configuration
- Primary Purpose: Staged End-user release (You can have a pre-release stage for product/business stakeholder sign-off here and QA validate if build meets latest PlayStore compliance and standards that Google brings up from time to time)
- Key Characteristics: Optimized; minified; signed with production keys; ready for Store.
- Output Format: `.aab` (Android App Bundle)
2. The Feature Lifecycle Flow
The diagram below illustrates how a code-feature moves through these configurations:
2.1 Phase 1: Implementation & Development
In this phase, you are building the feature locally. You need a Development Build to support any custom native modules you've added.
- Local Testing (Unit & Integration): Before even triggering a build, run your tests.
```
npm test
``` - Creating the Development Build: To run the app on a physical Android device with support for your custom native code:
```
# Build the development client for Android
eas build --profile development --platform android
```
Once the build is finished, install the .apk on your physical device. - Running the App: Start the Expo CLI development server.
```
npx expo start --dev-client
```
Note: Ensure your physical device is on the same Wi-Fi as your machine or connected via USB with port forwarding.
2.2 Phase 2: QA & Device Configuration Testing
Once the feature is "dev-complete," you move to the Preview phase. This creates a release-build version of your app that can be shared with testers via a URL without going through the Play Store.
- Building for Preview: This profile typically points to a "staging" API environment.
```
eas build --profile preview --platform android
``` - Automated E2E Testing (using Detox): To ensure the feature works across various device configurations (Screen sizes, OS versions), we use End-to-End (E2E) testing.
```
# Example: Running Detox E2E tests against the preview build
detox build -c android.emu.release
detox test -c android.emu.release
```
ProTip: If you were to use Maestro, this step becomes redundant. - Selective Manual Testing: Distribute the Preview URL to your QA team. They can install the app on various physical devices (Samsung Galaxy, Pixel, etc.) to check for UI regressions specific to Android manufacturer skins.
2.3 Phase 3: Production Release
Upon a QA certifying a build as good, we generate the Android App Bundle (.aab) for the Google Play Store.
- The Production Build: This build is highly optimized and uses your production certificates.
```
eas build --profile production --platform android
``` - Submission to Play Store: You can automate the upload to the Google Play Console (Internal Track or Production) using EAS Submit.
```
# Submit the last successful build to the Play Store
eas submit --platform android
```
3. Example eas.json Configuration
--
--