AI Engineering
We build iOS and Android apps with the model inside them — on-device where latency, privacy and cost demand it, in the cloud where quality does. Engineered for weak networks, review queues and per-user unit economics.
AI app development is the building of mobile applications where a model runs as part of the product — on the phone's own neural engine, on your servers, or split across both — and where the app still behaves sensibly on a train through Thane with two bars of signal. ZenMagix is an AI app development company in Mumbai that builds these for founders and product teams shipping to real users on real devices. We came to this from blockchain: wallet apps, exchange clients and settlement systems where a phone held signing keys, went offline mid-transaction, and had to reconcile state correctly when it came back. That is the same problem class as AI mobile app development, dressed differently. A phone is not a browser tab. It has a battery, a thermal ceiling, an OS that suspends your process without asking, a store reviewer who decides whether you ship at all, and a user who did not agree to pay for inference. Those five constraints — not model choice — decide whether an AI feature survives contact with production.
Run it on the device when the input is private, the call is frequent, or the network is unreliable. Run it in the cloud when quality genuinely needs a frontier model. Most apps need both, and the split has to be decided before the architecture, not after.
On-device AI means the model executes on the phone's NPU — Core ML and the Apple Foundation Models framework on iOS, LiteRT, ML Kit and Gemini Nano through Android's AICore, or ONNX Runtime and ExecuTorch when you need one runtime across both. What you get is 20-80ms latency instead of 400ms plus round trip, zero marginal cost per inference, and data that never leaves the handset, which changes what your privacy policy and your DPDP posture have to say. What you give up is real: a 2-4B parameter quantised model is not GPT-class, app binaries grow by 200MB to 2GB unless you download weights on first run, cold-start model load can take seconds, and sustained inference heats the device until iOS or Android throttles you.
Battery is measurable, not theoretical — continuous NPU work draws meaningfully more than idle, and users notice on day two, not day one. The practical answer for most products is a router: classification, embedding, redaction, wake-word, OCR, image tagging and short rewrites go local; long-form generation, complex reasoning and anything needing fresh knowledge goes to a hosted API. Device capability decides the path at runtime, because a 2019 Android handset on 3GB of RAM cannot run what an iPhone 16 Pro runs, and India's install base is mostly the former.
On a mobile network, requests do not fail cleanly — they hang, half-complete, and resolve twenty seconds after the OS has already suspended your process. An AI app has to treat every generation as a durable job with an ID, not as an in-flight promise.
This is where our wallet background shows. A signed transaction submitted over a dying connection has exactly the same failure profile as a paid generation request: you do not know whether the server received it, you cannot safely retry without an idempotency key, and the user will kill the app before you find out. So every generation gets a client-generated request ID, is queued locally, and is reconciled against the server on next launch — if it completed, you fetch the result you already paid for instead of billing twice.
Streaming into a mobile UI needs its own discipline: SSE over the OS's own networking stack, batched renders rather than a state update per token because that pegs the JS thread and cooks the battery, and a stream that persists server-side so backgrounding the app for a phone call does not destroy forty seconds of output. iOS gives you roughly thirty seconds of background execution before suspension; anything longer needs a push notification to bring the user back to a finished result.
Local state lives in SQLite or WatermelonDB with an explicit sync protocol — last-write-wins is a data-loss bug waiting for a user with two devices, so conflicts get resolved on a policy you choose, per field. And offline is a designed mode with its own UI: the on-device model answers, the cloud features are visibly unavailable rather than silently broken, and queued work shows as queued.
Both stores now have explicit rules for apps that generate content, and a rejection costs you a release cycle. Most AI rejections come from three things: missing content filtering, a wrong age rating, and undisclosed data sharing with a model provider.
Apple's guidelines require apps with user-generated or model-generated content to have filtering, a reporting mechanism, and the ability to block abusive users, and apps that can produce mature or unpredictable output are pushed to a 17+ or equivalent age rating. Apple has also tightened disclosure where personal data is shared with third-party AI providers — if your app sends user content to OpenAI, Anthropic or Google, that belongs in your privacy manifest and consent flow, not in a footnote.
Google Play's Generative AI policy runs parallel: you declare the AI functionality in the Play Console, ship in-app reporting for offensive output, and are expected to have red-teamed the thing before submission. Both stores treat an unfiltered pass-through to a raw model API as a defect. We handle this as an engineering deliverable rather than a paperwork scramble at the end — moderation on both input and output, a report button wired to something a human actually reads, age rating chosen deliberately, privacy manifests and data-safety forms filled to match what the code genuinely does, and reviewer notes with a test account and a script that demonstrates the safeguards working.
Where a feature is high-risk, we ship it behind a remote flag so it can be disabled without a resubmission. This is also adversarial thinking carried over from smart contract work: assume someone will try to make your app generate something that gets it pulled, and build for that person first.
Because in a consumer app there is no per-seat licence covering your inference bill, and unit economics decide whether the product lives. We build the cost model in the first sprint, alongside the app.
A B2B web tool charges per seat and can absorb a few dollars of tokens a month. A consumer mobile app cannot. If a free user costs you 40 rupees a month in inference and converts at two percent, the arithmetic fails and no amount of growth fixes it. So we instrument cost per active user from the first build, then engineer it down: on-device inference for anything that does not need a frontier model, aggressive prompt caching on stable system context, small-model routing for classification and extraction, semantic caching on repeated queries, and hard per-user ceilings with a real UI path when a limit is hit.
The number goes on a dashboard next to retention, in rupees or dollars, because that is the pair that decides pricing. The rest is engineering discipline we did not learn from AI. Exchange and wallet systems taught us idempotency, replay protection, offline-tolerant state reconciliation and auditability under people actively trying to break things — the exact properties an AI app needs once it has paying users on bad networks. We build in React Native when one team and one codebase is the right trade, and go native Swift or Kotlin when the app lives or dies on NPU access, background processing or camera pipeline performance.
We will tell you which in the first call. We also say no: if a feature is a regex, a lookup table or a well-tuned search index, we will build that instead and it will be faster, cheaper and more reliable than a model. Code, prompts, model weights and evals are yours from day one.
What you get
A written decision for every AI surface: on-device or cloud, which model, expected latency, battery and thermal impact, device capability tiers, and projected cost per active user at your target scale. Agreed before code.
The shipped app — React Native or native as the architecture demands — with AI surfaces, authentication, analytics, crash reporting, CI/CD, signed builds and over-the-air update capability where the platform allows it.
Local database, queue and sync protocol with idempotent generation requests, resumable streams, per-field conflict resolution and a designed offline mode where the on-device model keeps the core experience working.
Input and output moderation, in-app reporting and blocking, privacy manifests, Play Console AI declarations, age rating rationale, and reviewer notes with a test account demonstrating each safeguard.
Per-user spend ceilings, model routing, caching, dashboards for cost per active user, time-to-first-token and on-device fallback rate, plus architecture docs and working sessions so your team can ship the next release without us.
How we work
One to two weeks defining which screens need a model, what each costs per use, and which of your users' actual devices can run it locally. Surfaces a lookup or a search index handles better get built that way.
One AI surface end to end on a real device matrix including mid-range Android. Latency, battery draw, thermal behaviour and cost per session stop being estimates and become measured numbers.
Build the offline queue and sync, resumable streaming, moderation and reporting, spend ceilings and capability fallbacks. Assemble the submission pack and red-team the AI surfaces before they reach a reviewer.
Staged rollout behind remote flags, then weekly review of crash-free rate, cost per active user, on-device fallback rate and where users abandon mid-generation. Routing, prompts and quantisation get tuned against real usage.
Every phase ends at a decision point you can stop at — see how that works across fixed-scope projects, embedded pods and retainers.
Stack
Questions
Usually both. On-device suits frequent, private, low-complexity work — classification, embeddings, OCR, short rewrites — because it costs nothing per call and works offline. Cloud models handle synthesis, long context and current knowledge. We route at runtime based on device capability, since a mid-range Android handset cannot run what a recent iPhone can.
They will if the safeguards are missing. Both stores require content filtering, in-app reporting for offensive output, an appropriate age rating, and accurate disclosure when user data goes to a third-party model provider. Apps that pass raw model output straight to users without moderation are the common rejection. We build those safeguards in and prepare the reviewer notes.
React Native for most products: one codebase, one team, and native modules where you need them. We go native when the app depends on deep NPU access, sustained background processing, or a high-performance camera or audio pipeline. The decision is made in the first week with the reasoning written down, not assumed by default.
Sustained inference does — continuous NPU work draws real power and heats the device until the OS throttles it. Occasional short inferences are cheap. We measure draw and thermal behaviour on actual mid-range hardware during the first slice, set duty-cycle limits, and move anything long-running to the cloud or to a moment the phone is charging.
Consumer apps have no per-seat pricing to absorb it, so we track cost per active user from the first build. It comes down through on-device inference for cheap tasks, prompt caching, routing to small models, semantic caching on repeat queries, and hard per-user ceilings with a proper UI response rather than a surprise bill.
A focused app with two or three AI surfaces, offline support, auth and store submission typically ships in twelve to eighteen weeks across iOS and Android. Adding an AI feature to an existing app is usually five to eight. Both include the offline queue, cost controls and safety layer, which are not optional here.
Questions about cost, timelines, IP ownership and data residency are answered on the general FAQ, and how this practice came out of blockchain infrastructure explains why we build the way we do.
Related
A paid diagnostic that tells you what is worth building and what is not.
The pipelines and quality layer every AI project stalls on.
A working AI product in weeks, scoped to prove one thing to investors or users.
See also: build the browser side of the same product with AI web development · run the multi-step work behind the app with AI agent development · get a first version onto real phones faster with AI MVP development
Tell us what you are trying to build. We will tell you honestly whether we are the right team for it, and what it would realistically take.
