Adding an AI feature to a mobile app has never been easier. You wire up a text field, POST the message to a model, and render the response. A weekend gets you a working demo.
The demo is not the hard part. The hard part is everything between "it works" and "it feels like it belongs on a phone." Mobile users have unforgiving expectations — instant feedback, smooth motion, graceful behavior on a flaky train-tunnel connection — and a naive LLM integration violates all three at once. It blocks while it waits, it freezes the UI while it parses, and it shows a spinning error when the network blinks.
Here's how I think about closing that gap, drawn from shipping a production AI app to both app stores.
The latency problem is a UX problem
A model call takes one to several seconds. On the web, people tolerate that. On mobile, a multi-second unexplained wait reads as "the app is broken" — users background it, pull-to-refresh, or tap the button again and fire a duplicate request.
You cannot make the model faster from the client. What you can do is make the wait feel like progress instead of a void:
- Stream tokens. Server-sent events with line-buffered delta parsing lets you render the response word by word. The perceived latency drops to the time-to-first-token, which is a fraction of the total. The user starts reading while the model is still writing.
- Acknowledge instantly. The moment the user sends, render their message and a typing indicator. The interface should never look idle.
- Reserve layout. Animate the incoming bubble into a space you've already reserved so the list doesn't jump when the first token lands.
Streaming is the single highest-leverage thing you can do for AI UX on mobile. It changes the feeling from "submit and wait" to "conversation."
Optimistic UI, reconciled later
The pattern that makes a chat feel native is the same one that makes any mobile write feel native: render optimistically, reconcile when the truth arrives.
When the user sends a message, assign it a temporary local ID and show it immediately with a pending status. Fire the request in the background. When the backend responds with the canonical record — a real UUID, a server timestamp, the assistant's reply — reconcile the temp ID with the real one and flip the status to synced.
This decouples the interface from the round-trip entirely. The user is never waiting on the network to see their own action. The same sync_status field drives subtle UI affordances: a faint clock icon while pending, nothing once synced, a retry affordance on failure.
Keep the model off the device
It is tempting to call the model provider directly from the app. Don't. Put your own backend in front of every AI request.
This is partly a security decision — which I've written about separately — but it's also a UX and velocity decision:
- You can change the model without an app release. Provider, version, prompt strategy, fallback chain — all server-side. When a better or cheaper model ships, your users get it the same day, not after a store review.
- You control the prompt and the safety layer. Guardrails belong on a server you operate, not in a binary anyone can decompile.
- You can meter and rate-limit where it's actually enforceable.
The client becomes a thin, typed API client. The intelligence lives behind your own endpoint. This boundary is what lets the product evolve quickly while the app stays stable.
Context assembly is the real personalization work
A generic chatbot is a commodity. What makes an AI feature feel like your app is context — and assembling that context well is mostly mobile engineering.
In practice this means building a small, deliberate context payload on-device before each request:
- The relevant entity state (in my case, the baby's profile and recent data).
- A bounded window of recent conversation — say the last fifteen messages, filtered for system and saved entries.
- A short rolling summary of older history, capped to a few hundred characters so the prompt stays cheap.
The discipline is in the bounds. It's easy to stuff everything into the prompt and watch latency and cost balloon. The craft is deciding what the model actually needs to be grounded in this user's situation, and ruthlessly truncating the rest. Pre-compute summaries on a schedule rather than assembling raw history at request time.
Design for offline, because mobile is offline sometimes
The defining trait of a mobile app — the thing that separates it from a website in a WebView — is that it keeps working without a connection. AI features make this harder, because the model genuinely requires the network. The answer is not to disable the feature offline; it's to degrade it honestly.
- Cached history is always available. Read past conversations straight from the local database. A user should always be able to scroll back through what the AI told them, signal or not.
- Compose offline, send on reconnect. Let users write; queue the send; flush it when connectivity actually returns (verify reachability, not just the network interface).
- Say what's happening. A small, calm "back online" banner beats a silent failure or a scary error modal.
The goal is that losing signal feels like a temporary, understood state — not a crash.
Make AI feel native, not embedded
The last mile is motion and convention. An AI response that pops in instantly with no animation feels like a web page. The same response easing in on the UI thread, with a subtle entrance and a settle, feels like part of the app.
Run those animations on the UI thread so a busy JS thread — parsing a stream, hydrating a store — can't make them stutter. Respect platform conventions: keyboard handling, safe areas, the back gesture, dynamic type. The AI should feel like a feature of the operating system you're building on, not a stowaway from the browser.
The throughline
Every one of these techniques is really the same idea applied in different places: never make the user wait on the network to see the result of their intent. Stream so they read while the model writes. Render optimistically so their actions are instant. Cache so history is always there. Proxy so the product can evolve without shipping a binary.
The model is the easy part. The UX around it is the engineering — and it's where a mobile-specialist actually earns the title.