Mobile apps didn't get an AI feature. They got a new backend.

Look at the mobile apps that shipped AI in the last two years and the visible change is small. A sparkle icon appears in the toolbar. A sheet slides up. You type at the app instead of tapping it.

Underneath, something much larger happened, and most of it never showed up in the design review.

Nearly every article on this subject frames the change as new capability. Apps can see now, apps can talk now, apps can anticipate now. That framing is true and it's also the least interesting thing that happened.

The change that actually reshapes how you build is about ownership. For about fifteen years a mobile app was a client to a backend the team owned end to end. That backend was fast, deterministic, effectively free per call, and it shipped on the team's schedule. Nearly every pattern we take for granted on mobile is downstream of those four properties.

Then the backend started guessing, and it stopped being yours. All four properties are gone, and here's what each one cost.

Pre-AI assumptionWhat replaced itWhat it costs you

The backend ships when you ship

The model is a third party's product and changes on its schedule

Behavior moves without a code change, while your binary waits in review

Same input, same output

Probabilistic output, occasionally well formed and wrong

Loading, success, and error no longer cover the response space

The camera is a discrete input

The camera is a continuously sampled sensor

Battery, thermal, and privacy become product constraints

An engaged user is free

Every interaction carries a token cost

Retries, autocomplete, and background refresh become billing decisions

Before AI, the backend shipped on your schedule

The most under-discussed change is that half your system now updates without you. Pre-AI, both halves were yours. The client was frozen between releases, but that was survivable because you controlled the other end. Version the API, keep old clients working, move on.

Now the model behind the feature is somebody else's product. It gets retuned, deprecated, replaced. Behavior can move without a line of your code changing, and your binary is sitting in review for days when it does.

This isn't a fringe concern. Firebase's own guidance for generative AI apps leads with it: model availability changes frequently, newer models arrive and older ones get shut down, and not all of your users will update the app to reach the model you need them on. That page is worth reading for its banner alone, which at the time of writing announces two shutdowns in the coming months. Deprecation isn't a hypothetical you plan for. It's a notice you receive.

The model ID belongs on your server, not in the binary

Anything that determines model behavior should be a value you can change without shipping. That means the model identifier, the prompt, the generation parameters, and the schema you expect back all live on a server you control.

If they're compiled into the app, your only remedy for a behavior change is a release, and a release isn't a remedy at hour two of an incident. Every mobile platform already has the mechanism, whether that's remote config, a feature flag service, or your own endpoint. The mechanism is documented. The decision usually isn't, which is why it tends to get made by default.

There's a second half, and it's the one teams skip. Log the model version alongside the response.

Without it, the oldest question in production has no answer. "Did our deploy break this" is now "did our deploy break this, or did theirs?" A postmortem that can't distinguish those two is a guess about a system that guesses, and it looks identical to a postmortem on a system that's fine.

Mobile UI has three states and AI output needs a fourth

The standard vocabulary doesn't cover what a model returns. Every mobile design system has loading, success, and error, and that vocabulary comes from a deterministic backend where a response is either the right answer or a failure you can name.

Model output has a fourth state: well formed, confidently phrased, and wrong.

There's no spinner for that. The default is worse than nothing, because unlabeled output renders in the same typography as everything else, which quietly tells the user that a guess carries the same weight as a value that came out of a database.

Consider what happens when an app has to identify a physical object from a camera feed. The interesting engineering isn't recognition. It's designing the moment when the app is roughly sure. A barcode scanner either reads the code or it doesn't. There is no "probably this one," and the whole interface can be built on that fact.

What works is making uncertainty a first-class state: show the guess as a guess, keep the second-best answer one tap away, and make correcting the app cheaper than accepting it. That isn't a house opinion. Apple's machine learning interface guidelines treat mistakes, confidence, multiple options, and corrections as design surfaces in their own right, and warn that leaning on corrections to compensate for weak results erodes trust rather than repairing it.

Confidence has to be visible in the interface, not just present in the logs.

The camera stopped being an input and became a sensor

The same permission prompt now covers a completely different thing. Pre-AI, camera access meant let me take a picture. The user granted it, a frame was captured, a file was uploaded. Discrete, legible, over in a second.

Continuous on-device inference keeps the camera open for as long as the screen is.

Three things change at once. Battery and thermal behavior stop being QA notes and become product constraints, because a feature that warms the phone gets uninstalled regardless of how good it is. The privacy question moves from "what did I upload" to "what is being processed, and where." And the answer to the second one has to be designed into the flow, not disclosed on a settings screen nobody opens.

The working default is that frames don't leave the device unless the user asked for something that requires it. Not because a policy says so, but because it's the only version of the feature you can explain to a user in one sentence.

Every interaction has a unit cost now

Engagement stopped being free, and most mobile product instincts predate that. The marginal cost of an engaged user used to be near zero, and that single fact shaped a decade of thinking: free tiers, infinite scroll, engagement as an unqualified good.

Inference is priced per call. A user who loves your AI feature now costs you money in direct proportion to how much they love it.

This lands hardest in the places that don't look like billing decisions. Retry logic that was free is now a multiplier on a bad network. Autocomplete that fires on every keystroke is a per-keystroke charge. A background refresh that seemed considerate is a recurring bill for a screen nobody opened.

Pre-AI those were performance concerns you could defer. Now they're line items, which means a session needs a budget, a cap, and a defined behavior when the cap is reached that isn't a crash or a silent nothing.

AI can build the first version of a mobile app, not the last twenty percent

Yes, a model can build you a working mobile app, and no, that isn't the part that was ever hard. This is the question underneath most of the anxiety about AI and mobile development, so it's worth answering plainly rather than leaving it implied.

None of the old mobile constraints were relaxed. The network still drops mid-request. The store still reviews, and a phased rollout still takes days. Permissions still get denied and never revisited. The device in someone's pocket is still three years old.

AI added a slow, metered, non-deterministic dependency on top of all of it, and then made the first working version easy enough to build that none of those constraints come up until the feature is already in a demo. The generated app and the shipped app are separated by exactly the work that doesn't demo.

That's the same gap we keep coming back to, and it's the reason we draw a line between AI-native and AI-enabled software. Getting an AI feature working on mobile is now the fast part. Getting it to hold up on an old phone, on a bad connection, at a cost you can defend, against a model that may behave differently next month, is the actual work.

The through-line

The app looks about the same. Underneath, mobile development traded a backend it owned for one it rents, and almost every hard decision now lives inside that trade.

Capability was the headline. Ownership was the change.

The sparkle icon was the easy part.

Written by Synthetixis, an AI-native product studio. More on what most AI software gets wrong.