The State of Mobile CI/CD 2026

Shipping iOS and Android is slow and expensive for one structural reason, and most of it is the macOS runner.

Executive summary

Mobile CI is its own world, and the thing that makes it different is not the code, it is the hardware. iOS builds legally require macOS, macOS runners are the most expensive compute a hosted CI provider sells, and on published pricing a macOS minute costs about ten times a Linux minute. That single fact shapes every decision a mobile team makes about its pipeline, from how it splits work across operating systems to how aggressively it caches to how it thinks about device testing.

On top of the platform tax sits a stack of mobile-specific friction. Xcode and Gradle builds are long, code-signing and provisioning break in surprising and intermittent ways, and device or emulator testing is slow and flaky in ways web testing rarely is. Each of these is worse on mobile than on the web, and each compounds the cost of the runner it runs on, because on mobile that runner is frequently the most expensive one in the catalog. The friction and the cost multiply rather than add.

This report quantifies the macOS-versus-Linux cost shift, where mobile build minutes go, and how teams cut the bill by keeping work off macOS where the platform allows it and by caching the parts of the build that do not change. The recurring theme is that almost every effective mobile-CI optimization is, underneath, a way to spend fewer macOS minutes, because the macOS minute is where the money is.

Three figures frame the year. A macOS minute lists at roughly ten times a Linux minute on hosted runners, which is the structural fact behind everything else. Around two-thirds of a typical cross-platform mobile team's CI bill is attributable to macOS minutes specifically, far out of proportion to the share of work that genuinely needs Apple hardware. And the median iOS build runs well over twice as long as its Android equivalent, so the expensive runner is also the slow one, which is the worst possible combination for a bill.

For mobile engineering leaders the practical message is that the bill is governed by one ratio and one discipline. The ratio is macOS to Linux per-minute cost; the discipline is keeping every minute that does not strictly need Apple tooling off the macOS runner. A team that internalizes the ratio and applies the discipline, then caches the unavoidable macOS work and recovers its transient signing failures, turns the most expensive pipeline in software into a manageable one without giving up any coverage.

The macOS minute is the whole story

On published GitHub-hosted pricing a macOS minute runs about 10 times a Linux minute, and because iOS builds and tests must legally run on macOS, the macOS runner ends up driving the majority of a mobile team's CI bill. The runner-cost chart makes the gap visible: Linux sits near the floor, Windows is double it, and macOS towers an order of magnitude above both. There is no negotiating this ratio away, because it is a property of the hardware Apple requires, not a pricing quirk.

The bill-split chart shows the consequence. Around two-thirds of a cross-platform mobile team's CI spend goes to macOS and iOS minutes, even though the iOS-specific work is a minority of the total pipeline by step count. The Android build, the linting, the packaging, and most of the test setup are cheap Linux work; the macOS minutes are few but each costs ten times as much, so a small share of the work commands a dominant share of the bill.

This is why every other optimization in mobile CI is, in effect, a way to use fewer macOS minutes. Caching the Xcode build, splitting work onto Linux, recovering signing flakes without a full re-run: each one is valuable in proportion to the macOS time it removes. A team that understands that one ratio understands its bill, and a team that does not will keep optimizing cheap Linux minutes while the expensive macOS minutes quietly run the meter.

• A macOS minute models at 10x a Linux minute, set by Apple's hardware requirement, not by pricing.
• Roughly two-thirds of a cross-platform mobile bill is macOS minutes, far above their share of pipeline steps.
• Every effective mobile-CI optimization is, underneath, a way to spend fewer macOS minutes.

Keep everything off macOS that does not need it

The Android build, lint, formatting, dependency analysis, and most packaging steps run fine on cheap Linux, yet teams routinely leave them on macOS out of inertia, running cheap work on the most expensive runner in the catalog. The discipline that cuts mobile CI cost is mechanical: route every job that does not strictly require Apple tooling to Linux, and reserve macOS strictly for the Xcode compile, sign, and on-device legs that genuinely cannot run anywhere else.

The savings chart quantifies the move. A Linux-where-possible split is materially cheaper than even a well-cached all-macOS pipeline, because it removes whole categories of work from the ten-times runner rather than just speeding them up on it. The macOS-specific surface, the part that truly needs Apple hardware, is much smaller than the matrix that tends to grow up around it, so the reshaping recovers more than teams expect.

The reason this works so well is the same reason it is so often missed: the expensive runner ends up doing cheap, OS-agnostic work that would pass identically on Linux. Auditing which jobs actually touch Apple tooling, and demoting everything else to Linux, is usually the single largest one-time cut a mobile team can make to its bill, and it costs nothing but a configuration change and the loss of an assumption.

• Android builds, lint, formatting, dependency analysis, and most packaging run fine on cheap Linux.
• Reserve macOS strictly for Xcode compile, signing, and on-device legs that need Apple tooling.
• The genuinely macOS-specific surface is smaller than the matrix that grew around it.

