Mobile app AI integration means adding features such as summaries, smart search, photo and document understanding or voice actions to an iOS or Android app, using models that run on the phone, in the cloud, or both. It matters because both platforms now ship built-in language models and assistant hooks, so a useful first feature no longer needs your own model or a large cloud bill.
Which AI features actually pay off in a mobile app?
The features that earn their keep remove a step from something people already do often in your app, so the task gets finished faster or with less effort.
- Summaries of long content users already read in the app: threads, reviews, reports, transcripts.
- Extraction from photos and documents, such as receipts, invoices and forms turned into fields the user confirms.
- Natural-language search over the user’s own content, where keyword search fails on vague queries.
- Writing help inside existing input fields: proofreading, rewriting for tone, drafting replies.
- Image description and speech-to-text, which double as accessibility features.
- Classic machine learning for ranking, recommendations and fraud signals, which needs no language model at all.
What rarely pays is a generic chatbot tab with no access to the user’s data or the app’s actions. It duplicates assistants people already have and adds running cost.
When adding AI is the wrong call
- The task is rare, so the build, evaluation and upkeep never pay back.
- Errors are costly and nobody checks the output, as with payments, dosing or legal decisions.
- A rule, a better form or ordinary search would solve the problem.
- Few of your users’ phones can run on-device models, and cloud cost per user exceeds what that user is worth.
For use-case selection across the wider business, see our guide to generative AI implementation.
On-device or cloud: how do the model options compare?
The table compares the main routes. Most production apps combine two of them.
| Option | Runs where | Best for | Main limits | How you pay |
|---|---|---|---|---|
| Apple Foundation Models framework (system model) | On device, iOS 26 and later | Summaries, extraction, classification, typed Swift output, tool calling | 4K-token context; Apple Intelligence devices and regions only | No per-call fee |
| Foundation Models on Private Cloud Compute | Apple servers, iOS 27 and later | Long documents, multi-turn chat, reasoning | Needs a network; daily request limit per person; eligibility rules | No cloud API cost for eligible small developers |
| Core AI (new in iOS 27) or Core ML | On device | Your own or open-weight models; Core ML for classic models such as decision trees | You convert, ship and update the model; app size and memory | No per-call fee; engineering time |
| Gemini Nano via ML Kit GenAI APIs | On device (Android AICore) | Summarising, proofreading, rewriting, image description; custom prompts via the Prompt API | Supported devices only; foreground only; per-app quotas | No per-call server cost |
| Cloud LLM APIs (Gemini, Claude, OpenAI and others) | Provider servers | Hard reasoning, long context, image and video generation, any phone | Latency; network dependence; data leaves the device | Per token, image or second |
On Apple platforms, the system model works within a 4K-token context, while the Private Cloud Compute model offers 32K plus selectable reasoning levels, but needs a connection and gives each person a daily request limit. Apple’s own advice is to start on device, evaluate, and move up only when the feature needs it.
The framework is no longer tied to Apple’s models. In iOS 27 it accepts any provider that conforms to its LanguageModel protocol, including Claude and Gemini, and apps in the App Store Small Business Program with fewer than 2 million first-time downloads get the Private Cloud Compute model at no cloud API cost.
On Android, Gemini Nano runs in the AICore system service and is shared between apps, so you do not ship your own copy. The catch is reach: the ML Kit GenAI APIs work only on listed devices, only while your app is in the foreground, and within per-app and battery quotas. Most of these APIs, including the Prompt API for custom prompts, are still in beta.
The pattern that works is hybrid: on-device for short, private, frequent tasks, and cloud for long or hard requests and for phones that cannot run a local model. Firebase AI Logic supports this fallback in several client SDKs and keeps your Gemini API key off the device.
How do you expose your app’s actions to Siri and Gemini?
If people can ask Siri or Gemini to do something your app does, the assistant needs a structured description of those actions and the content they act on.
iOS: App Intents
On iOS that description is the App Intents framework. Apple’s iOS 27 developer guide highlights three additions worth adopting:
- Entity schemas add your content to Spotlight’s semantic index, so Siri can surface it with attribution to your app.
- Intent schemas let people trigger actions in their own words, with no fixed phrases to maintain.
- View annotations map what is on screen to entities, so people can act on “this” item conversationally.
The App Intents Testing framework then validates the integration through real system pathways rather than UI automation.
Android: AppFunctions
On Android the equivalent is AppFunctions, which lets your app behave like an on-device MCP server. You annotate Kotlin functions with @AppFunction, describe them in KDoc, and authorised callers such as Gemini can discover and run them locally. It needs Android 16 or later, is still experimental, and Google describes the Gemini integration as a private preview with trusted testers.
That status argues for preparing rather than betting the roadmap on it. Pick three to five frequent actions, make them safe to retry, and require confirmation before anything that spends money, sends a message or deletes data. Keep the business logic in one shared layer so App Intents, AppFunctions and your own in-app assistant call the same code.
What privacy, consent and app-store rules apply?
Apple’s guideline 5.1.2(i) says you must clearly disclose where personal data will be shared with third parties, “including with third-party AI”, and obtain explicit permission first (App Review Guidelines). In practice that means an in-app explanation and opt-in before personal data reaches a cloud model provider. A clause in the privacy policy is unlikely to count.
The same guidelines treat AI content-creation apps as user-generated content apps under 1.2, which brings filtering, reporting, blocking and published contact details. Google Play’s AI-Generated Content policy requires apps that generate content with AI to prevent restricted content and to let users report or flag offensive output without leaving the app.
- Send the minimum: strip names, contact details and identifiers before a prompt leaves the device.
- Prefer on-device or Private Cloud Compute for sensitive inputs such as health, finance and messages.
- Switch off provider data retention and training where your contract allows, and never log raw prompts containing personal data.
- Update App Store privacy labels and the Play Data safety form to match the new data flows.
- Label AI output. In the EU, the AI Act also requires telling people when they are interacting with an AI system.
What latency and running costs should you plan for?
Speed decides whether an AI feature feels like part of the app. Nielsen Norman Group’s response-time limits still hold: about 1 second keeps a user’s flow of thought, and about 10 seconds is the limit for keeping attention on the task. Generative features often exceed the first, so design for it.
- Stream output as it is generated, and let people cancel longer jobs.
- Precompute where you can, such as summarising a thread when it arrives rather than when it is opened.
- Keep on-device prompts short; inference speed depends on the phone’s hardware.
- Handle busy and quota errors with exponential backoff and a clear fallback.
On-device models carry no per-call fee. Cloud APIs bill per token, image or second, and the spread is wide: on Google’s Gemini API price list, output from Gemini 3.1 Pro Preview costs 30 times as much per token as output from Gemini 2.5 Flash-Lite.
Estimate cloud spend as tokens per request × requests per active user × active users, plus a margin for retries and long system prompts. The biggest levers are routing simple tasks to smaller or on-device models, capping output length, caching repeated context and batching work that does not need an instant answer.
Budget for upkeep too. On-device models change with system updates and differ between phones, and Google notes that different Gemini Nano versions may return different output for the same prompt. Keep an evaluation set and re-run it on every model or OS update.
A 90-day roadmap for your first AI feature
Ninety days is enough to take one well-chosen feature from idea to a measured rollout in an existing app. It is not enough for five.
- Days 1–10: choose and baseline. Pick one feature tied to a frequent task and record today’s completion rate, time taken and support contacts for it.
- Days 11–25: data, privacy and model choice. Map what data the feature needs and where it may go, then test on-device and cloud options against an evaluation set of real, anonymised examples with expected outputs.
- Days 26–55: build. Ship behind a remote flag with hybrid routing, fallbacks for unsupported devices, consent and reporting UI, and logging of latency, cost, errors and feedback. Add App Intents or AppFunctions for the one or two actions people will ask for most.
- Days 56–70: evaluate and harden. Run the evaluation set on every build, test edge cases, abuse attempts and every supported language, and beta through TestFlight and a Play testing track.
- Days 71–85: staged rollout. Use App Store phased release and Play staged rollout, and keep a holdout group without the feature.
- Days 86–90: decide. Compare the feature group with the holdout, then expand, iterate or remove it based on the numbers.
If this is the first of several features, our AI/ML deployment roadmap covers the monitoring and governance work that follows.
Which ROI metrics show the feature is working?
Measure against the holdout group, not last quarter: releases, seasons and marketing all move app metrics.
| Metric | What it tells you |
|---|---|
| Adoption: share of eligible users who try it | Whether people find and want it |
| Repeat use within two weeks | Whether it delivered value the first time |
| Task completion and time saved versus holdout | The core productivity gain |
| Acceptance: output kept without heavy edits or undo | Quality as users experience it |
| Report and thumbs-down rate | Safety and quality problems |
| Retention, conversion or support tickets versus holdout | The business outcome you will be judged on |
| Cost per successful task | Unit economics, including cloud spend |
| p95 latency and fallback rate | Whether it holds up on real phones and networks |
A simple ROI view is the value of the change in retention, conversion or support cost, minus running and maintenance cost, divided by build cost. Check it at 90 days and again a quarter later, once curiosity-driven use has settled.
How Pixelpk approaches this
Pixelpk builds and runs its own AI products in production, including on mobile. AITube is an AI-only video platform with a studio of 20+ models, iOS and Android apps and a self-serve ads Business Center. Our mobile work also includes KIXX, a native Android and iOS oil-change loyalty app for Saudi Arabia in English and Arabic.
We work as an Extended Team, a Managed Dedicated Team or through Custom Solution Development; our mobile app development page covers native, Flutter and React Native builds. To test a feature idea against the checks in this guide, book a free strategy call.
Frequently asked questions
How long does it take to add an AI feature to an existing mobile app?
For one well-scoped feature, about 90 days from choosing the use case to a measured, staged rollout is realistic. The first month goes on the feature choice, privacy decisions and an evaluation set, the second on building with fallbacks and consent, and the third on testing and rollout against a holdout group. Custom models or regulated data add time.
Should my app use on-device AI or a cloud model?
Use on-device models for short, frequent and private tasks such as summarising, rewriting or extracting fields, because they work offline and carry no per-call fee. Use a cloud model when the task needs long context, stronger reasoning or image generation, or when many users’ phones cannot run a local model. Most production apps combine both.
Do I need user consent before sending data to an AI model?
If personal data leaves the device for a third-party AI provider, yes. Apple’s App Review Guideline 5.1.2(i) requires you to clearly disclose where personal data is shared, including with third-party AI, and to get explicit permission first. Build an in-app explanation and opt-in, minimise what you send and update your privacy labels and Play Data safety form.
Will on-device AI work on all my users’ phones?
No. Apple’s on-device model needs a device and region that support Apple Intelligence, and Gemini Nano through ML Kit runs only on a published list of supported Android devices while the app is in the foreground. Check your analytics for the share of users on supported hardware, and give everyone else a cloud route or a non-AI fallback.
Can I add these features to a Flutter or React Native app?
Yes. Cloud models are reachable from any framework, and Firebase AI Logic has an official Flutter SDK. Apple’s Foundation Models framework, App Intents, the ML Kit GenAI APIs and AppFunctions are native APIs, so a cross-platform app calls them through a thin native module or plugin on each platform. Include that native work in your estimate.