Releasing to App Store & Google Play

01Versioning: version name vs build number

Every build has two numbers. The user-facing version (iOS CFBundleShortVersionString, Android versionName) follows semantic versioning: 2.4.0 for a feature release, 2.4.1 for a fix. The build number (iOS CFBundleVersion, Android versionCode) is for the stores and must always increase: Google Play rejects a versionCode it has seen, and App Store Connect needs a unique build number per version. Keep one source of truth and let CI bump the build number, for example from the pipeline run number. Tag the git commit with the version so you can always rebuild what is in the store. Also remember OTA updates (if you use them) must be tied to a runtime version so a JavaScript update never lands on a binary with different native code.

1// android/app/build.gradle
2android {
3  defaultConfig {
4    versionCode 2041      // integer, must always increase
5    versionName "2.4.1"   // shown to users
6    targetSdk 36          // Play: API 36 for new apps and updates from Aug 31, 2026
7  }
8}
9// iOS (Xcode build settings):
10// MARKETING_VERSION = 2.4.1       -> CFBundleShortVersionString
11// CURRENT_PROJECT_VERSION = 2041  -> CFBundleVersion

02Signing: iOS certificates and profiles, Android keystores

Signing proves a build comes from you and was not modified. On iOS you need an Apple Developer Program membership, an App ID (bundle identifier), a distribution certificate (private key in your keychain or CI) and a provisioning profile that ties the certificate, App ID and capabilities (push, Sign in with Apple, associated domains) together. Xcode's automatic signing works for small teams; CI usually uses fastlane match or EAS credentials to share them securely. On Android you sign with an upload key from a keystore file; with Play App Signing (required for new apps, which ship as AAB bundles), Google holds the real app signing key and re-signs. If you lose the upload key you can request a reset; without Play App Signing, a lost key meant you could never update the app. Never commit keystores or passwords to git; store them in a secrets manager or CI secrets.

1# Create an Android upload key (keep the file and passwords in a secret store)
2keytool -genkeypair -v -keystore upload-key.jks -alias upload \
3  -keyalg RSA -keysize 2048 -validity 10000
4 
5# Build a signed Android App Bundle
6cd android && ./gradlew bundleRelease
7 
8# iOS: archive and upload with fastlane (certificates via match)
9bundle exec fastlane ios beta

03Testing tracks: TestFlight and Play testing

Never send a build to production that real people have not installed from the store's own pipeline. On iOS, upload to App Store Connect and use TestFlight: internal testers (members of your team) get builds almost immediately; external testers (up to 10,000, by email or public link) require a short beta review for the first build of a version. Builds expire after 90 days. On Android, the Play Console has internal testing (fast, up to 100 testers), closed testing (lists or groups) and open testing. Note: new personal developer accounts must run a closed test with at least 12 testers opted in for 14 continuous days before they can apply for production access; organization accounts are exempt. Test the release build, not just debug: minification, signing, push and deep links often behave differently.

• Test upgrade from the previous store version, not only fresh installs
• Check push, deep links, payments and sign-in on the release build
• Keep a review/demo account ready with sample data

04Store listings and privacy information

The listing sells the app and also states facts the stores check. You need a name, subtitle/short description, description, keywords (iOS), screenshots for required device sizes, an icon, category, age rating questionnaire, support URL and a privacy policy URL. Both stores require privacy disclosures: Apple's App Privacy 'nutrition labels' and Google Play's Data safety form must match what the app and its SDKs (analytics, crash reporting, payments) really collect. On iOS, apps and third-party SDKs must include privacy manifests declaring data use and 'required reason' APIs. If the app tracks users across other companies' apps or sites, you must use App Tracking Transparency. Localize listings for each market you target. Prepare screenshots from a real build with realistic, non-personal demo data.

05Review rules and common rejections

Apple reviews every version against the App Review Guidelines; Google combines automated checks with policy review. Most rejections are predictable. Crashes or broken flows during review. Missing demo account or a login wall reviewers cannot pass. Account creation without in-app account deletion (Apple requires it). Third-party social login without an equivalent privacy-focused option such as Sign in with Apple. Selling digital goods or subscriptions outside in-app purchase where it is required (physical goods and real-world services, like food orders, use normal payment providers). Permission prompts without clear purpose strings. Placeholder content, broken links, or an app that is just a website wrapper. Privacy labels that do not match the SDKs. Reply calmly in Resolution Center with specifics; many rejections are resolved by an explanation or a short video.

• Provide a working demo account and notes for the reviewer
• Offer in-app account deletion when users can create accounts
• Write specific permission purpose strings (camera, location, photos)
• Keep store builds on current SDKs: Apple and Google raise minimums yearly

06Staged rollouts, hotfixes and OTA updates

