Mobile AI runs on two tracks at once: the IDE assistants that changed daily Android and iOS work — Gemini in Android Studio, Xcode Intelligence — and the on-device models that let features run private, offline, and free. This module covers both, plus the release engineering in between and the fallback discipline that makes on-device shippable.
Vikram, senior Android engineer at a note-taking app with 2M installs, ships the quarter's flagship: on-device note summarization via ML Kit GenAI on Gemini Nano. Private by design, zero inference cost. The demo on his Pixel 9 is flawless.
Play Console lights up. One-star reviews from mid-range devices: "summarize button does nothing." AICore isn't available on most of the fleet — Gemini Nano's device list is flagship-skewed, and his feature checked nothing.
68% of his install base — solidly mid-range, the Indian market reality — has no on-device model. The feature silently no-ops for two of every three users.
He pauses the staged rollout at 10% — the release gate working exactly as designed — and rebuilds the feature around a capability ladder: feature-detect AICore, fall back to a cloud path through Firebase AI Logic with App Check, degrade to extractive summaries offline.
Every device gets a summarize button; capable devices get it private and free. Crash-free stays at 99.8%, reviews recover. The postmortem's one line: "on-device is a capability, not a platform."
Vikram's paused rollout is the mobile-AI lesson in one incident: the on-device model landscape is genuinely revolutionary — private, offline, zero marginal cost — and fragmented by hardware, which makes capability detection and graceful degradation the first-class engineering problem, not an afterthought. Mobile makes every promise conditional on the device in the user's hand. This module covers the full mobile-AI stack in the order you'll live it: the IDE assistants that changed the daily loop, preview-driven verification, AI-assisted release engineering, the on-device/cloud decision, the platform APIs on each side, cross-platform SDKs, and the restricted-environment variants services engineers need.
Mobile's AI story starts inside the IDEs, because both vendors built assistance into the first-party tools — no third-party subscription required, which matters enormously for sanctioned-tool lists.
Gemini in Android Studio matured into a genuine daily instrument: Agent Mode takes multi-file feature work — implement, wire, build, read the errors, iterate — under your review; Journeys lets you describe user flows in natural language and watch Gemini drive the real app on an emulator as exploratory testing (exploration, not release gating — M5's deterministic-suite rule holds); App Quality Insights brings Gemini analysis to crashes and ANRs in-IDE; and LLM flexibility — the quietly radical one — lets you point the assistant at your own model, including a local one, which turns the IDE into a zero-egress AI tool on locked-down client accounts. Compose-specific assists (preview generation, recomposition explanations) round out the daily loop.
Xcode 26 Intelligence took the multi-model road: ChatGPT by default, Claude pluggable, and — the restricted-environment key — local models via LM Studio. SwiftUI generation, playground iteration, doc and test generation, and fix-error loops run against whichever model policy allows. The multi-model design means "which model may see this code" becomes a per-project setting rather than a tooling ultimatum.
The team-rules discipline transfers unchanged from this track's web modules: agent output enters review like any AI PR — provenance disclosed, M1's checklist applied, the build/test/lint harness as the deterministic gate. The IDE being first-party changes the sanctioning conversation, not the verification one.
On client accounts that sanction nothing cloud-based, the local-model paths in both IDEs are the unlock: Android Studio's LLM flexibility and Xcode-via-LM-Studio give you real assistance with zero code egress — below frontier quality, but sanctioned-by-construction. Pair either with the M2 instruction-file discipline; local models need the conditioning even more.
Mobile's visual-verification loop runs through previews, and AI generation made exhaustive previews nearly free. The pattern — mobile's twin of M2's Storybook discipline: for every screen, generate the full preview matrix — loading, error, empty, populated; dark mode; RTL; large dynamic type; small-screen — so that "does it hold up in every state?" is one click, not a manual QA session. Android Studio generates Compose previews directly; Xcode Intelligence does the same for SwiftUI previews. The matrix catches what mobile actually breaks: the German string that wraps into a third line, the RTL layout that never got mirrored, the dynamic-type setting that clips the CTA. Generated previews are also the reviewer's gift — a PR whose screens arrive with a full state matrix reviews in minutes, not device-sessions.
Mobile's release train — store metadata, staged rollouts, crash gates — is summarization-and-drafting work over structured artifacts, which is exactly the AI-safe shape:
The genuinely new mobile-AI capability is inference that never leaves the device. The decision framework comes first, because "should this be on-device?" is a product-architecture call:
| Dimension | On-device (Nano / Foundation Models / built-in web AI) | Cloud (Firebase AI Logic / your BFF) |
|---|---|---|
| Privacy | Data never leaves the device — a DPDP/compliance selling point | Data crosses the wire; consent and DPA territory |
| Cost | Zero marginal inference cost at any scale | Per-token, forever, scaling with success |
| Latency & offline | No round-trip; works in airplane mode | Network-bound; offline = broken |
| Capability | ~3B-class models: summarize, proofread, extract, classify | Frontier models: complex reasoning, long context, tools |
| Availability | Flagship-skewed device lists; the fleet decides | Every device with a connection |
The last row is Vikram's row, and it converts every on-device feature into a hybrid architecture — a capability ladder the app descends at runtime:
Capability check passes: AICore / Apple Intelligence / built-in model present and downloaded. Run locally — private, free, offline-capable. Instrument which rung served each request so you know your real fleet split.
No on-device support: route the same feature through Firebase AI Logic or your BFF — with App Check attestation, quotas, and consent handled. Same button, same UX contract, network required.
No model, no network: degrade to a non-generative approximation (extractive summary, cached result) or an honest, actionable empty state. Never a silent no-op.
Per platform:
unavailable path as a real experience.Never gate a feature on on-device availability — gate the execution path. The user was promised summarization, not a particular chip. If the button exists on flagships and silently no-ops elsewhere, you shipped Vikram's incident with your name on it. Feature-detect, route, degrade — and test the fallback path as a first-class citizen, because for most of your users it is the feature.
React Native and Flutter teams — half the mobile market, more in India — get the same capabilities through a maturing SDK layer: Firebase AI Logic (cloud Gemini from Flutter/RN/native clients without building your own backend — with App Check attestation, because a mobile client calling a model API is otherwise M7's stolen-endpoint problem in app form); Flutter AI Toolkit (prebuilt chat widgets — assemble, restyle on-system, M7's assembly discipline); and react-native-ai (on-device models with AI SDK-compatible APIs, so web streaming/tool patterns transfer — the Apple provider needs no model download). The M7 rules ride along unchanged: no keys in app binaries (extractable exactly like web bundles), attestation plus rate limits on whatever endpoint the app calls, sanitize rendered model output, authorization server-side. One more cross-platform duty from the research: behavioral parity — when the same feature ships on RN/Flutter and native, an agent-driven parity audit (feature × platform × state matrix generated from both codebases) catches the drift users report as "it works differently on my iPad."
For services engineers on NDA client accounts and DPDP-sensitive products, this module's pieces assemble into a coherent zero-egress stack — worth naming explicitly because it turns compliance from a blocker into an architecture: local models in both IDEs for daily assistance (Android Studio LLM flexibility, Xcode via LM Studio); on-device inference for product features (Nano, Foundation Models, Chrome built-in AI — user data never leaves the handset, a genuine DPDP Act 2023 selling point you can put in a proposal); and the M3 asset rules for anything design-side (client-tenant tools, redacted screenshots). App binaries and symbol files are client IP under the same "can I paste this?" tree as code — symbolicated crash dumps routinely contain user data in breadcrumbs; redact before any non-sanctioned model sees them.
The on-device privacy story is real but narrow: inference stays local. Analytics, crash reporting, and feedback events you attach to the feature still travel. A "fully private summarization" claim dies the day someone finds note excerpts in your crash breadcrumbs — audit the whole telemetry path before marketing writes the privacy copy.
This module's playbooks: pb-41 (Gemini in Android Studio as a Daily Instrument), pb-42 (Xcode Intelligence: Multi-Model SwiftUI Assistance), pb-43 (Preview-Driven UI Iteration), pb-44 (Mobile Crash and ANR Triage with IDE AI), pb-45 (Release-Engineering Copilot), pb-46 (Cross-Platform Parity Audit), and pb-52 (On-Device AI with Hybrid Fallback). Lab 15 is the mobile capstone: ship an on-device AI feature on your platform — ML Kit GenAI, Foundation Models @Generable, Flutter/RN, or Chrome built-in AI — with recorded evidence of the unsupported-device fallback path actually executing. The fallback evidence is the pass condition, because the fallback is the feature.
Mobile AI is two disciplines wearing one name: operating the first-party IDE assistants with the same verification you'd give any agent, and shipping on-device inference as a capability ladder — detect, prefer local, fall back to cloud, degrade gracefully — because the demo runs on your flagship, but the rollout runs on the fleet.