Release Day in App Development: What It Is, Stages, and Preparation
Release day is the scheduled date for launching a new version of a mobile app, including build preparation, store review, staged rollout, and monitoring. For iOS apps, the process starts with uploading the build to App Store Connect 24–48 hours before the planned release date due to mandatory Apple review. For Android, the build is assembled and uploaded to Google Play Console, where the review process usually takes 1–4 hours. According to Apple Developer Guidelines (2025), 90% of builds pass review within 24 hours. Staged rollout helps minimize impact if errors are discovered after publication.
Key Takeaways
- Release day — a set of activities from build preparation to post-rollout monitoring
- Staged rollout — gradual rollout: 1%, 10%, 50%, 100%
- Smoke testing — final build check before submitting to the store
- Rollback plan — a pre-prepared rollback scenario for critical errors
- Release retrospective — process analysis after 100% rollout completion
What Is Release Day and How to Prepare for It
Release day is not just the moment you hit the Publish button. It’s a coordinated process involving developers, QA, DevOps, product managers, and sometimes support. Preparation begins 2–3 weeks before release day: agreeing on scope, code freeze, regression testing, preparing release notes and marketing materials. The more thorough the preparation, the smoother the release day goes.
The release day preparation checklist includes: final QA run (regression + smoke suite) on the release build; checking store metadata (name, description, screenshots, keywords); agreeing on staged rollout percentage with the product manager; preparing a rollback plan (which tag to redeploy, how long it will take); notifying the team and related services about the upcoming release. Release checklist should be automated via CI/CD — for example, as a GitHub Actions workflow that checks all items before creating the release tag.
An important element of preparation is the blackout period (a period when production deployments are prohibited). Typically, blackout is introduced 48 hours before release day and lifted 24 hours after successful 100% rollout. Change freeze during the blackout period applies to all services related to the release.
Build Preparation: Code Freeze, Tagging, and Assembly
24–48 hours before release day, a code freeze is introduced — a complete halt to code changes. Developers switch to preparing documentation and release notes. DevOps assembles the release build from a fixed tag (e.g., v2.6.0-rc1). The build goes through a full regression suite (automated + manual tests). If critical bugs are found, they are fixed before the code freeze or the release is postponed. Release candidate (RC) — a build that has passed QA and is ready for store submission.
Git tagging: an annotated tag is created (git tag -a v2.6.0 -m “Release v2.6.0”). The CI/CD pipeline builds an AAB (Android App Bundle) for Google Play and IPA (iOS App Store Package) for the Apple App Store. The build is accompanied by: a checksum file (SHA256), a changelog, and a list of known issues. Reproducible builds — an ideal practice where rebuilding from the same tag produces a binary-identical result.
bash
# Release pipeline — tag creation and build
# Assumes code freeze is already active
# Create release branch from develop
git checkout develop
git pull origin develop
git checkout -b release/v2.6.0
git push origin release/v2.6.0
# Code freeze: branch protection rules block new PRs
# Run regression suite in CI/CD
./gradlew clean testReleaseUnitTest connectedReleaseTest
# Create release tag after successful QA
git tag -a v2.6.0 -m "Release v2.6.0: payment module, dark mode"
git push origin v2.6.0
# Build release binary via CI/CD
# fastlane build_release produces AAB + universal APK
fastlane build_releaseImportant: version bump (updating version code and version name) is done before the code freeze. After the code freeze, the version does not change. For Android: versionCode — a monotonically increasing integer; versionName — semantic version (2.6.0). For iOS: CFBundleVersion (build number) and CFBundleShortVersionString (semantic version). Versioning should be automated in gradle/xcconfig.
Submitting to the Store and Going Through Review
For iOS: the build is uploaded via Xcode, Transporter, or fastlane to App Store Connect. After upload, the build undergoes an automatic Apple check (processing), then is sent for manual review. Average review time is 24 hours, but can vary from 1 hour to 7 days depending on Apple reviewer workload and compliance requirements. Expedited review — a request for accelerated review for critical bug fixes (available no more than once a month, not guaranteed).
For Android: the build is uploaded via Google Play Console. Google uses a combined approach: automated testing (accessibility, malware, policy compliance) + selective manual review. Average review time is 1–4 hours. Internal test track and Closed track allow final testing before publication to the Production track. Recommended: 1–2 days on Internal test → 1 day on Closed beta → gradual Production rollout.
For both platforms, it is critically important to check metadata before uploading the build: app name, description (short + full), screenshots for each supported device (iPhone 6.5″, 5.5″, iPad, Android phone, tablet), keywords (iOS) or store listing experiments (Android). A metadata error can delay the review by an additional day. App metadata should be localized for all supported languages.
Staged Rollout: How to Roll Out a Release Without Risk
Staged rollout (gradual rollout, staged deployment) is a strategy where a new version becomes available to users gradually, not all at once. A typical scheme for a mature team: 1% of users (first 2–4 hours) → 10% (24 hours) → 25% (24 hours) → 50% (24 hours) → 100%. Each stage includes metric monitoring and checking for critical errors. Staged rollout is the primary tool for minimizing risk during releases.
Google Play Console provides built-in staged rollout: you can specify a user percentage and schedule gradual increases. For iOS App Store Connect, there is no such built-in feature — staged rollout is implemented through Phased Release (automatic coverage increase over 7 days with the ability to pause) or through server-side feature flags with geo-distribution. Phased release in App Store Connect allows you to Pause Release if problems are detected.
Key metrics for moving to the next stage: crash-free rate (≥99.9% for the new release), ANR rate (Android, ≤0.1%), error rate on backend API (≤0.5% 5xx), user ratings (not lower than the previous version), apdex score (≥0.94). If any metric exceeds the threshold, rollout is paused until the cause is determined. Go/no-go gate at each stage is the responsibility of the release manager or on-call engineer.
Post-Release Monitoring: What to Watch in the First Few Hours
The first 4 hours after release are the most critical time. The team monitors crash rate (Sentry, Firebase Crashlytics, App Center), 5xx error rate on the backend, custom events (successful payments, logins, registrations), user ratings in the App Store and Google Play, and social media mentions (Twitter, Reddit). The monitoring dashboard should be prepared in advance and available on a big screen in the office or in a dedicated Slack channel. Release dashboard — a single pane of glass for all release metrics.
Special attention goes to regression metrics: comparing crash rate with the previous version over a similar period. If crash rate has increased by more than 0.1%, this is a red flag requiring immediate analysis. It is also important to compare median and p95 latency of key API endpoints: even without crashes, a 200ms increase in response time may signal a problem. Metric comparison (baseline vs current) is automated in Datadog or Grafana.
User feedback is just as important as numerical metrics. In the first hours after a release, users actively leave reviews in the stores and write to support. Bugs not caught by tests quickly surface in reviews. The team lead or a designated QA engineer monitors reviews every 30 minutes in the first 4 hours and classifies them: false positive, known issue (already in the known issues list), new bug. New bugs P0/P1 — a trigger for pausing the rollout.
Rollback: When and How to Revert a Release
Rollback is reverting to a previous stable version when critical problems are discovered. The decision to roll back is made by the release manager together with the tech lead if: the crash-free rate of the new release falls below 99%, a data leak is detected, critical functionality (payments, authorization) does not work for more than 5% of users, or the store (App Store Review) rejected the build after publication. Rollback trigger must be defined before the release so that the decision is based on facts, not emotions.
For Android: rollback in Google Play Console means stopping the staged rollout and switching to the previous version. If the current build is already at 100% of users, publish the previous version as a new release. For iOS: via App Store Connect — Phased Release → Pause Release → release a new version with a fix (App Store does not allow reverting to a previous version). iOS rollback is more complex: the developer needs to assemble a new build with revert commits and go through review again.
After a rollback, the team switches to incident mode: root cause analysis, hotfix or next release with a fix, post-mortem. Rollback is not a failure but a standard procedure. Teams that have never done a rollback are likely not noticing problems rather than releasing bug-free builds. Rollback rate is one of the DORA metrics: high-performing teams roll back fewer than 10% of releases and recover in less than 1 hour.
Frequently Asked Questions
What is the best day to release a mobile app?
The best days are Tuesday, Wednesday, or Thursday. Monday has high traffic from the weekend, and Friday carries the risk of heading into the weekend with a problematic release. Avoid Friday: if a problem is discovered after deployment, the team will be fixing it over the weekend or waiting until Monday.
What if the App Store Review rejects the build?
Read the rejection reason in the Resolution Center, fix it, and re-upload the build. Common reasons: broken links, incomplete fields, content without a subscription (if required), outdated screenshots. App Review rejection delays the release by 24–48 hours, so the first build upload should be 3–5 days before the planned release date.
What percentage of staged rollout is optimal to start with?
For major releases (major changes) — 1%. For patch releases — 5–10%. The first stage should be small enough that in case of an error the impact is minimal, but large enough to obtain statistically significant metrics. 1% for an app with 10 million users means 100,000 people — sufficient for detecting critical problems.
Should we have a release party?
A release party (team celebration) is optional but beneficial for morale. It’s better to hold it after a successful 100% rollout rather than at the moment of build upload. Release celebration can be combined with a release retrospective to discuss what went well and what can be improved.
Who is responsible for the “release or postpone” decision?
The responsibility lies with the release manager (usually a senior engineer or tech lead). The decision is made based on data from the release dashboard, not based on the deadline. Release manager has the authority to delay the release if metrics do not pass the go/no-go gate.
Summary
- Release day — a coordinated process from code freeze to post-rollout monitoring
- Preparation — release candidate, QA run, metadata check, rollback plan
- Staged rollout — 1% → 10% → 25% → 50% → 100% with go/no-go gate at each stage
- Monitoring — crash-free rate, ANR, 5xx error rate, user ratings in the first 4 hours
- Rollback — standard procedure when crash-free rate drops below 99%
- Communication — notify the team and stakeholders before and after the release
- Release retrospective — process review after 100% rollout completion
We will develop a mobile application turnkey
IT Sectr creates iOS and Android applications for startups and businesses since 2017. We will advise you and propose the best solution.
Read also