The Build-Time Tax Is the Most Underpriced Cost in Mobile

If you ask a senior iOS engineer at a 100+ engineer mobile org what's slowing the team down, they will not say "build times." They will say something about architecture, or sprint planning, or onboarding. Build times will come up in the fourth answer, if at all, and it will be framed as a quality-of-life complaint, not a business problem.

That framing is wrong. Build times are the most under-priced cost on every mobile roadmap I have ever read. Run the math. A hundred engineers, three incremental builds per engineer per day, ten minutes per build, five workdays a week. That comes out to roughly thirty engineer-days a week of lost productivity. A 30-engineer team sitting and watching progress bars, inside the body of a 100-engineer org. Nobody runs that math.

I have been thinking about this for a year and the conclusion I keep arriving at is uncomfortable. Build time is a platform problem with org-design consequences. Treating it as a CI ticket guarantees you under-invest. The teams getting this right have made it a first-class platform investment with named ownership, instrumentation, and a public number on a chart everyone sees. The hardware refresh I wrote about in December, once the Apple Silicon MacBook Pros went out to engineers, was the easy half of the win. The org-design half is the part most teams are still avoiding.

The build cost compounds invisibly

A build that gets one minute slower per quarter is the kind of thing nobody notices. Each individual build is fine. The trendline is fatal.

Spotify's engineering team shipped XCMetrics in January 2021 for exactly this reason: you cannot manage what you cannot measure, and Xcode's closed tooling makes the median build-time number weirdly hard to extract for any team larger than a handful of engineers. Their framing was direct: build time is the most important developer-productivity metric for a large iOS org. I think they're right. The output of the engineering function is roughly proportional to how often engineers can iterate, and how often they iterate is roughly proportional to how fast the build is.

The second Spotify post is the one that actually moved my thinking. In November they introduced XCRemoteCache, reporting a 70% reduction in clean build times. Buried in the post is the line that should be on every mobile platform lead's office wall: "It often takes our developers more than 10 minutes to build the main Spotify iOS application." That is a real production reality at a top-tier mobile org with a published platform team, before they spent a year building their own caching infrastructure.

If Spotify is at ten minutes, your team is also at ten minutes, or worse, or you have not measured.

Why every mobile org under-invests

There is a structural reason build time gets under-funded, and it isn't malice. It's the same reason any platform investment gets under-funded: it doesn't ship a user feature. The product team can show a launch. The infra team can show a SLO. The build team can show a graph that ten people care about and the rest of the org takes for granted.

This is the examples vs. mandates problem from a different angle. Build investment that comes from a top-down mandate ("we need to be on Bazel by Q3") tends to land badly because the product teams don't feel the cost of the migration in their sprint planning. Build investment that comes from a credible platform team with public numbers and a track record of cutting build times on real product surfaces tends to land cleanly, because the product engineers can see the upside in their own iteration speed.

If you are leading mobile and your build is not a roadmap line item, you do not actually have a platform team. You have an infrastructure ticket queue.

What "fast build" actually requires

A fast build is not a flag. It is three things, and you need all three.

A dependency graph you can reason about. This is what the modularization conversation is actually about, although it gets framed as "the app is too coupled." The build can't be faster than the graph of work it has to do. If every change recompiles a third of the codebase, no caching strategy and no build system will save you. Airbnb's late-2021 writeup on their 1,500-module setup is the canonical reference. They organized modules into types (UI, Flow, Service, Logic, etc.) with enforced visibility rules so the dependency graph couldn't accidentally regress. Their seventy-fifth-percentile Dev App build is under two minutes. Over half their local builds run through Dev Apps rather than the full app.

Hermetic, reproducible builds. Builds that succeed on my machine but fail on yours are not a workflow problem, they are a graph problem. Once the inputs of a build target are explicit (sources, headers, dependencies, compiler flags), caching becomes possible. Until they are, every build is a snowflake, every CI miss is a mystery, and you pay re-build cost on every fresh checkout. This is why Bazel-for-iOS keeps drawing serious mobile orgs even though the migration cost is real.

