AI in Mobile Development: What It Can and Can't Do (Yet)

This is the third post in a series adapted from my guide, Build It Right: An Insider's Guide to Mobile App Development for Non-Developers. Each entry takes one slice of the guide and turns it into something you can read in ten minutes.

There's a version of mobile app development that exists right now in marketing copy and YouTube demos, and a different version that exists when you're trying to ship something users will actually pay for. The gap between the two is mostly about AI.

If you've been told that AI can build your app for you, or that you can describe an idea to a chatbot and get a finished product, you've heard the marketing version. The reality is more interesting and more useful. AI has genuinely changed mobile development. It hasn't changed it the way you may have been told.

This post is about what AI actually does well, where it breaks down, and what that means when you're hiring a developer.

What AI is genuinely good at

The honest answer: a lot of the day-to-day work of writing code.

Modern AI tools are remarkably effective at generating boilerplate (the routine, repeating bits of code that every app needs), translating between similar pieces of code, drafting tests, writing documentation, and handling the parts of programming that are mostly pattern matching against examples.

When I work on a project, AI saves me real time on tasks like setting up a new screen that follows the same structure as one I've already built, writing the data model code that handles JSON from an API, generating the dozens of small SwiftUI views that make up a feature, and producing the unit tests that verify a function does what it's supposed to. None of these tasks are intellectually interesting. All of them used to take time. Now they take less.

That's the legitimate productivity story. A senior developer using AI well is meaningfully faster than the same developer was three years ago.

Where it breaks down

The trouble starts when AI is asked to do work that requires judgment rather than pattern matching.

Architecture (how the pieces of the app fit together, where data flows, what depends on what) is judgment work. AI tools can produce a plausible-looking architecture, but plausible and correct are different things, and the difference doesn't show up until later. An app with a poor architecture works fine for the first few features and gets harder to extend with every one after that, until eventually adding a feature breaks three others and nobody can remember why.

Performance is judgment work. AI can write code that does what you asked, but doing what you asked at scale, on a battery-powered device, with limited memory, while staying responsive to user input, is a different problem. AI tools rarely think about that without being told to, and even when told, the judgments they make are often wrong in ways that aren't visible from the outside.

Security is judgment work. Data handling, authentication, payment flows, anything involving user privacy. AI tools will happily produce code that works and is also subtly insecure in ways that won't be discovered until something goes wrong.

The pattern is consistent. AI is excellent at the parts of programming that look like writing. It's much weaker at the parts that look like engineering.

The "looks done, isn't done" problem

This is the failure mode I see most often, and it's the one that catches non-technical clients hardest.

You hire someone, possibly inexpensively, who is using AI tools heavily. They produce something quickly. The screens look right. You can tap through it. It seems to work. You sign off, you launch, and then within weeks or months one of these things happens:

• The app is rejected at App Store review for reasons the developer can't quickly fix.
• Users start reporting crashes the developer can't reproduce.
• You want to add a feature and discover that adding it requires rebuilding pieces of the existing app.
• The app is slow on older devices and nobody knows why.
• Something breaks when iOS updates and there's no clear path to fixing it.

What happened, almost always, is that AI generated something that looked like an app but wasn't built like one. The visible parts are fine. The structural parts (the parts you can't see, the parts you'd have to be a developer to evaluate) were never engineered. They were generated, and then left in whatever state the AI happened to produce them.

Cleaning this up after the fact is its own kind of project. I do this work fairly often, and it's almost always more expensive than building the app properly the first time would have been.

What to look for when hiring

A developer who tells you they don't use AI at all is leaving real productivity on the table, and you're paying for it. A developer who tells you AI does most of the work is selling you the marketing version, and you'll pay for that later. The developers worth hiring are in between.

When you're evaluating someone who uses AI, the questions that matter:

• Where does AI help in your work, and where do you not use it?
• How do you verify what AI generates before you commit it to the project?
• Can you walk me through a recent decision where you chose not to use AI's output?
• What does your testing process look like for AI-generated code?
• Have you ever inherited an AI-built app? What did you find?

You're not looking for someone who can recite all the AI tools they use. You're looking for someone who treats AI as a tool with limits, has internalized those limits, and applies real judgment to what it produces.

A useful warning sign: if a developer can't tell you anywhere AI falls short, they probably haven't pushed it hard enough to find out.

The point

AI hasn't replaced the need for skilled mobile developers. It has changed what skilled mobile developers spend their time on. Less typing, more judgment. Less boilerplate, more architecture, performance, and review.

For you as a client, this means two things. First, you can reasonably expect projects to move faster than they did a few years ago, because the developer's time is being spent on the parts that matter. Second, the cost of hiring poorly has gone up, not down, because AI lets a less-skilled developer produce something that looks finished much earlier than they used to be able to. The visible quality of an early build tells you less than it once did.

The next post in the series gets into the timeline question: how long mobile projects actually take, why the estimates you'll be given are usually wrong, and how to recognize a realistic timeline when you see one.

This post is adapted from Build It Right: An Insider's Guide to Mobile App Development for Non-Developers. If you'd rather just talk it through, reach me at scott@appswage.com.