How to Use AI in a Mobile App: On-Device, Cloud and Hybrid (2026)

To use AI in a mobile app, you pick a model that runs either on the phone itself (Apple’s on-device Foundation Models, or Gemini Nano on Android) or in the cloud (such as Gemini through Firebase AI Logic), then call it from your app code with a prompt and show the result. Most real apps end up with a hybrid: on-device for quick, private, offline tasks and the cloud for heavy lifting or for devices that can’t run a local model.

This guide is for developers and product people working on iOS and Android apps. It covers how to choose an approach, the official tools each platform gives you as of October 2026, and the setup and security steps that are easy to get wrong.

Step 1: Decide what the AI feature actually does

Before picking a tool, pin down the job. Google’s Android AI overview splits AI features into a few clear goals:

• Generate or transform content: summarize, rewrite, answer questions, describe an image, draft text. This is generative AI.
• Analyze input: scan barcodes, read text from a photo (OCR), detect faces or objects, identify a language. This is traditional machine learning, and it’s often faster and cheaper than an LLM.
• Let the system’s assistant use your app: on Android, AppFunctions makes your app’s features discoverable and callable by system assistants such as Gemini.

If your feature is “read the receipt total from a photo,” a classic ML Kit text recognition API may beat a large language model. If it’s “turn these meeting notes into a to-do list,” you want a generative model.

Step 2: Choose on-device, cloud or hybrid

This is the biggest decision. Google’s guidance boils it down to a handful of trade-offs:

Summarized from Google’s Android AI overview.

A sensible rule of thumb from that same guide: small inputs like chat messages or short articles suit a local model, while large inputs such as PDFs, or tasks that need broader knowledge, suit the cloud. If the feature must work offline, keep data private, or avoid per-call costs, lean on-device.

Step 3: Pick the official tool for your platform

iOS and other Apple platforms: Foundation Models framework

Apple’s Foundation Models framework, introduced in 2025, gives apps access to the on-device model behind Apple Intelligence through a Swift API. You create a LanguageModelSession, send a prompt, and read back the response. It supports structured output (you describe a Swift type and get a filled-in instance back) and tool calling, where the model can ask your app for data or actions.

Apple expanded the framework significantly at WWDC26. According to the WWDC26 session on LLM providers:

• The on-device system model was rebuilt, follows instructions better, and accepts images in prompts.
• The same API now works with other models: Apple’s Private Cloud Compute model (with reasoning and a 32K-token context window), local models through Core AI, and open-source models through MLX.
• Apple says Anthropic and Google will ship Swift packages that make Claude and Gemini available through the same API.
• The framework is being released as open source.

The session’s sample code targets the 27-series OS releases, so check Apple’s documentation for exactly which features need which OS version before you plan around them.

One practical warning from Apple’s March 2026 developer newsletter: the on-device model changes when users update their OS, so you should retest your prompts against each new model version. Apple also published Python bindings for the on-device model on macOS to help evaluate prompts.

Android: ML Kit GenAI APIs and Gemini Nano

On Android, Google’s on-device model is Gemini Nano, which runs inside the AICore system service. You usually reach it through the ML Kit GenAI APIs, which currently cover:

• Prompt: custom text or multimodal prompts (the most flexible option)
• Summarization: articles or conversations as bullet points
• Proofreading and Rewriting for short chat messages
• Image Description
• Speech Recognition

Google notes that AICore doesn’t store inputs or outputs after processing and applies built-in safety filters. The catch is coverage: Gemini Nano may be unavailable on some devices, and speed depends on the hardware.

For non-generative tasks, ML Kit’s classic APIs (barcodes, OCR, face and object detection), LiteRT for your own TensorFlow Lite models, and MediaPipe for real-time vision pipelines remain the standard options.

Cloud models: Gemini through Firebase AI Logic

When you need more capability, or need the same behavior on every device, Google recommends calling Gemini Flash or Pro through Firebase AI Logic. Its client SDKs cover Android (Kotlin and Java), Apple platforms (Swift), Flutter, web and Unity. Some SDKs also support hybrid inference, using an on-device model when available and falling back to the cloud otherwise.

Step 4: Wire it up (Android cloud example)

Google’s Gemini Developer API guide for Android lays out the path. In short:

1. Prototype your prompts in Google AI Studio before writing app code.
2. Create a Firebase project and connect your app, following the Firebase AI Logic getting-started guide.
3. Add the Firebase AI dependency (firebase-ai, via the Firebase BoM) plus the App Check debug provider for development builds.
4. Set up App Check with the debug provider locally, and register the debug token in the Firebase console. Never commit or ship that token.
5. Initialize the model with Firebase.ai(...) and call generateContent() with your prompt. Chat, image, audio, video and PDF inputs use the same model object.
6. Before release, register a production attestation provider such as Play Integrity. Google says the Firebase console’s guided setup has enforced App Check since early July 2026, so skipping this step can block real users.

The Gemini Developer API has a free tier that doesn’t need a payment method, and you move to a paid tier as usage grows. Check Firebase’s pricing pages for current rates. Google also lists a Google Cloud-based provider (formerly Vertex AI) for teams with strict data-location needs.

Step 5: Design for failure and change

AI features break in ways ordinary features don’t. Build in these habits from day one:

• Check availability at runtime. On-device models only run on supported devices, and users can turn features off. Hide the feature gracefully or fall back to a cloud model.
• Tell users where their data goes. Apple’s WWDC26 session explicitly notes that on-device and cloud models have different privacy characteristics and that developers should tell users which one they’re getting.
• Don’t ship raw API keys. Apple recommends token providers or sign-in flows, Keychain storage and App Attest. Google’s equivalent is Firebase App Check with Play Integrity.
• Keep sensitive system prompts server-side where possible, which Google suggests as part of its hybrid setup.
• Retest after model updates. Both on-device and cloud models change over time, and a prompt that worked last month may behave differently today.
• Respect limits. On-device models have token limits and narrower knowledge, so chunk long inputs or route them to the cloud.

Which option should you start with?

If you’re building an iOS-first app and the feature is short, private text work, start with the Foundation Models framework on-device model, then swap in Private Cloud Compute or another provider later through the same API. If you’re on Android, try the ML Kit GenAI API that matches your task, and add Firebase AI Logic as a fallback. If you need identical behavior across iOS, Android and Flutter from day one, a cloud model through Firebase AI Logic is the simplest single path.

Model names, OS requirements and pricing move quickly in this space, so treat the details here as accurate as of October 2026 and confirm them in the linked official docs before you ship.