App Store Releases & Code Signing: iOS and Android

App Store Releases and Signing

Shipping a web app means deploying to servers you control. Shipping a mobile app means handing a signed binary to Apple or Google, passing review, and waiting for users to update — some of whom never will. Every release goes through code signing, store metadata, privacy disclosures, testing tracks, and rollout controls that have no web equivalent, and a mistake in any of them can block a launch or, worse, ship a broken build to millions of devices with no rollback button.

Teams that release smoothly treat the mobile release process as engineering: signing credentials stored and backed up like production secrets, builds produced by CI rather than a developer's laptop, testers receiving every release candidate, phased rollouts watched against crash and error dashboards, and server APIs that keep working for old app versions.

TL;DR

iOS: apps are signed with certificates and provisioning profiles tied to bundle IDs and entitlements; distribute betas with TestFlight.
Android: you sign uploads with an upload key; Play App Signing holds the app signing key and signs what users install, from Android App Bundles.
Increment build numbers (CFBundleVersion, versionCode) for every upload; keep user-facing versions meaningful.
Use testing tracks (TestFlight internal and external; Play internal, closed, and open) before production.
Release gradually: phased release on iOS, staged rollouts on Play — and halt on regressions.
Automate with fastlane or store APIs, and design for no rollback: feature flags, minimum-version checks, and backward-compatible APIs.

Quick Example

A Fastfile with beta and production lanes for both platforms:

Signing Android release builds from CI secrets instead of a committed keystore (Gradle Kotlin DSL):

Core Concepts

iOS Code Signing

Xcode's automatic signing works for individuals; teams usually centralize signing — with fastlane match (encrypted certificates and profiles in a private repository or storage) or Xcode Cloud — so CI and every developer use the same identities. Certificates expire and can be revoked, so track expiry dates.

Android Signing

Google Play requires new apps to publish as Android App Bundles (AAB) with Play App Signing. You sign uploads with your upload key; Google re-signs the optimized APKs it generates with the app signing key it protects. If the upload key is lost or compromised, it can be reset through Play Console support — a lost app signing key, in the days before Play App Signing, meant you could never update the app again. Store keystores and passwords in a secrets manager with backups, never in the repository.

Versions and Build Numbers

Derive build numbers from CI, so every artifact is traceable to a commit. See Release Engineering and Artifact Support Windows.

Testing Tracks and Review

Review checks builds against store policies: App Review Guidelines on iOS, Developer Program Policies on Play. Common rejection causes include crashes, incomplete features, misleading metadata, missing account deletion for apps with account creation, payments outside the store's billing system where not allowed, and inaccurate privacy disclosures.

Privacy and Platform Requirements

App Store privacy details ("nutrition labels") and privacy manifests for apps and SDKs that use certain APIs or track users.
Google Play Data safety section describing collection, sharing, and security practices.
Target API level requirements on Play: new apps and updates must target a recent Android version, rising every year.
Permissions justified in usage descriptions (iOS Info.plist strings) and Play declarations for sensitive permissions.

Keep disclosures in sync with the SDKs you ship; third-party analytics and ads SDKs often collect more than teams realize.

Rollouts and the No-Rollback Problem

Phased release on the App Store delivers an update to automatic-update users over seven days (1%, 2%, 5%, 10%, 20%, 50%, then 100%) and can be paused. Staged rollouts on Play release to a chosen percentage and can be increased or halted. Watch crash-free sessions, ANRs, error rates, and key business metrics at each step.

Neither store can revert users who already installed a bad version. The fix is a new build through review, which takes hours to days. Plan for that:

Feature flags to disable broken features remotely. See Feature Flags.
Minimum supported version checks that ask or force users to update when a version is unsafe.
Backward-compatible APIs: servers must support every app version still in use, often for months.
Expedited review requests (Apple) for critical fixes — use sparingly.

Automation

Build and upload from CI, not from laptops: fastlane, Xcode Cloud, Gradle Play Publisher, or direct use of the App Store Connect API and Google Play Developer API. Store API keys and signing credentials as CI secrets with least privilege, generate release notes from the changelog, and record which commit each build came from. See CI/CD and React Native Deployment.

Best Practices

Treat Signing Credentials as Production Secrets

Store them in a secrets manager, back them up, limit access, and document how to rotate them.

Release Every Build to Testers First

Send every release candidate through internal tracks so the exact binary that goes to production has been used by people.

Always Roll Out Gradually

Use phased releases and staged rollouts with defined metrics and owners who decide whether to continue or halt.

Support Old Versions Deliberately

Track version adoption, keep APIs compatible, and set a minimum supported version policy.

Common Mistakes

Signing on One Developer's Laptop

Breaking Old App Versions With a Server Change

Releasing to 100% at Once

FAQ

What is a provisioning profile?

An Apple file that authorizes an app, identified by its bundle ID, to run with a specific signing certificate and set of entitlements — and, for development builds, on specific devices.

What is Play App Signing?

A Google Play service in which Google manages your app signing key and signs the APKs delivered to users, while you sign uploads with a separate upload key that can be reset if lost.

Can I roll back a mobile app release?

Not for users who already installed it. You can pause or halt rollouts and ship a fixed version, so plan for feature flags, minimum-version checks, and backward-compatible APIs.

How long does app review take?

It varies; many reviews complete within a day or two, but complex apps, policy questions, and rejections take longer. Build review time into release schedules.

What is the difference between TestFlight internal and external testing?

Internal testers are members of your App Store Connect team and get builds without review. External testers can be anyone you invite, and the first build of a version requires Beta App Review.