AI Integration for Mobile Apps
LLM and on-device ML features built into iOS and Flutter apps. I work with the OpenAI and Claude APIs, Core ML for on-device inference, and Firebase ML Kit — wired into a mobile product properly, behind your own backend, with the latency and cost behaviour worked out before it ships.
Most AI features fail in the same places: a spinner where there should be streaming, no answer for what happens when the model is slow or wrong, an API key shipped inside the app, and a bill nobody modelled. Those are mobile engineering problems more than they are AI problems, and they're the part I focus on.
What I build
- Conversational interfaces with token streaming, cancellation, and retry that don't block the UI
- Generation features that turn user input into structured, validated output rather than free text
- On-device inference with Core ML where latency or privacy rules out a network call
- A backend gateway (Laravel or Next.js) so model keys never reach the client and usage is rate-limited and logged
- Evaluation and guardrails — a test set for prompt changes, plus moderation and reporting paths for App Review
The rule I don't break
The model provider key lives on your server, never in the app bundle. Anything with a NEXT_PUBLIC_ prefix or compiled into an iOS binary is readable by anyone who wants it, and a leaked key is someone else's inference billed to you. Every integration I build goes through a backend you control.
Frequently Asked Questions
What does AI integration actually mean in a mobile app?
Usually one of three things: a conversational surface backed by an LLM, a generation feature that turns user input into structured output, or a classification or extraction step that used to need a server round trip and can now run on-device. The engineering work is rarely the model call — it's latency, streaming, failure states, and cost.
On-device or API?
On-device with Core ML when the task is narrow, latency matters, or the data shouldn't leave the phone. A hosted model via the OpenAI or Claude API when the task needs general reasoning or a large context. Most real apps use both, and the interesting decision is where the boundary sits.
How do you stop an LLM feature from costing unpredictably?
Cap tokens per request, choose the smallest model that passes your evals, cache aggressively on stable inputs, and put the call behind your own backend rather than shipping a key in the app. Never call a model provider directly from the client — the key is extractable, and you inherit whatever bill someone runs up.
What does App Review ask about AI features?
Expect questions about what generates the content, whether users can report objectionable output, and what leaves the device. Generated-content features need a moderation path and a reporting affordance. Your privacy manifest and data-collection disclosures have to match what your API calls actually send.
Adding AI to an existing app?
Tell me what you want it to do and I'll tell you whether it needs a model at all.