Guide · for product people shipping AI features, not demos

    How to add AI features to a mobile app in 2026 — a guide for product people

    Two different things hide inside "AI in mobile apps": building your app WITH AI (an agent writes the code — that story is our whole site), and building AI INTO your app — features your users touch: chat, summaries, smart search, photo understanding. This guide is the second thing, and it treats AI features as what they are: product decisions with a cost meter attached, best made the way PMs make decisions — specified, bounded, and priced per user before a line is built.

    Start with the question that kills most AI-feature roadmaps politely: what does the AI actually do for the user on a Tuesday? "Our app has AI" is 2023's sentence; users stopped rewarding it. What they reward is a job done better — and the jobs AI reliably does in mobile apps sort into four patterns:

    Understand text — summarise the meeting note, extract the date from the email, answer questions about the user's own content. Understand images — what's in this photo, read this receipt, tag this collection. Generate on demand — the reply draft, the workout plan, the caption. Converse — the assistant that knows the app's data and does multi-step jobs. Almost every good AI feature is one of these four wearing your product's clothes; if a proposed feature isn't, ask twice whether it's a feature or a demo.

    The decision PMs skip: on-device or cloud — and what each costs

    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.

    How to spec a feature that isn't deterministic

    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.

    Building it: where the two meanings of "AI app" meet

    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.

    Frequently asked questions

    Pick the job from the four proven patterns (understand text, understand images, generate on demand, converse), decide where it runs — on-device for free/private/offline classification and short summaries, a cloud model API for heavy reasoning — and spec it with an output contract, failure behaviour, and an escape hatch before building. An AI build agent can then implement the native integration from that spec.

    On-device features cost nothing per request. Cloud features are metered per token and become a per-user cost line: at published Claude API prices (30 Aug 2026), a light summarisation feature works out to roughly ten cents per active user per month and a chat-heavy assistant to a few dollars — illustrative shapes, not quotes. The product decision is putting that line in the same spreadsheet as your pricing before launch, not after.

    Both, deliberately: on-device (the platforms now expose local models to apps) for classification, tagging and short summaries — free, offline, private; cloud APIs for the marquee reasoning feature, gated to paid tiers or capped. Hybrid is the correct default architecture, not a compromise.

    Building WITH AI means an agent writes your app’s code from specs — that is what tools like Modaal do. Adding AI TO an app means shipping model-powered features your users touch: chat, summaries, smart search. They compose: you spec the AI feature, and the build agent implements it in native code. This guide covers the second; most of our site covers the first.

    Against its contract, not against taste: define the output contract (format, length, hard rules like "never invents names"), collect a few dozen real inputs, and check outputs against the contract plus the failure states (slow, wrong, unavailable). Then instrument it — first-month usage data reliably differs from the spec, and the informed second version is where AI features get good.

    Start free. Ship native.

    One project, unlimited prompts. No card.

    Download for MacThe spec-driven workflow

    Keep reading