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 of the answer changes.
Both things are true at once. Code appears faster than it ever has, and delivery dates have barely moved. That gap is not a failure of the tools, and it is not a reason to ignore them. It is a signal that typing was never the constraint.
Break a mobile project into where the calendar actually goes and generation turns out to be a modest slice of it.
There is deciding what to build, which takes exactly as long as the stakeholders take. There is design, and the round of changes that follows the first build on a real device. There is integration with systems nobody on the team controls. There is testing across a device matrix, on hardware that behaves nothing like the simulator. There is the store submission cycle, which runs on its own clock. And there is review, which has quietly become the busiest station on the line.
Speeding up one step in a chain only shortens the chain if that step was the bottleneck. Generation was not. The saving is real, it is simply small, and it pushes the pressure somewhere else.
Reading code you did not write is slower than reading code you did. That was true before any of this, and it is the whole difficulty now.
An assistant can produce a plausible three hundred line change in the time it takes to describe the requirement. Understanding that change well enough to put your name on it takes what it has always taken. Output rose. Review capacity did not.
The failure mode follows from there. Pull requests get bigger, review gets shallower, and the defects a careful reader would have caught surface later, when they are more expensive. Teams that get real value from these tools tend to impose the same three rules: keep the diffs small, require an author who can explain every line without opening the assistant again, and never merge on the strength of a green test run alone.
This is the part that catches mobile teams off guard, and it is specific to the discipline.
Suggestions are shaped by the code a model has seen, and public mobile code skews old. So the assistant reaches for an API that was deprecated two releases ago, a permission flow that no longer matches how the platform asks a user for consent, a threading pattern from before structured concurrency arrived, or a library whose last release predates the current toolchain. All of it compiles. Some of it will not pass review at the store.
Dependencies deserve their own paragraph. Adding a third party SDK has stopped being a neutral act. Apple now requires privacy manifests and signatures for a list of commonly used SDKs, and every dependency carries a licence, a data collection disclosure and a maintenance risk along with its convenience. A model that suggests a package is not weighing any of that. Somebody still has to.
None of these problems announce themselves. A compiler will not catch a single one. They are caught in review, or they are caught by a rejection.
The picture is not one-sided, and pretending otherwise would be its own kind of mistake.
Assistants are excellent at boilerplate: the data classes, the serialisation, the wiring between layers that every project rebuilds. They are good at tests, particularly the edge cases people skip when they are tired. They are very good at mechanical migrations, moving Java to Kotlin or Objective-C to Swift, or lifting a codebase across a framework version. They shorten the time it takes to get oriented in an unfamiliar API. And they make throwaway code almost free, which changes what is worth prototyping.
The pattern behind that list is worth naming. The gain is largest where the work is mechanical, verifiable, and cheap to be wrong about. It shrinks to nothing where the work depends on something the model has no access to: your data model, your users, your regulatory constraints, and the reason the previous team made a decision that looks strange from the outside.
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, and does it change when a machine drafted the code? Who is accountable for a line nobody wrote by hand? How does a new dependency get approved, and who checks its licence and its privacy obligations? What runs automatically on every commit, and on how many real devices?
Those questions say more about the outcome than a headcount or a day rate does. The mobile application development Toronto teams do today looks less like typing and more like reviewing, and a team built for that is weighted differently: fewer hands, more judgement, and a process that assumes code needs to be defended rather than merely delivered.
There is a straightforward conclusion in all of this for anyone deciding where to spend engineering money.
If generation is fast and verification is slow, invest in verification. Continuous integration that runs on every commit. An automated device matrix rather than the two phones on the desk. Static analysis and dependency scanning in the pipeline instead of in someone's memory. A build that reaches a tester 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.