iOS builds are long because the compile is long

Across mobile pipelines the iOS build is consistently slower than the Android equivalent, modeling at well over twice the wall-clock, and the dominant cost inside it is the Xcode compile-and-link stage. The build-time chart breaks an iOS build into its stages, and the compile-and-link leg towers over dependency resolution, signing, archiving, and upload combined. That stage is where the macOS minutes pile up, which makes it the part of the build most worth attacking.

Caching derived data and dependency artifacts between runs takes a meaningful bite out of that stage. An incremental Xcode build that restores derived data instead of recompiling from scratch turns a long cold compile into a much shorter warm one, and the same applies to CocoaPods and Swift Package Manager dependency resolution, which is itself a non-trivial stage. The build is long because so much of it is recomputed every run that did not need to be.

This matters disproportionately because every minute saved here is a macOS minute at macOS prices. A caching win that would be a rounding error on a Linux pipeline is ten times as valuable on the iOS compile stage, because the minutes removed are the most expensive minutes a mobile team buys. The longest, most expensive stage of the most expensive build is exactly where caching pays the most, which is why derived-data caching is near the top of every effective mobile-CI plan.

Code signing is the silent flake

Provisioning profiles, expiring certificates, and keychain state make code signing one of the most failure-prone steps in mobile CI, and unlike a compile error it fails intermittently and for reasons that have nothing to do with the code. A profile that was valid yesterday, a certificate that rotated, a keychain that did not unlock cleanly: each produces a red build that a clean retry often clears, which is the signature of a transient failure rather than a real one.

The cost of these flakes is amplified by where they happen. A signing failure burns expensive macOS minutes before it fails, because signing sits late in the build after the long compile has already run, so the team pays for the whole macOS build and then gets nothing for it. Re-kicking the build pays for it all again. On the most expensive runner in software, a late-stage transient failure is one of the costliest failure modes there is.

Many of these failures are environmental and clear on a clean retry, which is exactly the class of failure self-healing runners absorb without a human re-kicking the build. When a signing step fails on a known-transient signal and the platform retries it on a fresh environment automatically, the failure never reaches the developer and the expensive macOS minutes already spent are followed by a recovery rather than a discarded run. For mobile, where every wasted macOS minute is costly, that recovery is worth more than on any other platform.

Caching pays double on Apple silicon

A cache hit that saves a minute on Linux saves a small amount of money; the same cache hit on macOS saves roughly 10 times as much, because the minute it removes is a macOS minute. This is the single most important asymmetry in mobile CI economics: caching has the same mechanism everywhere but a wildly different payoff depending on which runner it runs on, and on mobile it runs on the most expensive one.

That is why dependency and derived-data caching is the single most cost-effective change a mobile team can make. The savings chart shows cached macOS pipelines well below uncached ones, and the gap is large precisely because the cached minutes were so expensive to begin with. A mobile team that caches aggressively is not doing the same optimization as a web team with a tenth of the benefit, it is doing the same optimization with ten times the benefit.

A managed macOS runner with a warm cache changes the economics more sharply for mobile than for any other workload, because it combines a lower per-minute rate with the cache hits that remove the most expensive minutes. The chart's managed-and-cached case is the lowest of all, and it gets there by attacking both terms at once: a cheaper macOS minute and fewer of them. For a workload defined by the cost of a single runner type, attacking both the rate and the count of that runner's minutes is the whole game.

• A cache hit on macOS saves roughly 10x what the same hit saves on Linux.
• Derived-data and dependency caching is the most cost-effective single change a mobile team can make.
• A managed, cached macOS runner attacks both the rate and the count of expensive minutes at once.

Device and emulator testing is slow, flaky, and macOS-bound

On-device and emulator testing is the third meaningful slice of a mobile bill, and it carries its own combination of problems: it is slow to boot, prone to intermittent failures from simulator state and timing, and on iOS it is bound to macOS because the Simulator runs only there. So the flakiest, most timing-sensitive testing a mobile team does also runs on its most expensive hardware, which is the same expensive-and-unreliable pairing that defines the rest of mobile CI.

The flakiness here is structural rather than incidental. Simulators carry state between runs, animations and timing introduce races, and a freshly-booted simulator behaves differently from a warm one, so a test that passes locally fails intermittently in CI for reasons that have nothing to do with the code under test. Each such failure on a macOS runner burns expensive minutes and, if it forces a full re-run, burns them twice.

The mitigations mirror the rest of the report. Keeping non-UI tests off the Simulator and on cheaper hosts where possible reduces the macOS-bound surface, a fresh per-job environment removes the state-bleed class of flakes, and automatic recovery of transient simulator failures stops a timing race from costing a second full macOS run. Device testing will always be the slowest part of mobile CI, but it does not have to be the most wasteful, and the same disciplines that govern the build govern it too.

The fastest mobile teams treat the macOS runner as scarce

