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.

iOS, Android, or Both? The Platform Decision That Shapes Everything Else

This is the second 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.

Once you have a clear vision for your app and you understand what the project actually involves, the next question you'll face is the most consequential technical decision of the whole project. Which platform are you building for? iOS, Android, or both? And if both, are you building two apps or one?

This decision shapes your budget, your timeline, the kind of developer you hire, the technologies you'll be locked into, and the experience your users will have. Most clients answer it too quickly, usually because someone told them the answer was obvious. It rarely is.

There are three real options, and each one comes with trade-offs that don't show up until you're well into the project.

Option 1: Native iOS only

Your app is built specifically for the Apple platform using Swift (no new project should use Objective C). It runs only on iPhone and iPad (and, depending on the project, Apple Watch and Apple TV).

This is the right choice more often than people think. iOS users spend more on apps and in-app purchases than Android users, and by a meaningful margin. If your app is consumer-facing in the US, the UK, Canada, Australia, or Japan, you can capture most of your addressable market with iOS alone. The platform is also more consistent: a small set of devices, a unified design language, and users who update their OS quickly. That consistency translates directly to lower development cost per feature.

Native iOS apps also feel right on iOS. Animations, scrolling, gestures, system integrations like Face ID and Apple Pay, sharing to other apps, dark mode, accessibility features. Every one of these is something Apple has spent years refining, and a native app gets all of it for free. A non-native app has to approximate them, often with mixed results.

The downside is obvious: you're not on Android. If half your customers use Android phones, you're missing them.

Option 2: Native Android only

Your app is built specifically for Android using Kotlin (or, increasingly rarely, Java). It runs on the much wider range of devices in the Android ecosystem.

Android dominates global market share, especially outside the US. If your audience is primarily in India, Southeast Asia, Africa, or much of Latin America, Android is the more sensible starting point. Android also gives you more flexibility around what an app is allowed to do: background processing, deeper system integrations, alternative app stores, sideloading.

The complications are also real. Android runs on thousands of different devices with different screen sizes, hardware capabilities, and OS versions. Testing across that range is more expensive than testing iOS. Users update their OS more slowly, so you're often supporting older Android versions years after Apple users have moved on.

Option 3: Cross-platform

You write one codebase that runs on both iOS and Android. The two main contenders today are Flutter (from Google) and React Native (from React Foundation). The pitch is irresistible: build once, ship to both platforms, save money.

The pitch is also misleading.

In practice, "build once" is closer to "build 80% once and the remaining 20% twice, in a less pleasant way than you would have if you'd just built two native apps to begin with." That 20% includes most of the things that actually matter: how the app feels on the device, integration with platform-specific features, performance under real-world conditions, the way bugs get debugged, and the long-term maintenance story when the framework ships breaking changes.

Cross-platform makes the most sense when:

• Your app is mostly content. News apps, reading apps, simple utility apps, or apps that are essentially a wrapper around a web service.
• Your team is already a web team. React Native lets web developers reuse their JavaScript skills, which can be a real advantage if you're an existing web company adding a mobile presence.
• You genuinely have to ship to both platforms simultaneously and your budget can't support two native builds.

Cross-platform makes less sense when:

• The app is performance-sensitive or graphically rich.
• The app needs deep platform integration: background tasks, sophisticated camera access, hardware-specific features.
• The app is the core product of your business rather than a companion to something else.
• You're building something you intend to maintain for many years. Cross-platform frameworks change fast, and the cost of upgrades over time is significant.

The argument I hear most often for cross-platform is that it's cheaper. Sometimes it is. I've also watched several projects start cross-platform, hit a wall, and then get rebuilt natively at much greater total cost than if they'd gone native from the start. The savings are real, but they're conditional on the app staying within the boundaries the framework handles well. The further you push past those boundaries, the faster the savings disappear.

A simpler way to think about the decision

Strip the technical detail away and the question is really about three things.

Where are your users?

If you can name the country or region your customers live in, you can usually identify which platform dominates there. Build for that platform first. You can always add the other later.

