The State of Mobile Development 2026
Mobile teams are building more than ever. AI is exposing who was ready and who wasn't.
Introduction
Bitrise powers build, test, and release pipelines for thousands of mobile teams, from two-person startups to the largest apps on the App Store and Google Play. Last year, we shared what that vantage point showed us in Mobile Insights 2025. This year, the story is all about AI. And while AI coding tools aren't new — they've been reshaping software more broadly for a couple of years now — what changed in 2026 is how much of that reached mobile. That's the question we set out to answer: what is AI-written code doing to mobile development?
There's already plenty of research on how developers feel about coding with AI, and no shortage of debate about what it might break. But most of those insights come from surveys. We wanted to look at the data instead. Pipelines don't have opinions: builds either pass or fail, speed up or slow down. This report follows that record.
So, we compared Q1 2025 against Q1 2026 across more than 19 million anonymized builds on our platform, with the core comparison drawn from teams active in both quarters. We only counted a build as AI-attributed when the tool identifies itself, through a co-author line, bot trigger, or agent branch name. That means every AI figure in this report is a minimum baseline, not a ceiling: the true numbers are likely higher. The full methodology is included at the end.
The data did not show the story we were braced for. The short version is this: the predicted big AI pipeline breakage never arrived, and what differentiates high-performing teams today isn't how much AI they use, but the infrastructure and setup around it. This reports sets out the full story, chapter by chapter, with the data on the table.
Key findings
AI-attributed builds grew year on year — the fastest-growing source of new work on the platform.
Build failure rate held flat year on year (17.8% in Q1 2025), with about one build in six failing, even as volume increased. AI didn’t make builds less reliable.
Build volume grew year on year, with AI-attributed builds behind roughly a sixth of that rise.
100% of the sectors we track now run AI-attributed builds, from at least 13% of workspaces in insurance to 36% in travel. A year ago, this was near zero everywhere.
iOS builds are now faster than Android, clocking in at 12.05 mins average build duration. The lines crossed in mid-2025 as the M4 fleet arrived. But Android got 7% faster too, alongside a 53% rise in Gradle Build Cache adoption.
Of the highest-volume teams run caching, test reporting and observability together, compared to 6.6% of light-use teams. At least 45% of active workspaces run automated tests in CI, but only 34% have test reporting enabled.
We can see that AI is now writing mobile code
AI-attributed builds grew 161× from Q1 2025 to Q1 2026.
We attribute a build to AI when at least one of three is present: a co-author line in the commit (Co-authored-by: Claude [email protected]), a known bot account triggering the build (webhook-github/cursor[bot]), or an agent-style branch name (devin/1777625139-migrate-item-post). Everything in this chapter counts only those tagged builds, so the true figure is likely higher still, as this analysis captures only AI use that leaves an identifiable signature.
Some AI code never gets a signature. Paste it from a chat window, or commit assistant-written code under your own name, and it looks like any other commit. Plus, the signatures themselves are also new: most didn't exist in early 2025, so the further back we look, the more we miss.
Even just looking at tagged builds, the growth is still sharp: a 161× rise in just one year.
The chart tells the tool story at a glance: Devin led a tiny early market, Claude took over in mid-2025, and Codex and Cursor are the ones climbing now. That said, there are two things the chart can't show. First, a falling line doesn't mean a shrinking tool. The market underneath grew a hundred-fold, so Devin and Copilot run more builds than ever: only their share shrank as Claude exploded.
Second, share of builds is not the same as reach: Copilot shows up in more workspaces than any other bot integration but it runs few builds in each, so its share understates how many different teams are actually using it.
Every industry has teams building with AI now
Every sector we track now runs AI-attributed builds, from at least 13% of workspaces in insurance to 36% in travel. A year ago, that number was near zero everywhere.
A year ago, evidence of AI adoption was basically a rounding error. Today, teams in all 17 sectors we track are building with it. Consumer-facing tech is setting the pace: travel leads with 36% of workspaces running at least one AI-attributed build, closely followed by food delivery and consumer electronics at 35%. Further back sit the regulated and risk-sensitive sectors: insurance, sports betting and Original Equipment Manufacturers (OEMs) in the connected car industry. These teams have more reason to be careful with AI tooling, but none of them are sitting it out.
Even the insurance sector, at the back of the chart, runs AI builds in at least 13% of its teams.
What stands out is how broad this is. Industries differ by how many teams have picked up AI, not by whether anyone has, and every sector has climbed from near zero within a year. Trying AI is now close to standard across mobile. Where industries still diverge is in how heavily they lean on it, for now.
More code is coming down the pipeline than ever
The same teams ran a fifth more builds this year than last.
More builds written means more arriving in the pipeline. Among teams active in both Q1 2025 and Q1 2026, build volume grew 20.9% year on year. That works out as roughly two extra CI runs a week for an individual developer on a large team.
Most of this is ordinary growth of mobile CI: non-AI builds alone grew about 1.2×. But AI-attributed builds grew faster than anything else on the platform, and while they still only account for about a sixth of the total increase, that share only climbs from here.
This growth pattern shows up on every platform. Among teams active in both years, iOS build volume grew 27%, cross-platform 17%, and Android 14%. And it doesn't spare teams that sat still: workspaces that added no new tooling or capacity all year still saw 15.4% more builds.
You don't have to use AI yourself to feel it, your dependencies update faster, your teammates' tools push more commits, and it all lands in your CI queue.
AI-written code isn't causing the spike in build failures many feared
AI-attributed builds fail less often (16.3%) in CI than non-AI builds (17.4%), and finish about 9% faster.
The overall build failure rate held flat year on year (17.8% in Q1 2025), even as volume grew.
However highly you rate today's models, you might still expect AI-written code to break more builds. Our data shows the opposite: AI-attributed builds fail slightly less than non-AI builds (16.3% vs 17.4%) and run about 9% faster on average (10.7 vs 11.8 mins), with a shorter slow tail (P90 of 22 vs 24 minutes). Part of this is down to where the builds run, since AI-attributed builds concentrate in workspaces with more mature setups. So we ran a second analysis to remove that setup advantage: comparing AI-attributed vs non-AI builds inside the same workspace. Turns out when team, pipeline and setup all stay the same, AI-attributed builds still fail less and finish about 5% faster.
Note: The data is measured from CI onward, so it's about the builds that reach the pipeline, not whatever a developer or agent did before pushing. And it compares builds, not the same workflow run two ways: we can't line up one pipeline triggered once by a person and once by an agent, so part of the gap may be that AI-attributed builds tend to be different work. What the data does say is that builds carrying an AI signature are not failing more, even inside the same teams.
The wider picture tells the same story. Even though build volume grew by about 20% within the same teams, and failure rates stayed flat at about 17%, roughly one build in six, exactly where they were before AI arrived in the pipeline.
The failures that remain are changing in character: among the failures we can categorize, the share caused by quality checks doing their job (a test catching a bug, lint catching a problem) rose from 21.5% to 25.3%, while genuine infrastructure failures held stable at ~5.6%.
This looks less like teams catching problems by hand and more like automation catching them first. And we know that automation has scaled sharply: Bitrise's automatic test-rerun feature, which re-runs failed tests to flag flaky ones, now fires around five times as often as it did in January 2025. Among teams using Bitrise Test Reports, per-test failure rates halved even as test volume grew 78%.
Capacity told the same story of who was ready: on modern infrastructure (Bitrise's current-generation build stack) P90 queue waits fell 13% while volume rose 17%, while teams still on older infrastructure watched the extra load turn into queues, with their longest waits stretching past half an hour.
Build times fell, even as build volume grew by more than 20%
iOS build are now faster than Anroid, with average iOS build duration falling to 12.05 mins in Q1 2026, down 12% year on year, compared to 12.98 mins for Android (12.98 mins).
Android’s failure rate on non-PR builds fell 1.68 percentage points year on year — the largest reliability improvement of any segment in the dataset.
Even though a fifth more volume landed on the same platform, builds actually got faster. There were two reasons for this: faster hardware and more build caching. Mobile CI benchmarks have long shown iOS builds to be the slowest, but in mid-2025 the lines crossed with the arrival of the M4 and M4 Pro fleet.
The average iOS build on Bitrise finished Q1 2026 in 12.05 minutes, 12% faster than a year ago and ahead of Android for the first time, even though iOS workflows run 10% more steps than they did last year. More work, less time.
That gain is almost entirely hardware. A year ago, 61% of iOS builds ran on M1 machines: today it's 4%, with M4 going from zero to 54% of the fleet in the same window, and even M2 builds got 16% faster within their class. An iOS engineer on a large team gets back around 11 hours a year from build speed alone. This speed gain was universal, with all teams benefiting equally, so it wasn't what separated the leaders from the rest.
Nevertheles, one Apple-shaped caveat to mention: in the weeks after a major Xcode release, failure rates spike by as much as 16 percentage points as teams migrate, worst for teams tracking floating stack tags. Pinning your Xcode version, so you upgrade on your own schedule instead of Apple's, is still the easiest reliability win in mobile CI.
On Android, the speed gains came from teams themselves, not the platform. Android builds fell 7% to 12.98 minutes, and even the slowest improved (P99 from 59 to 57 minutes). The mechanism was tooling, not hardware: Gradle Build Cache adoption grew 53% year on year at steady ~35% hit rates, and durations fell as more teams switched it on. Our 2025 Mobile Insights Report measured what caching enabled (25% off median build times, up to 30% off the slowest); this year, Android teams cashed in those gains.
The trend is spreading too, with more iOS teams starting to pick up Xcode Build Cache since it launched in Q3 2025.
Android also logged the biggest reliability gain in the dataset over the same year: non-PR build failures fell 1.68 percentage points (17.1% to 15.4%). We know this isn't a caching effect (caching changes how fast a build runs, not whether it passes) and right now the data doesn't tell us what drove it, but it's still a notable win for Androud teams.
What the highest-volume teams do differently
Over 80% of our highest-volume teams (5,000+ builds a quarter) run caching, test reporting and observability together. Among the lightest teams, it’s only 6.6%.
At least 45% of active workspaces run automated tests we can identify in CI, and the true share is higher. Only 34% use test reporting to see the results.
By industry, AI readiness was mixed. Stacked by build volume, it lines up into a clean staircase: the more builds a team runs, the more instrumented it is. Among workspaces running 5,000+ builds a quarter, all rely on CI observability, 96.8% use build caching, and at least 81.9% run automated tests. But these key pillars fall away as build volume drops.
The widest gap at every size is test visibility: at least 45% of active workspaces run automated tests we can identify in CI, and roughly 86% of all builds happen inside those workspaces, but only 34% have test reporting. Reporting is opt-in feature and takes setup, so plenty of teams run tests but never surface results as pass rate trends or flaky-test counts. The true testing share is probably higher still, since we can’t measure tests buried in plain script steps.
What tooling buys, more than anything, is the ability to handle volume. A small team at a modest pace can manage without much of it. But when you're running 5,000 builds a quarter, caching keeps the queue from becoming a critical bottleneck, automated tests catch problems as fast as they arrive, and observability tells you why something broke without hours of investigation.
Today, fewer than a quarter of active workspaces run all three, but nearly three-quarters of all builds happen inside the ones that do. In terms of AI, this means adoption doesn't tax teams evenly: the gains (and blockers) it creates multiply based on whatever infrastructure you already have in place.
What comes next
AI coding didn't start this year, but this was the year it visibly arrived in mobile. The initial 161× jump won't repeat, but it doesn't have to: your pipeline is only going to see more AI-written code, and that trend isn't reversing.
The real divide is between teams that automated their build and test setup and those that haven't, not between AI leaders and laggards. The teams that coped with increased build volume relied on infrastructure: caching, automated retries, observability, and tests on every commit.
Our biggest takeaway: if you do one thing this year, run automated tests in CI. It's the simplest way to catch problems before they reach users, and the teams doing the most building already run them: more than eight in ten builds happen in workspaces with automated tests.
The question isn't whether AI-written code is coming to mobile: it's already here, and next year we predict that it will represent an even bigger share of overall build volume growth. The real question is whether your pipeline is ready for it.
Methodology
- All findings are based on aggregated, anonymized Bitrise customer data. The full dataset covers more than 19 million builds across the trailing twelve months. The core comparison is Q1 2025 versus Q1 2026.
- Year-on-year comparisons use a same-store cohort of teams active in both quarters (roughly 10 million builds), which isolates real behavior change from customer churn.
- AI-attributed builds are identified by the presence of one or more three direct signals: AI co-authorship or generation footers in commit messages (Claude, Cursor, GitHub Copilot, Devin, Aider, OpenAI Codex/ChatGPT/GPT, Gemini Code Assist, Google Jules, Qodo), builds triggered by known AI bot accounts, and AI-tool branch naming conventions. We only count AI that leaves one of these marks, so the real figure is likely higher than what we report.
- Success and failure rates follow the Mobile Insights 2025 methodology, so they're comparable with last year's report.
- Per-build adoption figures weight each workspace by its Q1 2026 build volume, excluding two outlier customers. Per-workspace figures count each workspace once.
- Team-size bands (Chapter 6): Light = 5-50 successful builds per quarter, Regular = 51-500, Heavy = 501-5,000, Very heavy = 5,000+, across all workspaces active in Q1 2026.
- Infrastructure comparisons distinguish modern and legacy Bitrise infrastructure generations. No customer plan details are disclosed.
- Testing adoption is measured two ways: test-executing steps we can identify (xcode-test, Gradle test tasks, fastlane scan and similar), at least 45% of active workspaces; and adoption of Bitrise Test Reports (34%), an opt-in feature requiring configuration, whose adoption understates how many teams run tests. Tests inside plain script steps can't be detected.
- Anonymized customer stories are drawn from per-customer platform data; no customer is named without explicit permission.