Test sharding and selective CI. Once the graph is right, your CI should rebuild and test only what the change actually touches, not the whole world. Alberto De Bortoli's monorepo + selective CI post from last June is the honest version of this story: monorepo-on-iOS implies rebuilding pipelines, not just moving folders. He's blunt about it: "Each change involves at least 2 pull requests: 1 for the module and 1 for the integration in the app." That two-PR tax is what selective CI exists to fix.

These three are coupled. You can't get one without the others. Anyone telling you "just turn on remote caching" without first reasoning about the graph is selling you a tactic that won't compound.

The Bazel question

The Bazel-for-iOS conversation has gone from "should we" to "when" at every mobile org I talk to. Keith Smiley's BazelCon postmortem from Lyft is the honest reference here, and the line worth keeping is that "adoption cost is very high." Bazel buys you shared tooling, remote caching, and remote execution. It costs you something like a year of platform-team effort and an unhappy quarter for product engineers who have to learn the new build flow.

Pinterest published a 2019 case study of clean local builds dropping from 4:38 to 3:38 and CI beta builds dropping from 14:32 to 7:52, with a CI success rate jumping from ~80% to 97-100%. That last number is the one that actually matters. Build flakiness has a productivity cost that's hard to even quantify, because engineers stop trusting the signal and start rebuilding speculatively.

My read for a 100-engineer iOS team in early 2022: Bazel is worth it, but only if you have a real platform team that owns the migration. If your "platform team" is two engineers who get pulled onto product work whenever a deadline slips, you are going to be a year and a half into the migration with no end in sight and a frustrated product org. The right play in that case is graph-surgery and caching investments inside the existing Xcode build, not a full Bazel migration. Don't sign up for the year-long thing if you can't staff the year-long thing.

Build time as an org-design problem

The deeper claim I want to make is that build time is an org-design problem masquerading as a tooling problem.

Who owns the build? At most mobile orgs the answer is "nobody, exactly." Some piece of it lives with mobile infra. Some piece lives with the iOS architects who happened to care. Some piece lives with the CI team that owns the runners. The build cost gets paid by the product engineers, who don't own the levers to fix it.

The teams making real progress on this have named ownership. There is a build team or a mobile platform team with the build time as part of their explicit charter. The team has a SLO on median build time, publishes the number, and the number is in the engineering all-hands deck. When the trend goes the wrong way, someone is on the hook. When it goes the right way, they get credit.

This sounds obvious. It is rare. Most mobile orgs have build time as a shared, diffuse, uncomplained-about cost that nobody is allowed to spend their quarter on. The result is the trend goes one way. Slower.

What I'd do this quarter on a 100-engineer iOS team

A small set of moves, in the order they pay off:

Instrument. Median PR build time, p75, p95. Median CI duration. Build success rate. Put the chart on a wall. Most teams skip this because it feels like infra work, not engineering work. It is the highest-leverage two weeks you can spend.

Name the owner. Pick one engineer with the seniority to make graph changes that affect product teams. Give them a quarter of dedicated time. The work compounds.

Audit the worst-offender targets. Spotify reported that under 3% of their builds consumed 50% of total build time. The fat tail is where the productivity tax actually lives. Most of the win is in fixing the worst 5% of build paths.

Decide on the Bazel question. Not "should we" -- "do we have the staffing to commit." If yes, start. If no, invest in caching and graph surgery instead.

Make the number a visible part of how engineering leadership evaluates the platform. This is the part most teams skip. Build time is one of the few engineering numbers that correlates almost perfectly with team velocity. If it isn't in your engineering scorecard, you are leaving the leverage on the floor.

Where I land

Build time is the most underpriced cost in mobile because the cost is paid in a currency leadership doesn't measure (engineer-minutes per day) and the investment is funded in a currency leadership does measure (headcount and feature ship dates). The mismatch is structural. Fixing it requires treating the build as a product, with a team, with a number, with a roadmap.

The teams that figured this out three years ago are now shipping faster than the teams that didn't, and the gap is widening because build cost compounds. The teams that figure it out this quarter will be in a strong position twelve months from now. The teams that don't are going to spend Q4 2022 explaining to leadership why velocity dropped.

You can't out-hire a slow build. The number is the number. Make it your number.