How much time do mobile engineers really lose per release?

Most mobile engineering teams have invested seriously in automation. CI/CD is running, Fastlane scripts are doing their thing, and someone probably spent a weekend wiring up a Slack bot to post build status. But mobile teams are still frustrated by the manual tasks that drain their productivity and turn release week into a drag. 

According to Runway's 2025 State of Mobile Release Management Report, the average engineer spends 5 hours per release on manual, repetitive tasks. On teams that have invested heavily in automation, it's often worse: 51% still report losing 6 to 10 hours per release, a pattern the report calls the "automation paradox." On a weekly cadence, that's a consistent, substantial drain on engineering capacity, not counting hotfixes, incidents, and the productivity loss that comes with context switching.

Why doesn’t automation solve mobile release pain? 

Understandably, when teams recognize the time losses and productivity gaps, they turn to automation to ease their pain. In fact, our survey data shows 75% of teams regularly invest in automation and scripting for their release process. Unfortunately, more tooling rarely fixes the core issues. These same teams still report losing 6 to 10 hours per release. 

The root of the issue is that many teams consider CI/CD to be the end-all-be-all of release automation. In reality, CI/CD ends when the build finishes, but the release process itself starts well before that. Branch management, feature freezes, and version coordination happen before the build. Store submissions, rollout coordination, stakeholder sign-offs, crash monitoring, and release notes happen after. Most of that work is still largely manual for most teams. 

CI/CD and Fastlane scripts are built to handle the build. They were never designed to manage the coordination layer that follows it: cross-team sign-offs, stakeholder visibility, rollout decisions, incident response. 

The bottleneck shifts, but it doesn't disappear. Teams move from "builds are slow" to "releases are still chaotic" and assume they're one more script away from solving it. In most cases, they're solving a build problem when the real problem is downstream.

Runway's data reflects this directly: mobile teams are stuck spending roughly a third of every release cycle on busywork, even on mature, automated teams. That's not a process debt problem, it’s a tooling issue caused by the absence of a system that can manage the entire release cycle, not just the build.

Point solutions that handle individual steps (a Fastlane lane here, a CI step there) add complexity without addressing the coordination challenge underneath. Teams end up bridging those gaps manually between fragmented toolchains, operating under what we call the illusion of a false safety net: the automation is running, but the release is still being held together by whoever happens to know the most.

Where the hours actually go: A breakdown of the release time sink

Time loss in a mobile release comes from a dozen smaller leaks, distributed across every stage of the cycle. Automation handles the core steps of the release process well, but the bridge work between them (which is where the most collaboration and communication happens) is where time slips away. 

Pre-release coordination and branch management

Cutting the release branch, bumping build numbers, cherry-picking fixes, coordinating a feature freeze, and drafting the initial changelog all require manual judgment calls with no dedicated tooling to coordinate them. The work lives in Slack threads and one engineer's head, and when that person is out, the process stalls.

Build monitoring and handoff

Context switching is the second most cited release frustration in our 2025 survey, at 42%, and monitoring and handoff points are rife with it. Even with CI/CD in place, someone has to watch the pipeline to confirm builds are healthy, check logs, and route artifacts. The work demands enough sustained attention to block focus but not enough to count as productive time, pulling engineers into a half-working state for the duration of the build window. 

App store submissions

Submitting to App Store Connect and Google Play Console means managing metadata, screenshots, version codes, and release notes across both platforms, manually, every release. The same actions repeat each cycle with just enough variation to resist full automation, and errors in metadata or screenshots trigger rejection and restart the review clock.

QA coordination and beta distribution

Cross-functional coordination is the third most cited frustration from our 2025 data, at 41%, and QA coordination and beta distribution are clear contributors. Why? Distributing builds via TestFlight or Firebase App Distribution, promoting across tracks, and chasing sign-off across Slack threads is a coordination problem with no dedicated home. There is no single source of truth for release status, so progress has to be assembled manually across tools, people, and threads. 

Hotfix overhead

77% of teams need hotfixes every 3 to 5 releases. At that frequency, hotfixes are close to the baseline for most teams. Each one means cherry-picking the fix to the release branch, bumping the build number, re-running the full submission pipeline, and waiting on App Review again: a compressed version of the entire release process, under pressure, often with fewer people available.

Stakeholder communication and status updates

There’s an invisible time tax you pay each time you answer "what's the status?" from product, QA, and leadership that doesn't show up on a release checklist, but it accumulates steadily across every release day. Stakeholder coordination ranks among the top three frustrations in our survey, and most teams are still managing it with project management and communication tools that weren't built for release workflows.

Our research found that better communication, process, and collaboration across releases could have prevented 63.1% of uncaught incidents in respondents' previous releases.

How to calculate your team's actual release time cost

Most teams underestimate this number because they only count the release engineer's time. The full cost of an inefficient release process includes the impact of on cadence, hotfixes, and the productivity drag on everyone pulled into the process. Here's how to run it.

Step 1: Baseline hours

Track how many hours whoever is running your releases (dedicated release engineer, developer on rotation, platform team etc.) spends per cycle on release-specific work: branch prep, build monitoring, store submissions, QA coordination, rollout management, stakeholder updates. If you don't have your own data, use 5 hours per release as an industry baseline. For teams with more complex release processes, 6-10 hours per release is closer to the norm per Runway's 2025 report (we’ll say 7 hours for the sake of this calculation).

Step 2: Frequency multiplier

Weekly cadence: ~50 releases/year. Biweekly: ~26. Multiply baseline hours by annual release count to get raw annual hours. (weekly, 7 hrs across 50 weekly releases: 350 hrs/year)

Step 3: Context switching tax

