On-Device AI (Apple Intelligence, Gemini Nano): Rollout Checklist

On-device models let an app summarise, rewrite, classify or extract text without sending user data to a server. That matters for apps handling messages, health notes or financial data, and for markets where users and regulators are sensitive about data transfers.

There is also a cost angle. Inference on the user’s device does not appear on your cloud bill. For a feature used millions of times a day, such as smart replies or text clean-up, that can change the economics, though the engineering effort is higher.

This is the first gate in the checklist. Apple Intelligence requires recent hardware and specific language and region settings; Gemini Nano is limited to devices whose manufacturers ship AICore support. Both lists change with each release, so check official documentation rather than a blog post.

Pull your own analytics before committing. If only a fraction of your active users own supported devices, the feature becomes an enhancement, not a core function, and the plan should say so.

A pilot proves the model can do the task. Production proves it can do it for thousands of people on mixed hardware, with model updates you do not control.

Both Apple and Google update their on-device models through operating system or system service updates. Your prompts and output parsing can behave differently after an update. Treat this like any third-party dependency: keep a regression test set and run it when a new OS version reaches beta.

Production checklist

• Feature flag the AI path so it can be switched off remotely.
• Log anonymous outcome signals, such as accepted, edited or dismissed, without logging the user’s content.
• Set guardrails for output length and format, and handle empty or malformed responses.
• Document the fallback path and its cost if it uses a cloud model.
• Add the feature to release QA on at least one supported and one unsupported device per platform.
• Prepare support answers for “why don’t I see this feature?”

Measure adoption and quality per platform, because the models differ. Useful metrics are the share of eligible users who try the feature, the acceptance rate of AI output, the edit rate after acceptance and task completion time compared with the non-AI path.

Be careful with privacy promises in measurement. If your marketing says data never leaves the device, your analytics cannot quietly collect the text. Track behaviour, not content.

Small models know less and reason less than their cloud siblings. They are good at bounded tasks with the needed information in the prompt, such as rewriting a paragraph or pulling a date from an email. They are poor at open questions that need broad world knowledge.

Context windows are also shorter, so long documents may need to be split. And because you cannot fine-tune the system model the way you would a cloud model, quality improvements come from better prompts and better input preparation, not from training. Plan features around these limits rather than hoping the next OS release removes them.

Bounded text tasks are the safest start: summarising a single message, suggesting a short reply, rewriting a note in a friendlier tone, or extracting an address or date. Image tasks such as tagging photos or removing a background also suit local processing.

Tasks that need fresh information, long documents or careful reasoning belong on a server model. A clear split, local for quick private tasks and cloud for heavy ones, is easier to explain to users and to legal teams than a feature that switches unpredictably.