React Native CI/CD Guide: Automate Expo and Native App Builds for Android and iOS

Overview

A reliable React Native CI/CD workflow should answer five questions for every change: can the app be built, does it pass automated checks, can the correct people review it, can it be signed safely, and can the release be monitored or reversed if necessary?

For Expo-based projects, EAS can provide hosted builds, submission workflows, and update-related tooling. A native pipeline built with a provider such as GitHub Actions, a cloud CI service, Fastlane, or a combination of these gives the team more control over runners, scripts, caching, and credentials. Neither approach is automatically better. The useful decision depends on the project’s native code, compliance requirements, team skills, build frequency, and tolerance for infrastructure maintenance.

Estimate the workflow using two separate measures:

• Operational effort: the engineering time needed to configure, maintain, debug, and review the pipeline.
• Pipeline consumption: the number and duration of builds, tests, artifacts, and release jobs the team expects to run.

Keeping these measures separate prevents a common mistake: selecting a tool based only on its visible build cost while ignoring the time spent repairing brittle scripts or manually preparing releases.

For wider release-readiness work, pair this process with a React Native performance optimization checklist. Performance regressions that are discovered after store submission are more expensive to correct than regressions caught in a preview build.

How to estimate

Start with a simple monthly model. The model does not need to predict every minute precisely; it needs to expose the assumptions behind your choice.

Monthly pipeline load = build jobs + test jobs + release jobs + reruns

For each job type, record:

• How often it runs, such as on every pull request, on merges to the main branch, or only for a release candidate.
• Its typical duration, including dependency installation, native compilation, tests, artifact creation, and upload time.
• The proportion of jobs that are repeated because of flaky tests, expired credentials, transient infrastructure failures, or incorrect configuration.
• Whether the job creates a reusable artifact, such as an Android package, an iOS archive, a debug build, or a preview build.

A practical estimate is:

Expected job minutes = job count × average duration × (1 + rerun rate)

Use separate rows for Android and iOS because their signing, simulator, device, and native build requirements are different. Also separate pull-request validation from release builds. A lightweight JavaScript and TypeScript check may run for every change, while a signed store artifact should run only after stronger gates have passed.

Then estimate maintenance effort:

Monthly workflow effort = scheduled maintenance + failure investigation + release administration

Scheduled maintenance includes dependency updates, runner images, native SDK changes, action updates, and credential rotation. Failure investigation includes time spent distinguishing application failures from CI configuration failures. Release administration includes approving builds, checking metadata, promoting staged releases, and documenting rollback steps.

For a small project, the most economical workflow may be the one that removes manual steps even if it offers less infrastructure control. For a larger team, reproducibility, auditability, isolated secrets, and custom native scripts may justify a more involved native pipeline.

Inputs and assumptions

Write down the following inputs before comparing EAS with a native CI pipeline. If an input is unknown, mark it as an assumption instead of silently treating it as zero.

Project shape

• Is the app using managed Expo configuration, a prebuild workflow, or a fully native React Native setup?
• Does the project require custom native modules, modified Gradle files, CocoaPods changes, or platform-specific build scripts?
• Are Android and iOS built from the same commit and configuration, or do they follow different release schedules?

Validation requirements

• Which checks must pass before merging: formatting, linting, TypeScript, unit tests, integration tests, or end-to-end tests?
• Which checks need a simulator, emulator, physical device, or platform-specific runner?
• How long can a pull-request job run before developers begin bypassing it?

Security and release controls

• Where are Android keystores, iOS certificates, provisioning profiles, app-store tokens, and service-account credentials stored?
• Which secrets are available to pull requests from forks, and which are restricted to protected branches or environments?
• Who can approve production submission, and how is the exact source commit recorded?

Never place signing credentials in the repository or expose production secrets to untrusted pull-request code. Use the CI platform’s encrypted secret store or a dedicated credential system, keep production credentials separate from preview credentials, and limit release jobs to protected branches. A successful build is not proof that the release process is secure.

Choose a test strategy that fits the risk of the app. Unit and component tests are usually useful as fast merge gates. End-to-end tests should focus on critical paths such as authentication, payments, offline recovery, navigation, and push-notification handling. For tool selection and trade-offs, see Detox vs. Maestro vs. Appium for React Native E2E testing.

Worked examples

Example 1: Expo application with frequent preview builds

Assume a team has one shared Expo application. Every pull request receives a JavaScript validation job, selected changes receive a preview build, and the release branch produces signed Android and iOS artifacts. The team values a short setup period and does not need extensive customization of the native runners.

The estimate should count:

• Pull-request checks per week multiplied by their average duration.
• Preview builds per week, including both successful builds and expected reruns.
• One Android and one iOS release build for each release candidate.
• Time spent maintaining build profiles, environment variables, credentials, and submission permissions.

In this case, EAS may reduce operational effort because hosted build and submission workflows can keep much of the native setup outside the project repository. The team should still version its build profiles, document environment variables, test preview artifacts on real devices, and verify that a release build can be reproduced from a known commit.

Example 2: React Native app with custom native integration

Now assume the app includes custom Android and iOS modules, separate internal and production environments, device-level tests, and a release process that requires additional native scripts. The team also needs to retain control over runner configuration and artifact retention.

Here, the estimate should add the time required to maintain Gradle and CocoaPods dependencies, configure platform-specific runners, cache safely, manage certificates, and debug failures that occur only on one operating system. A native CI pipeline may be a better fit because its flexibility offsets the extra maintenance. EAS can still be part of the workflow if its hosted builds meet the project’s native requirements, but that should be confirmed with a representative build rather than assumed.

For both examples, create three artifacts: a preview build for review, a release-candidate build for final testing, and a production build tied to an approved commit. Do not use a successful preview build as a substitute for validating production configuration, signing, permissions, and store metadata.

When to recalculate

Recalculate the workflow whenever an input changes materially. Common triggers include a major increase in pull requests, longer native build times, a new native module, a change from manual to automated store submission, a new app environment, or a requirement to retain artifacts and logs for longer.

Also revisit the estimate after repeated failures. Track whether each failure came from application code, test flakiness, dependency installation, signing, runner capacity, or release configuration. A pipeline with a low nominal job count can still be expensive if developers regularly rerun it or wait for manual intervention.

At the end of each release cycle, review four indicators:

1. Median time from merge to a reviewable build.
2. Percentage of jobs requiring a rerun.
3. Time needed to produce a signed Android or iOS release artifact.
4. Time needed to recover from a failed release or restore the previous version.

Use those observations to simplify gates, improve caching, isolate flaky tests, or change platforms. Keep rollback practical: retain the previous known-good artifact, record its commit and configuration, and document who can halt or reverse a rollout. For release-specific implementation patterns, continue with the React Native CI/CD guide covering GitHub Actions, EAS Build, Fastlane, and store releases.

The best React Native CI/CD workflow is not the one with the most automation. It is the one whose checks are trusted, whose secrets are controlled, whose build assumptions are visible, and whose recovery path has been tested before an incident occurs.