Skip to main content

CI/CD and Release Engineering

React Native release engineering is a cross-functional system, not a final step in the sprint. The pipeline has to coordinate JavaScript validation, native builds, code signing, environment management, store submission, staged rollout, observability, and rollback. If any one of those areas depends on tribal knowledge, the team does not yet have a production-grade mobile delivery system.

Delivery model​

A stable release system usually separates work into these layers:

  • Source validation: linting, type checking, unit tests, dependency checks, and static analysis.
  • Integration validation: component tests, end-to-end tests, API contract checks, and key device-matrix verification.
  • Artifact generation: Android and iOS build creation with deterministic versions and environment inputs.
  • Distribution: internal QA builds, beta channels, release candidates, and production distribution.
  • Operational control: staged rollout, monitoring, kill switches, rollback, and hotfix handling.

Teams should define the owner and input for each layer. If the same engineer is manually bridging all of them during release week, the system is too fragile.

Branch and environment strategy​

Avoid improvising branch rules every release. A practical model is:

  • main: always releasable, protected, and validated by CI.
  • Short-lived feature branches: merged through pull requests.
  • Optional release branches: only when the team truly needs a stabilization lane or store submission buffering.
  • Hotfix branches: created from the last production commit or release tag, with strict scope control.

Environment separation should also be explicit:

  • Local development: permissive logging, mock services where needed, and faster feedback loops.
  • QA/internal: real backend integration with safe test data.
  • Staging/pre-production: store-like behavior, production-like services, and stricter gating.
  • Production: minimum debugging surface, full signing, and release observability enabled.

Do not let environment identity depend on ad hoc .env files copied between machines. CI should be the canonical source of build-time configuration.

Pipeline stages​

1. Fast verification on every pull request​

Every pull request should at minimum run:

  • dependency installation
  • type checking
  • linting
  • unit tests
  • targeted component tests
  • lockfile and generated-file consistency checks

For larger teams, this is the point to add:

  • code ownership checks
  • bundle size or startup baseline regression checks
  • native build smoke validation
  • schema generation validation for APIs or GraphQL

This stage is meant to fail quickly and cheaply.

2. Artifact validation on protected branches​

Once changes land on the protected release branch, the pipeline should create real mobile artifacts and validate:

  • Android assemble/bundle success
  • iOS archive/build success
  • version code and version name generation
  • environment injection correctness
  • signing configuration correctness
  • sourcemap upload success
  • release notes generation or changelog packaging

If the app uses Hermes, confirm that symbolication, bundle mapping, and crash reporting all align with the generated artifact versions.

3. Distribution automation​

After artifacts are produced, teams typically automate:

  • internal distribution to QA
  • TestFlight or internal Android distribution
  • release candidate promotion
  • store metadata packaging
  • app submission or draft creation

For many teams, human approval still belongs between artifact generation and public rollout. Automating the build is not the same as automating the decision to release.

Native build concerns​

React Native teams often underestimate how much reliability depends on native build hygiene. Document and automate:

  • Android SDK, JDK, Gradle, and NDK expectations
  • iOS Xcode version policy
  • Ruby, CocoaPods, and Bundler usage if applicable
  • dependency caching strategy
  • local reproduction commands for CI failures

Two rules matter here:

  • Keep the CI toolchain versioned and pinned.
  • Make the failing step reproducible by any engineer without needing a release manager on a call.

Signing, credentials, and secrets​

Signing is where otherwise mature teams still get exposed. The safe model is:

  • iOS signing certificates and provisioning are centrally managed.
  • Android signing keys are backed up and access-controlled.
  • CI receives credentials through secret storage, not committed files.
  • Secret rotation procedures are written down and tested.
  • No release credential exists only on one laptop.

Also separate:

  • build secrets
  • runtime public config
  • server-owned secrets

If a value must stay private, it should not be recoverable from the mobile bundle at all.

Versioning and release identity​

Every production artifact should answer:

  • Which git commit produced this build?
  • Which environment was used?
  • Which JS bundle or OTA update is paired with it?
  • Which release notes apply?
  • Which crash reports correspond to this version?

A practical release identity model includes:

  • semantic or marketing app version
  • monotonic build number/version code
  • release tag in Git
  • uploaded sourcemaps/symbols bound to that release identifier

OTA and binary releases​

If the team uses over-the-air updates, define strict boundaries:

  • Safe for OTA: copy updates, styling adjustments, feature flag wiring, low-risk JS-only logic changes.
  • Unsafe for OTA: anything that depends on new native code, permissions, SDK configuration, entitlement changes, or platform policy changes.

OTA should be governed by:

  • runtime version compatibility
  • staged rollout or channel targeting
  • emergency disable path
  • monitoring immediately after publish

Treat OTA as another controlled release lane, not as a shortcut around QA.

Release quality gates​

A serious release pipeline usually blocks production rollout unless:

  • the build was created from a protected branch or tag
  • required reviewers approved the release
  • tests passed at the required level
  • crash-free and startup baselines from prior releases are acceptable
  • release notes exist
  • rollout owner and rollback owner are identified
  • observability dashboards are ready for the target version

For regulated or enterprise apps, add:

  • security review signoff
  • privacy-impact signoff when data handling changed
  • compliance confirmation for third-party SDK changes

Staged rollout strategy​

Do not ship directly to 100% unless the product profile truly allows it. A better pattern is:

  • Internal users
  • Small production percentage
  • Broader rollout after health checks
  • Full rollout after stability confirmation

The health check window should look at:

  • crash-free sessions
  • startup latency
  • API error rates
  • authentication failures
  • payment or conversion failures
  • device or OS-specific regressions

Rollout decisions should be based on explicit thresholds, not intuition.

Hotfix process​

The hotfix system should be more disciplined than the normal flow, not less. Document:

  • who can declare a hotfix
  • how scope is constrained
  • what tests are mandatory even under pressure
  • how release notes are updated
  • how the fix is merged back to the main development line

The most common failure here is shipping a hotfix that fixes production but leaves the main branch divergent.

The exact stack depends on workflow choice, but common combinations include:

  • Expo + EAS Build/Submit + GitHub Actions
  • Bare React Native + Fastlane + GitHub Actions
  • Internal build farm + store APIs + artifact repository

Choose one primary release path. A mixed environment where some releases use one pipeline and others use another creates operational drift quickly.

Release checklist​

  • Branch protection is active.
  • CI validates code quality and tests.
  • Native artifacts are reproducible in CI.
  • Signing material is centrally managed.
  • Store submission steps are automated or scripted.
  • OTA rules are documented.
  • Rollout stages and rollback rules are defined.
  • Release dashboards map to app version and build number.
  • Hotfix workflow is rehearsed.

Team rule​

Release engineering should feel boring on a healthy team. If each production release feels unique, stressful, or hero-driven, the system still needs design work.

Pair this page with Deployment and Release, Mobile Security, and Production Playbooks.