The mobile teams with the healthiest pipelines share a single mindset: they treat the macOS runner as scarce, expensive capacity to be conserved, not as a default to reach for. Every decision flows from that, from the Linux-first matrix to the aggressive derived-data caching to the auto-healing of signing and simulator flakes. None of it is exotic, and all of it is in service of spending fewer, cheaper, more reliable macOS minutes.

These teams also measure the right thing. Instead of tracking total CI minutes, which is dominated by cheap Linux work and hides the real cost, they track macOS minutes specifically and the cost per iOS build, because that is the number that actually moves their bill. Watching the expensive metric rather than the aggregate one is what lets them catch a regression in macOS usage before it becomes an invoice surprise.

The combined effect is a mobile pipeline whose cost is proportional to the genuinely Apple-specific work it does, rather than to every job that happened to land on a macOS runner. That is the achievable goal: not eliminating the macOS minute, which is impossible, but ensuring that every macOS minute spent is one that truly needed Apple hardware, was not recomputable from cache, and was not wasted on a transient failure. A team that holds that line ships iOS and Android affordably; a team that does not pays the ten-times tax on work that never needed it.

Recommendations

Audit the matrix and demote every non-Apple job to Linux

The single largest one-time cut a mobile team can make is to route every job that does not strictly require Apple tooling, the Android build, lint, formatting, dependency analysis, and most packaging, onto cheap Linux, and reserve macOS for Xcode compile, signing, and on-device legs. The genuinely macOS-specific surface is smaller than the matrix that grew around it, so this recovers more than expected and costs only a config change.

Cache derived data and dependencies aggressively

Caching pays roughly ten times more on macOS than on Linux because the minutes it removes are macOS minutes. Cache Xcode derived data, CocoaPods, and Swift Package Manager artifacts between runs so the long compile-and-link stage restores instead of recompiling. This is the most cost-effective single change available to a mobile team, and it targets the longest, most expensive stage of the most expensive build.

Auto-heal signing and simulator flakes instead of re-kicking

Code signing and Simulator testing fail intermittently for environmental reasons and burn expensive macOS minutes before failing, often late in the build. Retry these transient failures on a fresh environment automatically so a profile hiccup or a simulator race never forces a developer to re-run a whole macOS build, which would pay for the expensive minutes a second time.

Track macOS minutes and cost per iOS build, not total minutes

Total CI minutes are dominated by cheap Linux work and hide the real cost driver. Track macOS minutes specifically and the cost per iOS build, because that is the number that moves the bill, and watching it lets you catch a regression in macOS usage before it becomes an invoice surprise.

Use a managed, cached macOS runner to attack rate and count together

A managed macOS runner with a warm cache combines a lower per-minute rate with the cache hits that remove the most expensive minutes, attacking both terms of the cost at once. For a workload defined by the price of a single runner type, lowering both the rate and the count of that runner's minutes is the whole game, and it gets the bill lower than caching or rate alone.

Outlook

Expect the macOS minute to remain the defining constraint of mobile CI/CD for as long as iOS builds require Apple hardware, which is to say indefinitely. The ten-times ratio is not a market inefficiency that competition will erode; it is a property of the platform, so the teams that win on mobile CI cost will keep winning by conserving macOS minutes rather than by waiting for the price to fall. The discipline is durable because the constraint is.

The architectural direction is toward managed macOS capacity that is warm, cached, and self-healing becoming the way serious mobile teams ship. The same properties that help every other workload help disproportionately on mobile, because they all reduce the count or the cost of the most expensive minutes in software. As that becomes understood, the all-hosted-macOS pipeline with no caching will look like the obvious waste it is.

For most mobile teams the takeaway is that the bill is governed by one ratio and one discipline, and both are within reach. Keep every minute that does not need Apple tooling off the macOS runner, cache the unavoidable macOS work, and recover the transient signing and simulator failures, and the most expensive pipeline in software becomes a manageable one. The organizations that hold that line will ship iOS and Android affordably while their peers pay the ten-times tax on work that never needed it.

Methodology

This report combines published GitHub Actions runner pricing with Latchkey's own analysis of mobile CI economics. The macOS-versus-Linux per-minute ratio reflects published GitHub-hosted rates at time of writing (Linux at $0.008/min, macOS at $0.08/min). Figures labeled "modeled" are illustrative estimates derived from that pricing and typical iOS and Android build shapes, not a primary survey. The managed rate and the roughly 70 percent saving are modeled blended figures. Build times, bill splits, and monthly costs vary widely by project size, dependency graph, and test strategy. Figures labeled "modeled" are illustrative estimates derived from public pricing and typical pipeline shapes, not a primary survey; figures attributed to a named source reflect that source. Pricing reflects published rates at time of writing and should be verified against current provider pricing.

Sources

• GitHub Actions - billing & pricing
• Stack Overflow Developer Survey
• GitHub - Octoverse
• DORA State of DevOps Report

More Latchkey reports