Add 30 to 50% to account for the productivity drag on everyone else pulled into release work: PMs chasing status, QA coordinating sign-off, engineers context-switching mid-sprint. This isn't a soft number; interrupted deep work typically costs 23.25 minutes of recovery time per interruption. (350 hrs × 1.38 = 483 hrs)

Step 4: Hotfix load

77% of teams need hotfixes every 3 to 5 releases. Use one hotfix per four releases as a baseline. At 50 releases/year, that's roughly 13 hotfixes. Each runs 3 to 5 hours of compressed release work. (13 × 4 hrs = 52 hrs, running total: ~535 hrs)

Step 5: Dollar cost

Multiply total hours by your fully-loaded engineering hourly rate. A senior mobile engineer in the US fully loaded typically runs $175 to $225/hr. At $185/hr, 540 hours is roughly $98,975 per year in engineering time spent on release operations.

That's one engineer, on a typical team, on a weekly cadence. For context, Runway's report puts the baseline loss for biweekly teams at 130 hours per year just wasted on manual work alone, the equivalent of 3 full work weeks. Add on a faster cadence, rotation schedules that cause people to forget process and have to relearn what’s changed for each release, and the hourly rate of senior engineers who are often required to come help fix issues and this total gets unwieldy quickly across the full scale of your releases. 

The compounding cost: It's not just the hours

The raw hour count understates the real impact. Hours are the floor. What compounds on top of them is harder to measure and more damaging over time.

As we showed above, context switching is not free. Jumping between release tasks and active sprint work generates errors on top of consuming time, and errors create additional work. Six hours of release-related interruption can easily become twelve once you factor in the mistakes that happen when attention is divided. Review cycles get slower. Bugs that would have been caught get missed. The rework cost accumulates quietly.

Release duty becomes something engineers dread. On teams where release rotation is shared, the best engineers learn to time their vacation requests around release weeks. That pattern is a signal worth paying attention to, not just as a morale issue but as a recruiting and retention one. A release process that engineers actively avoid is a competitive disadvantage in hiring. 

Tribal knowledge hardens. When only one or two engineers fully understand how a release works end to end, every departure or extended leave is a risk event. The knowledge lives in someone's head instead of in a system, and that debt compounds every time a new team member joins and has to be trained informally. 

The organizational consequences go further. Slow, unpredictable releases erode leadership confidence in the mobile team. Product managers can't run experiments at the cadence they need. Features ship in batches rather than continuously, which constrains the team's ability to learn and iterate. At enterprise scale, this shows up in the numbers: for companies with 5,000 or more employees, inefficient release processes rank as the No. 1 risk factor at 34%, ahead of budget constraints and resource limitations. The release process stops being infrastructure and starts being a ceiling on what the team can accomplish.

What to do about it

As we discussed, the most common response to release overhead is more automation: another lane in the Fastfile, another CI step, another custom tool, another attempt at vibe coding away the problem. That approach keeps working up to a point, and then the automation paradox sets in. The more automation layers you add, the more coordination is required to connect them, and the more expertise is required to maintain them. At some points, the overhead of managing your automation outweighs the time saved by automating. 

The fix is, in the words of Zachary Radford (Sr. iOS Engineer at Faire), “treating your releases as you would any other product” from the first branch cut through to rollout monitoring. That means managing pre-build coordination, handling the build handoff, automating store submissions, and maintaining visibility through phased rollout, in a single connected flow rather than a series of manual handoffs. Optimizing the mobile release process walks through what that looks like in practice.

For teams evaluating ways to streamline their mobile releases, a few questions are worth asking before committing: 

• Can your existing CI/CD stay in place, or does adopting a new solution mean rebuilding your pipeline?
• Can the full release cycle be covered, from branch management through phased rollout, or does the solution only address one segment of it?
• Can any engineer on the team run a release, or does it still depend on one or two people with specialized knowledge?
• Can product and leadership get real-time visibility into release status without interrupting the engineers running it?

These questions will help uncover not just how many hours are being eaten by your existing release process, but the cost of efficiency to DevEx, release predictability, and the ceiling of what your team can ship. 

Runway is built to manage the entire mobile release workflow to reduce process waste and drive developer satisfaction. It layers on top of Bitrise, GitHub Actions, CircleCI, and other CI providers with no migration required, connecting every step of the release cycle, from branch cut through phased rollout, into a single repeatable system.

Explore how Runway connects your release workflow or start free.

‍

FAQ 

Why do mobile teams still lose time on releases even with CI/CD and automation in place?

Because CI/CD was built to automate the build, and the release process extends well before and beyond it. Branch management, store submissions, QA coordination, rollout monitoring, and stakeholder communication all sit outside what CI/CD handles. According to our 2025 State of Mobile Release Management Report, 75% of teams invest in automation and scripting, yet 51% of those with significant automation still lose 6 to 10 hours per release. The bottleneck shifts from the build to the coordination layer, but the time loss persists.

How much does mobile release overhead actually cost a team per year?

More than most teams realize. A senior mobile engineer on a weekly cadence, spending 7 hours per release on non-product work, with 13 hotfixes per year and a 38% context switching tax, accumulates roughly 535 hours annually. At a fully loaded rate of $185/hr, that's close to $99,000 per year in engineering time spent on release operations, not product development, for one engineer, on one team.

How often do mobile teams need hotfixes, and how much time do they add?

Frequently enough to treat as a baseline rather than an exception. According to our 2025 report, 77% of mobile teams need hotfixes every 3 to 5 releases. Each one means cherry-picking the fix to the release branch, bumping the build number, re-running the full submission pipeline, and waiting on App Review again, typically 3 to 5 additional hours of compressed release work, under pressure, with less lead time than a standard release.