AI features in mobile apps

Calling a model is the easy part and takes an afternoon. The work is everything around it: what the user sees during the wait, what happens when the answer is wrong, and what it costs you when somebody uses it a hundred times a day.

The hard parts of an AI feature are latency, cost that scales with usage, and behaviour when the model is wrong or unavailable. A demo ignores all three. A shipped product cannot.

What we have actually shipped

Omni AI is our own product: an assistant that puts chat, writing and image generation from current models into one app. Luna Story generates bedtime stories for children, which is a much less forgiving problem than it sounds, because the output goes to a child at the end of the day and there is no acceptable failure mode where it produces something strange.

Both are ours, both are live, and both cost us money every time somebody uses them. That is a different kind of knowledge from having integrated an API once for a client.

The four problems worth planning for

Latency, and what fills it

A model that takes six seconds is not a performance bug you can optimise away. It is a design constraint. The question is what the interface does during those seconds: streaming the answer as it arrives, showing genuine progress rather than a spinner, and letting the user do something else without losing their place. Products that get this right feel fast at the same speed products that get it wrong feel broken.

Cost that scales with use

Almost every other feature in an app costs the same whether one person or a million use it. AI features do not. A small number of heavy users can cost more than everyone else combined, which has direct consequences for pricing, for whether the feature sits behind a subscription, and for how aggressively you cache.

• Route the common case to a cheaper, faster model and escalate only when needed.
• Cache aggressively. A surprising share of requests in a real product are near-duplicates.
• Set limits before launch, not after the first month's bill.
• Instrument cost per user from day one, so pricing is a decision rather than a discovery.

Being wrong, gracefully

Models produce confident, plausible, incorrect output. Any product where that matters needs to decide in advance what it does about it: showing sources, letting the user correct and retry, keeping a human in the loop for consequential actions, or constraining the output enough that a wrong answer is still a safe one. Deciding this at design time is considerably cheaper than deciding it after a complaint.

Being unavailable

Providers have outages, rate limits and deprecations. An app whose main screen is unusable when one company has a bad afternoon is a fragile app. Fallback to a second provider, degrade to a simpler experience, and never let a failed request leave the user staring at a dead screen with no explanation.

Privacy, and telling users the truth

If user content leaves the device, that has to be stated plainly in the app and declared accurately in both stores. Apple's privacy labels and Google's data safety form are checked against actual behaviour, and a mismatch is a rejection at best. Beyond compliance, users are increasingly direct in asking where their content goes, and a clear answer is a feature rather than a legal chore.

When we will tell you not to add AI

When it is decoration. A feature added because the category expects one, with no clear job, tends to produce a button people press once. It still costs money on every press, still needs failure handling, and still has to be explained to app review.

The test we apply is whether you can name the specific thing a user is trying to do and say honestly that a model does it better than a well-designed form. Where the answer is no, the honest recommendation is to build the form.

Design the failure paths before the happy path. A feature that works beautifully when the model cooperates and collapses when it does not is not finished, it is demonstrated.

How we work

1. Discovery, focused on the specific job the feature does and what a wrong answer costs the user.
2. A narrow prototype against real prompts and real data, to find the latency and quality reality early.
3. Design of the waiting, correcting and failing states alongside the working one.
4. Build, with cost and latency instrumented from the first week rather than added later.
5. Launch with limits and fallbacks in place, then iterate on what people actually ask for.