For the last few years, adding AI to a mobile app meant calling a cloud API. Every summary, suggestion or rewrite cost money per request, needed a connection and sent user data to someone else's servers. For startups with freemium plans, those per-request costs climbed right alongside usage.

That model is shifting. Apple opened the on-device models behind Apple Intelligence to developers in June 2025 through its Foundation Models framework, which works offline and carries no cloud API costs, as TechCrunch reported. On Android, Google's ML Kit GenAI APIs run Gemini Nano on the device for summarization, proofreading, rewriting and image description. So when a founder briefs a mobile app development company in San Francisco on an AI feature today, the first question is where the model should run.

What Runs Well on the Phone

On-device models are small, so they suit short, focused tasks. Summarizing a note, rewriting a message in a different tone, proofreading, pulling structured fields out of text and describing an image all fit comfortably. Apple's launch examples show the range: Kahoot generating a personalized quiz from a student's notes, Automattic building the framework into its Day One journaling app, and AllTrails recommending hiking routes.

These tasks share three traits. They work on data the user already has on the phone, they need a quick answer, and they happen often enough that per-request cloud fees would add up. At AppVerticals, those traits are the first filter when we sort a proposed AI feature into on-device, cloud or both, and that sorting happens before anyone estimates the work.

What Still Belongs in the Cloud

Larger models still win on long documents, broad world knowledge, complex reasoning and image generation. Anything that needs fresh data from your backend, or answers that must match across a user's devices, belongs on the server too.

Device support is the other limit. On-device models run on recent, higher-end phones, so part of your audience won't have them. Every on-device feature needs a fallback, either a cloud model or a simpler version of the feature.

That split shapes the architecture. A mobile app development company San Francisco founders bring in for an AI product should design a routing layer that tries the on-device model first, falls back to the cloud when the device can't handle the task, and logs which path each request took. Those logs tell you later how much inference you're paying for and where.

Cost, Privacy and Speed

The business case rests on three changes:

•       Cost. On-device inference carries no per-request fee, which changes the unit economics of free tiers and high-frequency features.

•       Privacy. Text and images processed on the phone stay there. For apps handling journals, health notes or messages, that's a selling point and a lighter compliance load.

•       Speed. With no network round trip, results arrive fast enough to feel like part of the interface, even on a weak connection.

The trade-offs are real. Small models make more mistakes, results can differ between the on-device and cloud paths, and heavy use drains battery. Test on the older phones you support, write evaluation sets for each AI feature, and decide in advance what the app does when the model gets something wrong.

Design for Two Kinds of Users

Some users will get the on-device version and some won't. Decide feature by feature whether the experience should match exactly or degrade gracefully, and say so in the interface when a feature needs a newer phone. Keep prompts and output formats consistent across both paths, so switching from one model to the other doesn't change the look of the result.

Both platforms let the app check at runtime whether the model is available, still downloading or unsupported on that phone. Run that check early, and the interface can pick the right path before the user taps anything.

Start With One Feature

Pick an AI feature your users trigger many times a day, one whose cloud bill worries you, and move it on-device first. Measure speed, quality and cost against the cloud version for a few weeks before moving anything else. Log latency, user edits to the AI output and cloud spend for the current version first, so the on-device numbers have a baseline to beat.

Cloud models will keep handling the heavy work. On-device models give San Francisco startups a cheaper, faster and more private option for the small tasks users repeat all day, and the apps that combine both will feel quicker and cost less to run.