Softech Blog
← Back to blog
Mobile Product Engineering

Expo & EAS Production Workflow: Build, TestFlight, Google Play, Submit and Updates

How to structure a repeatable React Native release workflow with Expo/EAS: development builds, preview, store testing, submission, updates, monitoring and recovery.

2 min read
Expo & EAS Production Workflow: Build, TestFlight, Google Play, Submit and Updates
Executive summary

The most important points from this article

How to structure a repeatable React Native release workflow with Expo/EAS: development builds, preview, store testing, submission, updates, monitoring and recovery. The core principle is to treat the mobile application as one interface of a larger product system, with backend state, device behavior, release engineering and operations designed explicitly.

Key takeaways
  • Version build configuration with the project.
  • Separate development, preview and production profiles.
  • Automate submission without confusing it with store approval.
  • Define runtime compatibility and rollback before OTA updates.
Key insights

Key observations and insights

The key observations summarizing the experience, decisions and outcomes described in the article.

“The mobile app is only one interface of the product.”
“Product state should remain explicit across device, API and backend.”
“Release engineering is part of mobile product architecture, not a final checklist.”

Production mobile delivery is a pipeline

A release is not “run the build and upload it”. A production workflow connects environment configuration, signing, internal distribution, QA, store testing, submission, rollout, telemetry and incident response.

Development builds

Teams need an installable application that contains the native modules used by the project and can connect to development environments. For React Native products using Expo tooling, development builds provide that project-specific runtime rather than depending only on a generic sandbox.

Preview and internal distribution

Before a store build, stakeholders should be able to install a version that is close to production. Preview builds reduce the gap between local development and device QA and make it easier to test permissions, deep links, notifications and native integrations.

Build profiles are product environments

Keep development, preview/staging and production configuration explicit. API endpoints, feature flags, bundle identifiers, credentials and analytics destinations should not depend on a developer remembering manual steps.

EAS Build

Expo Application Services can run cloud builds for Android and iOS, manage build profiles and support credential workflows. The key engineering value is repeatability: the build recipe is versioned with the project rather than living only on one laptop.

EAS Submit and store testing

EAS Submit can upload binaries to Google Play Console or App Store Connect/TestFlight. Submission automation does not bypass review. Store metadata, privacy declarations, screenshots, account access and policy requirements still belong to release readiness.

EAS Update: define a compatibility policy

Update tooling can deliver compatible JavaScript and asset changes between binary releases. Do not treat this as permission to bypass stores or ship arbitrary native changes. Define runtime compatibility, rollout channels and rollback rules before relying on over-the-air updates operationally.

DEVELOPMENT
  ↓
PREVIEW / INTERNAL
  ↓
STORE TESTING
  ↓
SUBMITTED
  ↓
REVIEW
  ↓
ROLLOUT
  ↓
PRODUCTION OBSERVATION

What to monitor after release

  • crashes and fatal errors,
  • startup and key journey performance,
  • API errors and failed business actions,
  • notification/deep-link behavior,
  • version adoption,
  • support incidents correlated with release version.

Release engineering is ownership

The right question is not “do you use EAS?”. It is whether the team can reproduce, test, submit, observe and recover a mobile release without relying on undocumented personal knowledge.

Solution framework

Key elements and relationships

Mobile Product System

Five layers connecting the device experience to authoritative product state and production operations.

Layer 1
Experience

Mobile interaction, navigation and native capabilities.

Layer 2
Client state

Local state, cache, queue and network-aware behavior.

Layer 3
Product API

Typed contracts, authorization and idempotent operations.

Layer 4
Business state

Authoritative workflow, payments, records and lifecycle rules.

Layer 5
Production

Build, release, telemetry, support and recovery.

Evidence and context

Information supporting the analysis

EAS Build is Expo’s hosted service for building Android and iOS application binaries from configured build profiles.

Expo Docs — EAS Build · 2026

EAS Submit can upload Android and iOS builds to Google Play Console and App Store Connect/TestFlight.

Expo Docs — EAS Submit · 2026

EAS Update delivers compatible application updates for JavaScript, styles and assets without replacing native binary changes.

Expo Docs — EAS Update · 2026

FAQ

What is EAS Build used for?
EAS Build creates configured Android and iOS binaries in a hosted build environment, supporting repeatable build profiles and credential workflows.
Does EAS Submit bypass App Store or Google Play review?
No. It automates binary upload to the store consoles; application review and policy requirements still apply.
Can EAS Update change native code?
No. Compatible updates are intended for JavaScript and asset changes. Native dependency changes require a new binary release.
Continue reading

Related articles

Articles that expand the topic and add further practical context.

How to Build a Production Mobile App in 2026: Architecture, React Native and Release Engineering

A production mobile app architecture guide covering React Native, backend state, offline workflows, notifications, native capabilities, store delivery and operations.

React Native vs Native iOS & Android: A Product Architecture Decision Guide

A decision framework for choosing React Native, Swift/Kotlin or a mixed architecture based on shared product logic, native constraints, performance and long-term ownership.

Offline-first Mobile App Architecture: Sync, Idempotency and Conflict Handling

A practical architecture for mobile products that must survive poor connectivity: local persistence, operation queues, idempotency, sync, conflict policy and support observability.

Author

Matt Dudzicz · Softech.app

Founder

Founder of Softech.app, focused on product engineering, mobile and web systems, digital infrastructure and AI-native business software.

LinkedIn
Next step
Planning a new mobile product or extending an existing platform?
We map the operating model, backend state, offline requirements, native capabilities and release workflow before turning the brief into a screen backlog.
Book mobile product discoveryExplore Mobile Product Engineering
Design the system→