CI/CD for Mobile, Without the Release-Day Panic

Mobile release automation is less mature than its backend equivalent, and most teams underinvest until a manual release goes wrong at a bad moment. The fix is not elaborate; it is mostly about removing the steps a human can get wrong.

Signing is the part that bites

Certificates, provisioning profiles and keystores are the most common cause of "it builds on my machine". They expire, they differ per environment, and they are easy to misplace.

Keep signing material out of the repository and in a secret store your CI can read. Automate renewal reminders — an expired certificate discovered during a hotfix is an expensive afternoon.

The failure mode worth guarding hardest against is losing an Android upload key, which is not recoverable in the ordinary way. Back it up somewhere your team will still have access to in three years.

Build numbers should be automatic

Both stores reject duplicate build numbers, and the manual increment is the step people forget under pressure. Derive it from the CI run number or the commit count. Never type it.

Keep the user-facing version separate and deliberate — that one is a product decision.

The pipeline worth having

On every pull request: lint, type-check, unit tests, and a build that proves the app compiles for both platforms. That last one catches a surprising amount.

On merge to the release branch: build signed artefacts, upload to the internal test track, notify the team. A tester should be able to install the latest build without anyone doing anything by hand.

On tag: promote to the store's review queue with release notes drawn from the changelog.

Test on real devices, selectively

Simulators miss camera behaviour, push delivery, performance under thermal load and the quirks of specific Android manufacturers. A small matrix of real devices — your oldest supported phone, a current flagship, one problematic manufacturer — catches most of what matters.

Run the full matrix nightly rather than per-commit. It is slow and the signal rarely changes within a day.

Staged rollout, always

Release to a small percentage first and watch crash-free rate and reviews before widening. A bad build caught at 5% is an inconvenience; the same build at 100% is a week of recovery.

Crash reporting with source maps or symbols uploaded automatically as part of the build is what makes this actionable — a stack trace you cannot read tells you something broke and nothing about what.

Know how to roll back

You largely cannot, on mobile. Once a version is out and installed, it is out. Your rollback is halting the rollout and shipping a fix forward through review.

That asymmetry is the argument for staged rollout, for feature flags that let you disable a feature server-side without a release, and for taking the review queue seriously as a dependency with variable latency.