Ask a mobile team how much of their code an assistant drafts today, and the honest answer is a large share of it. Ask whether the last project shipped in half the time, and the tone changes. Both things are true at once: code appears faster than ever, but delivery dates have barely moved. That gap is not a failure of the tools, nor a reason to ignore them. It is a signal that typing was never the constraint.
Writing Code Was Never the Bottleneck
Break a mobile project into where the calendar actually goes, and code generation turns out to be a modest slice. There is deciding what to build, design iterations, integration with external systems, testing across a device matrix, the store submission cycle, and review—which has quietly become the busiest station on the line. Speeding up one step only shortens the chain if that step was the bottleneck. Generation was not. The saving is real but small, and it pushes the pressure elsewhere.
The Bottleneck Moved to Review
Reading code you did not write is slower than reading code you did. An assistant can produce a plausible 300-line change in the time it takes to describe the requirement. Understanding that change well enough to approve it takes what it always has. Output rose; review capacity did not. Pull requests get bigger, review gets shallower, and defects surface later, when they are more expensive. Teams that get real value impose three rules: keep diffs small, require an author who can explain every line, and never merge on a green test run alone.
Platform Knowledge Gaps
Suggestions are shaped by the code a model has seen, and public mobile code skews old. The assistant reaches for a deprecated API, an outdated permission flow, a threading pattern from before structured concurrency, or a library whose last release predates the current toolchain. All of it compiles. Some will not pass store review. Dependencies add further risk: Apple now requires privacy manifests and signatures for common SDKs, and every dependency carries a license, data collection disclosure, and maintenance risk. A model that suggests a package is not weighing any of that. None of these problems announce themselves; a compiler will not catch them.
Where AI Genuinely Excels
Assistants are excellent at boilerplate: data classes, serialization, wiring between layers. They are good at tests, especially edge cases people skip when tired. They excel at mechanical migrations (Java to Kotlin, Objective-C to Swift) and shorten the time to get oriented in an unfamiliar API. Throwaway code becomes almost free, changing what is worth prototyping. The gain is largest where work is mechanical, verifiable, and cheap to be wrong about. It shrinks to nothing where work depends on something the model has no access to: your data model, users, regulatory constraints, or historical decisions.
What This Changes About Buying Mobile Development
If the constraint has moved from production to verification, then the thing worth buying has moved too. Useful questions for a prospective partner now sound different: What is the review policy? Who is accountable for a line nobody wrote by hand? How does a new dependency get approved? What runs automatically on every commit, and on how many real devices? Those questions say more about the outcome than headcount or day rate. The mobile development teams that succeed today look less like typing and more like reviewing: fewer hands, more judgment, and a process that assumes code needs to be defended rather than merely delivered.
The Real Lever: Feedback Loops
If generation is fast and verification is slow, invest in verification. Continuous integration on every commit, an automated device matrix, static analysis and dependency scanning in the pipeline, builds that reach testers in minutes. The teams that actually got faster over the last two years are the ones that shortened the distance between writing something and finding out whether it works. The assistant is one input into that loop. It was never going to be the loop itself.