What does the app do?

If the app is a simple, content-driven experience that doesn't lean heavily on the device's capabilities, cross-platform is a reasonable starting point. If it's performance-sensitive, deeply integrated with the device, or central to your business, native almost always pays off.

What's your budget, realistically?

Two native apps cost roughly twice as much to build and maintain as one. If you're trying to do both on a budget that only really supports one, you're going to ship something half-built on both platforms. Better to ship one platform well, validate the idea, and add the other once revenue justifies it.

What this means for who you hire

The platform decision narrows the pool of developers you should be talking to. A senior native iOS developer and a senior Flutter developer are both excellent at their work, but they're optimizing for different things, and the questions you should be asking them are different.

If you're building native iOS, you want someone fluent in Swift and SwiftUI, with shipped apps in the App Store, and ideally with experience in the specific iOS subsystems your app touches (HealthKit, ARKit, StoreKit, whatever applies). If you're building cross-platform, you want someone who has shipped apps in Flutter or React Native at scale, who can speak honestly about where the framework breaks down, and who has enough native knowledge to drop into platform-specific code when needed.

A developer who claims to be equally good at all three (native iOS, native Android, and cross-platform) and equally happy on any of them is worth examining carefully. Most of the strongest mobile developers I know have a clear primary platform and treat the others as secondary.

The next post in the series gets into the AI question: what AI-assisted development actually looks like in practice, where it genuinely helps, and where the marketing has gotten ahead of reality.

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.

Before You Build: The Two Things to Get Right Before You Hire a Mobile Developer

This is the first 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.

If you're planning to build a mobile app and you're not a developer yourself, the freelance market you're about to enter is one of the most confusing markets a non-technical buyer can walk into. There are talented people everywhere. There's also rushed work, overpromised timelines, code you can't maintain, and apps that look finished but can't actually ship. Most clients don't learn the difference until after they've paid for it.

This series is meant to change that. Over the next several posts I'll walk through what I wish every client knew before they hired their first developer — what good projects do at the start that bad ones don't, where the freelance market quietly takes advantage of non-technical buyers, and how to spot trouble before it's expensive.

We're starting with the part that happens before you've posted a job: the work you should be doing yourself, before any developer is involved.

Two things matter most at this stage: knowing what you're actually building, and understanding what the project really involves. Most clients underestimate both, and pay for it later.

1. Know — and articulate — your vision

Your developer doesn't share your understanding of the problem your app is solving, or what makes it distinctive. They can't. You've spent months or years thinking about this; they're hearing about it for the first time. Misunderstandings about the product cost time, money, and goodwill on both sides, and they're nearly always preventable.

Knowing what you want isn't enough on its own. You have to describe it in meticulous detail, both verbally and in writing. A simple storyboard with images or rough sketches illustrating the user experience helps enormously. You don't need to understand the underlying technologies, but you do need to be able to explain what the app does, why it exists, and how a user interacts with it. If you can't, you're not ready to hire a developer.

A tip: use AI to clarify your own thinking

Modern AI tools are very good at helping a non-technical person turn a vague idea into something describable. You can talk through your idea in conversation with an AI, have it draft feature descriptions, produce written walkthroughs of user flows, and generate rough visuals of screens from a prose description. None of this replaces the work of real design once development begins, but it can take a fuzzy idea in your head and turn it into something a developer can actually respond to.

If you've been struggling to put your idea into words, this is a low-cost, high-value place to start.

Unclear scope is one of the most common reasons projects blow past their timelines and budgets. Time spent clarifying the vision before development starts saves far more time than it costs.

2. Understand what it actually takes

Building an app well involves more than writing code. A developer handles the code, but several other disciplines determine whether the end product actually works. If you walk in thinking "developer equals app," you're going to miss most of what's about to happen.

Here's what's actually involved.

Project management

