How to add AI features to an iPhone and Android app — a guide for product people

Every AI feature runs somewhere, and the somewhere is a product decision with three consequences: cost, privacy, and capability.

On-device models — both platforms now expose local models to apps (Apple's Core ML lineage on iOS, with the platforms increasingly offering built-in foundation models to developers). Marginal cost per request: zero. Works offline. The user's data never leaves the phone — a privacy sentence you get to put in your App Store listing. The trade: local models are smaller — brilliant for classification, tagging, short summaries; not the tool for long-form reasoning.

Cloud model APIs — the most capable models, one HTTPS call away, metered per token. Capability is maximal; the meter is the product decision. A labelled illustration with stated assumptions: at Claude's published API prices (Sonnet 5: $2 per million input tokens, $10 per million output, 30 Aug 2026 — check current), a summarise-my-notes feature processing ~50k tokens in and ~2k out per user per month costs roughly $0.12 per active user per month; a chat-heavy assistant at 20× that usage, ~$2.40. Neither number is your number — the point is the shape: cloud AI features are a per-user COGS line, and they belong in the same spreadsheet as your subscription price. Free tiers with unmetered cloud AI are how founders discover unit economics the hard way; the monetization guide is the companion read.

The default that falls out: classification, tagging and short summaries on-device (free, private, offline); the marquee reasoning feature on a cloud API, gated to paid tiers or fair-use caps. Hybrid is not a compromise — it is the correct architecture for most products.

The on-device option now has a name on each platform, and a product manager should know both, because the spec is written once and built twice.

On iPhone: the Foundation Models framework. Apple’s framework gives an app access to the on-device language model at the core of Apple Intelligence. It runs on the phone; for requests that need a larger model, Apple describes Private Cloud Compute as the extension. Two features matter to a spec. The model can return structured output — the app declares the shape it wants (a title, three bullets, a date) and gets typed data back, not free text to parse — which is exactly the “output contract” below, enforced by the platform. And the model can call tools the app defines — look up the user’s own notes, read a calendar — so the assistant pattern works on the user’s data without that data leaving the device. It requires a device and region with Apple Intelligence enabled, so the spec needs a fallback for phones without it.

On Android: Gemini Nano through ML Kit. Google’s on-device model runs through the ML Kit GenAI APIs on the AICore system component. Google’s documentation: “GenAI APIs run entirely on-device,” “Input, inference, and output data is processed locally,” and “Functionality remains the same without reliable internet connection.” The APIs are task-shaped — summarization, proofreading, rewriting, image description, speech recognition — plus a Prompt API for open prompts; the task-shaped ones suit the classification-and-short-summary jobs the previous section put on-device. Availability is per device, listed by Google, so the same fallback line applies.

The spec line that covers both. “Summaries and tags run on-device when the platform model is available (Apple Foundation Models on iPhone, Gemini Nano via ML Kit on Android); output is structured — title, three bullets, no invented names; when no on-device model is available, [the cloud route or the non-AI fallback].” One sentence, two native implementations. In a build tool that writes each feature once and renders it natively on both platforms — Modaal’s agent writes the Swift call to the Foundation Models framework and the Kotlin call to ML Kit from the same spec — the second platform is not a second AI project. How to build a cross-platform app with AI has the mechanism; the PRD prompt has where the line goes.

Here is the genuinely new PM skill of 2026: specifying acceptance for features that don't return the same answer twice. A login screen either works or doesn't; a summary is only better or worse. The old spec vocabulary fails, and hand-waving ("output should be high quality") fails more expensively. What works — and slots straight into a spec-driven workflow — is bounding the feature on four sides:

Inputs, bounded. What the model sees — which fields, how much history, what is deliberately excluded (the privacy line lives here, written by you, not discovered by users).

Output contract. Not "a good summary" but "3 bullets, ≤20 words each, never invents names not present in the source." Contracts are testable; vibes are not.

Failure behaviour. The model will sometimes be wrong, slow, or unavailable. Spec what the user sees then: the graceful empty state, the retry, the non-AI fallback. Every beloved AI feature has an unglamorous fallback behind it.

The escape hatch. How the user corrects, regenerates, or ignores the AI. Features that let users overrule the model earn trust; features that insist are uninstalled.

Write those four and hand them to whoever builds — an agent included. This is exactly the prompt-is-a-wish, spec-is-a-decision argument applied to the model inside your product.

Now the practical loop, and yes, the disclosure applies. In Modaal, the two meanings of AI compose: you describe the AI feature in a spec — patterns, contracts, fallbacks, exactly as above — and your build agent writes the native Swift or Kotlin that implements it: the API calls, the on-device model integration, the caching, the fallback states. The feature spec you reviewed is the implementation brief; unlimited prompts mean the inevitable tuning rounds (AI features need more iteration than deterministic ones — that is normal, budget for it) cost nothing extra.

Two build-side notes that save real money: cache aggressively — the same summary requested twice should hit your cache, not the meter; and log what the feature actually gets used for in the first month — AI features are famous for being used differently than specced, and the second version informed by usage beats the first version informed by hope. If that first month teaches you the feature is the product — congratulations, that's an idea, the "things AI just made possible" kind.