How Spotify Manages Weekly Mobile App Releases: Balancing Speed and Quality

Large‑scale development and weekly releases of Spotify’s iOS and Android mobile apps reach over 675 million users, making release management critical for a smooth listening experience.

At Spotify, the release team has two core responsibilities: minimizing the time from code merge to user availability and ensuring the quality meets their standards . Balancing these goals requires careful prioritization, rollback planning, and rapid action on critical bugs.

Key practices include:

Prioritizing bugs : Not all bugs are equal; crashes during registration or playback are addressed immediately, while less‑critical crashes are deferred.

Identifying fallback options : If a bug affects a specific A/B test group, the backend can temporarily route all users to a stable experience while the client fix is prepared.

Acting quickly when needed : Even minor bugs that impact a small but important user segment may require swift resolution.

Release Cycle Overview

To illustrate Spotify’s release cycle, we follow version 8.9.2 from creation to launch.

Friday, Sep 20 – New version created

The cycle starts on a Friday morning when the previous version is cut off. Spotify practices trunk‑based development, merging code to the main branch after testing and review. Major changes, such as large‑scale or infrastructure updates, are merged early in the cycle (typically the first Friday) to allow extensive testing with internal and external alpha users.

For version 8.9.2, a new audiobooks feature was enabled behind a backend feature flag and underwent internal testing to catch any blocking bugs before the public rollout.

Sep 20 – Sep 26 – First week of the cycle

Each morning, the nightly build from the main branch is sent to internal and alpha users.

Developers merge new code that has passed tests and reviews.

Internal and external alpha users submit bug reports; the release manager assigns each bug to the appropriate team.

Crash rates and other metrics are tracked automatically and manually. When a metric exceeds predefined severity thresholds, a bug ticket is created automatically; otherwise, tickets are created manually as needed.

The release manager dashboard aggregates all relevant release data in one place, showing blocked bugs, latest build status, crash/ANR rates, daily usage, and distribution job status for internal and external builds.

During this week, the audiobooks team monitors all crashes to ensure no issue could jeopardize the upcoming feature launch.

Friday, Sep 27 – Branch day

After one week, the 8.9.2 version is branched, marking it as the *current* release where only critical bug fixes are allowed. Non‑critical bugs and new features are deferred to subsequent releases.

A public beta build is generated from the release branch, offering greater stability than the alpha builds. Teams perform manual regression testing on the beta or rely on automated tests if confidence is high.

Any bugs discovered during testing generate tickets, and crash reports from internal and external users may also trigger new bug tickets.

Sep 27 – Sep 30 – Preparing for submission

During the weekend, the beta build receives additional runtime to increase confidence. The goal is to submit the app to the stores on Monday, though complex bugs may delay this.

Updates, questions, and potential issues are shared in a dedicated Slack channel. The release manager ensures bugs are assigned, prioritized, and that release‑blocking bugs (typically three to five per cycle) are fixed on the release branch.

Before submission, the following criteria must be met:

All commits on the release branch are included in the latest build and have passed automated tests.

No open blocking bug tickets remain.

All teams have signed off.

Crash rates and key metrics are below defined thresholds.

The version has been used to play a sufficient amount of content.

Oct 1 – Oct 2 – Rollout

Once approved by the platform, the rollout occurs in two phases: a small percentage of users first, then 100 % the following day.

During the initial 1 % rollout, the dashboard highlights any remaining yellow indicators, such as open ITGC tickets. Minor bugs are acceptable in the current version but are treated as blockers for future releases. In severe cases, the rollout may be paused until fixes are ready.

The robust system enables Spotify to continuously update its apps, quickly address issues, and introduce new features like audiobooks while minimizing user‑experience disruption.

Summary

Spotify’s weekly mobile app release process strives to balance speed and quality.

The release manager coordinates communication and decisions throughout the cycle, supported by tools such as the release dashboard.

Detailed documentation of tools and processes guides all involved teams, allowing Spotify to deliver frequent updates, resolve problems rapidly, and roll out new functionality with minimal impact on users.