Mobile apps where AI is the product

This is the architectural decision that everything else follows from, and it has four inputs: connectivity, latency, privacy and cost.

Connectivity first. If the app is used where signal is unreliable — warehouses, basements, rural sites, aircraft, underground — then anything on the critical path must work offline, full stop. We have rebuilt several apps whose core AI feature was cloud-only and therefore useless to the field teams they were built for.

Latency second. Anything in a real-time loop — camera overlays, live captioning, interactive voice — cannot tolerate a network round trip. Below roughly 100 milliseconds an interaction feels like part of the interface; above 300 it feels like waiting for something else. Only on-device inference reaches the first number reliably.

Privacy third. Data that never leaves the device is data you do not have to secure in transit, store compliantly, or declare in a data-safety form. For health, financial and biometric features this frequently converts a difficult enterprise or app-store privacy review into a straightforward one, and it is worth architecting for on that basis alone.

Cost last, but it compounds. A feature invoked twenty times per session by a hundred thousand users is a serious cloud bill; the same model quantised onto the device costs nothing per call. We have moved features on-device purely on unit economics after launch, and it is cheaper to plan for it than to retrofit.

In practice most apps end up hybrid: a small quantised model handles the frequent, fast, private path, and a frontier cloud model handles the heavy reasoning, with graceful degradation when offline rather than a blocked screen.

Model size is only part of the story. Sustained inference generates heat, and once a phone thermally throttles, everything slows — including the rest of your app. An AI feature that benchmarks well in a thirty-second demo and degrades over a ten-minute session is a common and avoidable failure.

We profile on the devices users actually own, which for most Indian and global consumer apps means mid-range Android hardware, not the latest flagship. Quantising to 8-bit or 4-bit typically cuts model size several-fold with accuracy loss that is measurable but usually immaterial for the task; we measure it rather than assume it.

Scheduling matters as much as model size. Running inference on every camera frame is almost never necessary — sampling at a rate matched to how fast the scene actually changes, and pausing entirely when the app is backgrounded or the device is hot, keeps the experience smooth and the battery graph unremarkable. Users notice battery drain faster than they notice model accuracy.

Where the neural engine is available we target it rather than the CPU, and we always ship a graceful path for older devices: a smaller model, a lower frame rate, or a cloud fallback, chosen at runtime from device capability rather than excluding those users from the feature.

Mobile AI interfaces have less room for explanation than desktop ones, which makes designing for uncertainty harder and more important. The patterns that work are consistent across the products we have built.

Show confidence without showing numbers. A detection the model is unsure about should look different — softer, dashed, marked "check this" — rather than presented identically to a confident one. Users calibrate their trust remarkably well when the interface is honest about uncertainty, and they lose it entirely when it is not.

Make correction cheap and make it count. Tap to fix, swipe to reject, hold to re-run. Every correction is both a better immediate result and a labelled example, and users are far more tolerant of an imperfect model that is easy to correct than a slightly better one that is not.

Never block on the model. If inference is slow or fails, the app continues with the manual path rather than presenting a spinner or an error wall. This is especially true offline: the correct behaviour is to capture now, process later, and tell the user clearly that is what is happening.

Set expectations in the first session. A brief, specific statement of what the feature does well and where it needs checking earns far more trust than a claim of intelligence — and it substantially reduces one-star reviews that begin "it doesn’t always work".

Both stores have tightened their handling of AI features, and rejections are usually procedural rather than substantive — which means they are avoidable with preparation.

Apple expects clarity on what the feature does, whether user data leaves the device, and what content moderation exists if the app can generate open-ended text or images. Apps with generative capability need age ratings that reflect it and a plausible mechanism for handling harmful output. Privacy manifests must accurately declare data collection and any third-party SDKs, including inference providers.

Google Play requires a Data Safety declaration that matches actual behaviour, and its generative-AI policy requires in-app reporting for offensive output plus documented testing of your safeguards. Declaring "no data collected" while calling a cloud model with user text is the most common cause of rejection we see, and it delays launches by weeks.

We prepare the compliance pack alongside the build rather than at submission: privacy manifest, data-safety mapping, moderation description, and reviewer notes explaining the AI features with a test account and a walkthrough. Submissions prepared this way generally pass first time, and when a rejection does arrive it is answerable in a day because the evidence already exists.

We default to React Native or Flutter with native modules where performance demands them, and that default holds for most AI apps. One product team, one codebase, both stores, and shared business logic — with the AI-heavy paths (camera pipeline, audio capture, on-device inference) dropping to Swift and Kotlin where the difference is real.

We go fully native when the app is essentially a real-time media pipeline — continuous computer vision with tight frame budgets, complex audio processing, or heavy reliance on platform-specific ML features shortly after release. In those cases the bridging overhead and the lag in cross-platform support for new platform APIs outweigh the shared-codebase benefit.

What we do not do is start native "for performance" without a measured reason. The performance-critical portion of an AI app is usually a small, well-defined part of it, and writing the other 85% twice is a permanent tax on every feature you ship afterwards.