Do not release to 100% at once. On iOS, Phased Release spreads automatic updates over seven days (1%, 2%, 5%, 10%, 20%, 50%, 100%) and can be paused; users can still update manually. On Google Play, a staged rollout lets you pick a percentage and increase it, or halt it if Crashlytics shows a spike. Watch crash-free users, key funnels and support messages before each step. For emergencies, have a hotfix branch and expedited review requests (use sparingly), plus your Remote Config kill-switches. OTA updates (EAS Update, or self-hosted equivalents; Microsoft's CodePush service was retired with App Center in 2025) replace the JavaScript bundle and assets without store review. They are excellent for small fixes, but they cannot change native code, must match the binary's runtime version, and must not change the app's primary purpose — store rules still apply. Roll OTA updates out gradually too.

07A CI pipeline that builds, signs and uploads

Manual releases fail in boring ways: the wrong scheme, an expired certificate on one laptop, a forgotten build number. Move the whole path into CI. For iOS, fastlane match keeps certificates and profiles encrypted in a private storage repository, and CI pulls them read-only; an App Store Connect API key replaces personal Apple ID logins and two-factor prompts. For Android, CI decodes the upload keystore from a secret, builds the AAB and uploads it to the internal track. Build numbers come from the pipeline run number, the commit is tagged, and the job stores build artifacts and symbol files. Humans keep the decisions that need judgment — promoting to production and increasing rollout percentages — while machines do every repeatable step.

1# fastlane/Fastfile
2platform :ios do
3  lane :beta do
4    setup_ci
5    app_store_connect_api_key(key_id: ENV["ASC_KEY_ID"], issuer_id: ENV["ASC_ISSUER_ID"],
6                              key_content: ENV["ASC_KEY_P8"])
7    match(type: "appstore", readonly: true)
8    increment_build_number(build_number: ENV["CI_RUN_NUMBER"])
9    build_app(scheme: "MyApp", export_method: "app-store")
10    upload_to_testflight(skip_waiting_for_build_processing: true)
11  end
12end
13 
14platform :android do
15  lane :internal do
16    gradle(task: "bundle", build_type: "Release", project_dir: "android")
17    upload_to_play_store(track: "internal", aab: lane_context[SharedValues::GRADLE_AAB_OUTPUT_PATH])
18  end
19end

08Platform requirements move every year

Both stores raise their minimums on a yearly rhythm, and a release can be blocked by a rule that has nothing to do with your feature. Apple: since 28 April 2026 App Store Connect accepts only builds made with Xcode 26 and the iOS 26 SDK or later; privacy manifests and declared reasons for sensitive APIs are checked at upload. Google: new apps and updates must target API 36 from 31 August 2026, and apps targeting Android 15 or higher must support 16 KB memory page sizes, which means native libraries — including those inside React Native dependencies — must be built for it. Plan a fixed upgrade window each year (Xcode, Android Gradle Plugin, React Native, SDKs) instead of discovering the rule during an urgent hotfix, and subscribe to Apple's and Google's developer news.

09What the stores do with your binary

On Android you upload an App Bundle, not an APK. Google Play splits it into APKs per device configuration — CPU architecture, screen density, language — and signs them with the app signing key, so users download only what their device needs. bundletool lets you reproduce those APKs locally to test exactly what a device would install. On iOS, App Store Connect processes the upload, and App Thinning produces device-specific variants; the App Store Connect size report shows the real download and install sizes per device. Size matters for conversion, especially on mobile data: watch native libraries, bundled fonts and images, and unused locales. Both stores also run automated checks on upload — private API use, missing purpose strings, privacy manifest issues, target SDK — and those messages arrive by email, so someone must read them.

1# Reproduce what Play would install on the connected device
2bundletool build-apks --bundle=app-release.aab --output=app.apks --connected-device
3bundletool install-apks --apks=app.apks
4 
5# Check which certificate signed an APK
6apksigner verify --print-certs app.apk
7 
8# Fingerprints of your upload key (needed for API consoles and resets)
9keytool -list -v -keystore upload-key.jks -alias upload

10OTA updates: runtime versions, channels and rollback

An OTA update is only safe if it lands on a binary with exactly the native code it expects. EAS Update tracks that with a runtime version. The appVersion policy ties it to the app version, which is simple but breaks if someone changes native code without bumping the version; the fingerprint policy hashes the native project so any native change produces a new runtime automatically, at the cost of more frequent store builds. Builds listen on a channel (production, staging) mapped to a branch of updates, so you can test an update on staging builds before pointing production at it. Roll out gradually with a percentage, watch crash-free users, and keep a rollback path: republish the previous update or roll back to the update embedded in the binary. Sign updates (code signing) so a compromised server cannot push arbitrary code.

1# app.json (expo): runtime changes whenever native code changes
2# "runtimeVersion": { "policy": "fingerprint" }
3 
4# Publish to 10% of production users first
5eas update --branch production --message "Fix checkout crash" --rollout-percentage 10
6 
7# Increase, finish or revert the rollout
8eas update:edit
9eas update:revert-update-rollout
10 
11# Emergency: send clients back to the code embedded in the binary
12eas update:roll-back-to-embedded