Don't hire an “AI agency” to build your AI iPhone app. Hire a mobile team that has already shipped the unglamorous parts of AI to real users: where the API keys live, who pays for each call, what the screen shows while the model thinks, and what happens when the answer is wrong. The model is the easy 20%. Those four things are the other 80%, and they are where AI apps actually fail.
That's the whole argument. The rest of this post is why we hold it, the strongest case against it, and five questions that tell you in one call whether an agency has done this before.
Most AI iPhone apps fail an audit nobody asked them to pass
In 2026, researchers at Wake Forest looked at 444 iOS apps with LLM features. In 282 of them, 64%, anyone who watched the app's network traffic could lift working AI credentials or backend access. No jailbreak, no reverse engineering. Ninety days after the researchers told the developers, only 78 had fixed it.
Every one of those apps had a demo that worked. That is the point. A stunning demo tells you a team can call a model. It tells you nothing about whether they'll leak your key, burn your margin or ship a feature users stop trusting after two wrong answers.
A great AI demo proves a team can call a model. It proves nothing about the other 80%.
What the “boring 80%” actually is
We've shipped AI features across several products, and the work that decided whether each one survived real users was never the prompt. It was one of these four.
Where the keys live
On MedLogsRx, our prescription-tracking app, every photo goes to OpenAI vision through a server-side function. The app never holds the key, so there is nothing to lift from the binary or the traffic. It costs a little latency and one more piece of infrastructure. It is not optional.
Who pays for each call
The same app gives free users three scans. Early on, a quota checked on the phone is a quota anyone can reset. So the quota moved to the server: each scan is checked before the model is called, a failed scan is refunded, and a per-user lock stops two uploads racing for the last free scan. None of that shows up in a demo. All of it shows up on your invoice.
What the screen shows while the model thinks
On IngrediCheck, a FungeeLLC product we build, a barcode scan streams one evolving result over Server-Sent Events. Product details appear first, then the verdict for each family member fills in as the analysis lands. A spinner that sits for several seconds reads as broken; a screen that fills in reads as fast, even when the total time is the same.
What happens when the answer is wrong
KIN, the voice-first family calendar we built for FungeeLLC, taught us this one. Turning speech into text was reliable within days. Turning “next Thursday after pickup” into one correct event took far longer, because a wrong entry a family trusts is worse than no entry at all. We wrote up how KIN splits capture and understanding; the short version is that the design work around a wrong answer is product work, not model work.
The strongest case against us
Here's the fair objection: if your product is the model, you need people who train models. A custom vision model for skin conditions, a fine-tuned speech model for a regional accent, a ranking model on your own data: a mobile team that “integrates LLMs” won't get you there, and pretending otherwise wastes your runway.
That's true, and for those products you should hire ML talent. But it describes a small minority of the AI apps founders bring us. Most need a capable hosted or on-device model wrapped in a product people trust. For CopyAgain, our clipboard app, the AI writing tools run entirely on Apple's Foundation Models framework and are offered only on devices that support them. The hard part wasn't the model; it was deciding what the app does on every other device.
Why we still hold it
Because the failures that kill AI apps after launch are almost never model failures. They're a leaked key, a cost curve nobody modelled, a slow screen users abandon, or a wrong answer with no recovery path. Those are mobile and backend engineering problems, and they are exactly what a team that has shipped consumer apps already knows how to handle.
There's a trade-off in our position too. A team like ours will usually pick the boring, proven model and spend the effort on the product around it. If your edge depends on squeezing the last few points of model quality, that instinct can hold you back, and you should say so up front.
Five questions that expose an AI agency in one call
Ask these on your first call. A team that has shipped AI to real users answers each one with a story; a team that hasn't answers with a slide.
- “Where will the model API keys live, and how do you stop someone from using them outside our app?” The right answer names a server-side proxy and authenticated calls, not “we'll obfuscate it.”
- “How do we cap and meter AI cost per user?” Listen for server-side quotas and what happens to a failed call.
- “What does the user see in the first two seconds?” Streaming, partial results or an honest progress state, not a spinner.
- “Show me what your app does when the model is wrong.” Ask for a real example from a shipped product.
- “What runs on-device, and why?” A considered answer about privacy, cost and device support beats a blanket “cloud” or “on-device.”
These sit alongside the governance questions every founder should ask a small studio, like who owns the IP and where the code lives, which we cover in how to de-risk hiring a boutique app agency.
FAQ
How do I choose an agency to build an AI-powered iPhone app?
Choose a mobile team that has shipped AI to real users, not one that only shows demos. Ask where the model keys will live, how cost per user is capped, what the screen shows while the model works, and what happens when the answer is wrong. Teams with real launches answer with specific stories from products you can download.
Should my AI app call OpenAI directly from the iPhone?
No. Calling a model provider straight from the app means the key travels with the app, and a 2026 study found 64% of LLM-powered iOS apps exposed credentials or backend access. Route calls through your own server, authenticate every request, and meter usage there. Eightinity's MedLogsRx sends prescription photos to OpenAI this way.
Do I need a machine learning team or a mobile app agency for an AI app?
Most AI apps need a mobile team, not ML researchers. If your product wraps a capable hosted or on-device model, the hard work is security, cost, latency and handling wrong answers. Hire ML specialists only when you must train or fine-tune your own model, such as custom medical imaging or speech for a specific accent.
What makes an AI feature feel fast on mobile?
Showing progress as it happens. Streaming partial results, such as product details first and analysis second, makes a multi-second model call feel quick, while a static spinner feels broken. IngrediCheck, built by Eightinity for FungeeLLC, streams scan results over Server-Sent Events so the screen fills in as data arrives.
Planning an AI feature for your app? Bring us the five questions above, and we'll answer them for your product →