If you've been shipping React Native apps the hard way, Expo's EAS (Expo Application Services) might be the workflow upgrade you've been waiting for. A new breakdown from Codonomics walks through how to configure eas.json with three build profiles—Development, Preview, and Production—and maps them to a realistic feature lifecycle that takes you from local debugging straight to Google Play Store submission.
Understanding Build Configurations
The core of EAS power lives in your eas.json file. This config defines different Build Profiles that handle specific stages of your app's journey. Development builds include expo-dev-client, support hot updates, and output debug APKs. Preview builds are release-like but distributed internally via URL—skipping the Play Store entirely for faster stakeholder access. Production builds? Optimized, minified, signed with production certificates, and packaged as Android App Bundles (AAB) ready for Google Play submission.
Development: Where the Real Work Happens
Phase 1 focuses on local implementation and debugging. Before triggering any build, run your tests with npm test. Once you're confident, generate a development client APK using eas build --profile development --platform android, then install it on a physical device. Fire up Expo CLI with npx expo start --dev-client—just make sure your phone is on the same Wi-Fi as your machine or connected via USB with port forwarding enabled.
Preview: QA's Time to Shine
Phase 2 handles quality assurance and stakeholder sign-off. The preview profile typically points to a "staging" API environment, letting you test against production-like infrastructure without touching real data. Run E2E tests using Detox across various device configurations—screen sizes, OS versions—with commands like detox build -c android.emu.release followed by detox test. The article notes that Maestro could replace this step entirely if you're looking to simplify your testing stack.
Production: The Real Deal
Phase 3 is where features get certified for end users. Generate the production AAB with optimized builds and your production certificates using eas build --profile production --platform android. Then automate Play Store submission with eas submit --platform android—no manual uploads to Google Play Console required.
Key Takeaways
- EAS Build Profiles in eas.json handle Development, Preview, and Production stages separately
- Development uses expo-dev-client for hot reload; Preview distributes via URL; Production outputs store-ready AABs
- Detox or Maestro can automate E2E testing across device configurations before release
- EAS Submit automates Play Store uploads—set it and forget it
The Bottom Line
Three profiles, three phases, one smooth pipeline. If you're still manually managing builds across environments or uploading APKs by hand, you're leaving time on the table. EAS won't fix bad architecture, but it will make your shipping process feel like actual engineering instead of DevOps theater.