Keeping the project on schedule and within budget. Detailed work breakdown structures are overkill for most freelance projects, but a single "due date" with nothing in between is a recipe for failure. What works is an iterative approach with small, specific milestones, consistent check-ins, and someone — your project manager or the freelancer themselves — who knows when to constructively challenge a status update. If nobody is paying attention between milestones, problems compound invisibly until the next check-in, and the next check-in isn't where you want to be discovering problems.

UI/UX design

How your app looks and how users interact with it. For consumer-facing apps, strong aesthetics and usability aren't optional. With millions of apps on the store, users abandon anything that's ugly or confusing within seconds.

UI/UX design is a specialized craft. It draws on artistic skill and on a deep understanding of the target platform and how it shapes user expectations. Don't expect your developer to be a designer; their strength is programming. Budgeting for a designer who produces detailed screen mockups — color, typography, spacing, graphical assets — is one of the more consequential investments you'll make in the project.

Testing

Quality assurance to confirm the app works as designed and holds up under real use. This goes beyond catching bugs; it covers performance, resiliency, and behavior across a range of devices and conditions.

Your developer should test their own work, and you should verify what you receive, but for most apps that isn't enough. Specialized testers find issues the developer won't spot, and they verify that the app works across the range of real-world devices your users actually carry. Consider hiring a tester to review and document testing steps, ideally well before final delivery rather than at the end. Buggy behavior gives users an easy reason to delete your app and move on. The store is full of alternatives.

Communications

The single biggest factor in whether a project succeeds. Communication problems are especially common in freelance engagements, where you're relying on individuals who may not have been trained in it.

When you're evaluating a freelancer, vet their communication carefully:

• Can they explain things without jargon or condescension?

• Do they ask sharp, probing questions and build real rapport?

• Are they candid when the news isn't positive?

• Do they actually listen to what you're saying and respond with substance?

• Are they willing to engage with your budget and offer options?

"The sales phase is when a freelancer's incentive to communicate well is at its peak. If they're not putting that effort in while they're trying to close the deal, they're not going to start once the contract is secured."

If communication is poor during the interview, it will almost certainly be worse once the contract is signed. Treat any communication concerns at the interview stage as load-bearing.

Budget understanding

A freelancer doesn't just charge you for their time. A good one manages your investment. That includes advising on technology choices, growth planning, maintenance, and other costs you may not have thought of. The true cost of a project extends well beyond the developer's fees: backend infrastructure, developer-account fees for the Apple and Google stores, revenue shares on any paid apps or in-app purchases, design work, testing, scaling costs, ongoing maintenance — all of it adds up.

A freelancer who treats your investment as their own will keep you informed of costs you may not have seen coming. A freelancer who only wants to talk about their own hours is not managing your budget, regardless of whether they use those words.

Monetization strategy

If your app is meant to generate revenue directly, you need a developer who understands the available models — subscriptions, in-app purchases, advertising, paid downloads — and can discuss which ones fit your business goals. This isn't a detail to figure out at the end. Monetization design decisions shape the whole app, and getting them wrong can get you rejected at App Store review.

Selecting complementary technologies

Most apps depend on external services: databases, authentication, analytics, push notifications, payments, social integrations, APIs. A strong developer knows the trade-offs between the major options — integration cost, ongoing maintenance cost, vendor lock-in, long-term viability — and can recommend what fits your project. Getting this right at the start avoids painful and expensive migrations later. Getting it wrong means rebuilding infrastructure mid-project, usually at the worst possible moment.

The point

If you scan back over the list above, you'll notice something: not all of these are technical. Communication, budget management, monetization strategy — those are business judgment problems. The developer you hire is going to make decisions in every one of these areas, whether or not they're equipped to. Whether they're equipped to is one of the things you're actually evaluating when you hire them.

The clearer you are about what you're building, and the more honestly you've thought about everything the project involves, the better positioned you are to recognize a freelancer who can steward all of it — and to spot one who can only handle a slice.

The next post in the series gets into how to actually do that recognition, starting with how to read a freelancer's profile and what to listen for when you're talking to 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.