On-Device AI for Mobile Apps: How to Pick the Right Apple Layer Before You Build

On-device AI for mobile apps used to mean a blunt choice: send every request to a cloud service and pay per call, or squeeze a model onto the phone by hand. Apple now ships a layered stack instead, so the hard question has moved from "can we build this?" to "which layer should this feature sit on?" Choose well and the feature ships faster, costs almost nothing to run and keeps customer data on the device. Choose badly and you inherit a model, a conversion pipeline and a battery problem you never needed.

This guide is written for business owners and product leads who are about to brief a mobile project. It explains each layer in plain terms, shows which jobs belong where and lists the mistakes that add cost without adding value.

Key Takeaways

• Start with the language model Apple already ships on the device. It needs no model files, no per-use bill and no ongoing maintenance from your team.
• Use Core ML when the job is to recognise, classify, score or predict. A classifier of a few megabytes beats a multi-gigabyte language model at those tasks on speed, cost and battery.
• Bring your own generative model only when a requirement forces it, such as a specialist field model your team has validated.
• On-device processing keeps sensitive data on the phone, which makes privacy obligations easier to meet.
• Let the requirement choose the layer. Never let the newest framework choose the requirement.

Why the Layer You Pick Matters More Than the Model

Most failed AI features do not fail because the model is weak. They fail because the team picked a layer that did not match the job. A business that wants to tag expense categories does not need a chatbot engine. A business that wants plain-English summaries of site inspection notes does not need a custom image classifier.

The layer decides what you ship, what you maintain and what you pay each month. That is why we settle it during discovery, before a single screen is designed. Our mobile app development team treats it as an architecture decision, not a coding detail.

The One Question That Splits the Stack

Every option below answers a single question: do you use the intelligence Apple ships, or do you bring your own? Everything on the "use what ships" side is private, free to call and maintained by Apple. Everything on the "bring your own" side gives you control, and with it, responsibility.

Foundation Models: the default for language tasks

Apple's Foundation Models framework gives an app access to the language model that already lives on supported iPhones, iPads and Macs. You write instructions and describe the shape of the answer you want. The framework fills in that shape and hands back a typed result, so there is no fragile text parsing afterwards.

That makes it a strong fit for turning messy input into clean records. A technician types "replaced pump seal at the Dandenong depot, needs follow-up Friday" and the app returns a category, a title, a due date and a priority. Because the model runs on the phone, the note never leaves the device and there is no AI invoice at the end of the month.

Two cautions apply. The model is not present on every device, and a user can switch the feature off, so the app must check availability and have a sensible fallback. Its output is good but not perfect, so keep the requested structure small and validate what comes back.

Core ML: still the right tool for recognising and scoring

Core ML is the older, quieter layer, and it remains the best answer for work that is not generative. If the verb is recognise, classify, detect, score or predict, start here. Image classification, object detection, sound recognition and tabular prediction all fit.

The size gap is the whole argument. A Core ML classifier runs in milliseconds, takes a few megabytes of storage and barely touches the battery. Pointing a giant language model at "is this a pallet or a carton?" is like hiring a crane to hang a picture frame. It works in the demo and wastes money in production.

Core ML also supports a pattern that surprises many clients: apps that learn new items on the spot. Apple's Vision framework turns a camera frame into a compact numeric fingerprint, and the app compares that fingerprint against items the user has taught it. A stock controller photographs a new part from a few angles, names it, and the app recognises it from then on. There is no training run, no server and no per-scan fee.

Core AI: when you must bring your own generative model

Core AI is Apple's newer route for running your own generative model on Apple silicon. You convert a model, shrink it to fit the device and ship it with the app. The payoff is a model you chose, running offline, with no cloud cost per use.

The price is ownership. You are now responsible for the model's quality, its size in the app download and its updates. Treat it as an earned decision. Choose it when the system model genuinely cannot do the job, for example when a regulated field demands a model trained and checked for that field.

App Intents: getting the feature out of the app

App Intents is not an AI layer. It is the wiring that lets Siri, Spotlight and Shortcuts run an action in your app without opening it. A field worker says what they want logged and the work happens in the background. Pair it with one of the layers above and the intelligence becomes part of the phone rather than a screen the user has to visit.

A Decision Table You Can Hand to Your Developers

• Summarise, extract or rewrite text - Layer: Foundation Models; Why: Private, free to call, nothing to maintain
• Recognise, classify or score - Layer: Core ML; Why: Tiny, fast, battery friendly
• Run a specialist generative model offline - Layer: Core AI; Why: You control the model and accept its upkeep
• Reach a feature from Siri or Spotlight - Layer: App Intents; Why: Opens the feature to the system

Two Worked Examples

These are illustrations of the thinking, not client case studies.

A warehouse stock check

A distributor wants staff to point a phone at a shelf and see what is there. The verb is recognise, so Core ML and Vision handle the camera work on the device. If staff also want to dictate a short note about damaged stock, Foundation Models can turn that sentence into a structured record. Two layers, each doing the job it suits, and no model files to maintain beyond the classifier.

A specialist research assistant

A medical research group wants staff to ask questions about papers in their own field, with accuracy they can defend. The system model may not be enough here. The requirement, not the technology, moves the feature to Core AI with a model the group has validated. The phrase "defend its accuracy" is what changed the layer.

Three Mistakes That Add Cost Without Adding Value

• Reaching for the impressive option. Bringing your own model looks bold, but it adds conversion work, quality loss from shrinking the model and a larger app download. If Foundation Models already does the job, stay there.
• Using a language model to classify. Generative does not mean better. Sorting, scoring and recognising belong on Core ML.
• Confusing two meanings of "bring your own model". One means sending requests to a provider such as Claude or Gemini over the network, which costs money per call and moves data off the device. The other means running your own weights on the phone. Ask a stakeholder which one they mean before you scope anything.

Privacy and Running Cost on the Device

When the work runs on the phone, customer text and photos stay there. That simplifies the conversation with your privacy officer, though it does not remove your obligations. The Office of the Australian Information Commissioner publishes guidance on the Australian Privacy Principles, and any app that collects personal information should be reviewed against them.

Cost follows the same logic. On-device features carry no per-request fee, so usage can grow without the bill growing with it. When a task is heavy, the system can hand it to Apple's private cloud tier automatically, and you only need a paid external model when the requirement truly calls for one.

Related Resources

• Mobile app development by 9Byte
• AI powered platforms from 9Byte
• Apple's Foundation Models documentation
• Apple's Core ML documentation
• Apple's App Intents documentation
• The Australian Privacy Principles

Common Questions About On-Device AI for Mobile Apps

1. What is on-device AI in a mobile app?

On-device AI means the model runs on the phone itself instead of on a remote server. The app can classify photos, extract details from text or answer questions without sending the data away, and many features keep working offline.

2. Is on-device AI cheaper than a cloud AI service?

Usually, yes. There is no per-request charge when the model runs on the phone. You still pay for development and testing, and a bring-your-own model adds maintenance. A cloud model adds a bill that grows with usage.

3. Will on-device AI work on every phone?

No. Apple's system language model only runs on supported devices, and the user can turn it off. A well-built app checks availability and falls back to a simpler path, such as a manual form, when the model is not ready.

4. When should a business bring its own AI model?

Only when the requirement forces it. Typical reasons are a specialist field that needs a validated model, a strict offline rule or a need to control exactly which model version runs. If the system model can do the job, it is the cheaper and safer choice.

5. Does on-device AI keep customer data private?

It keeps the data on the phone, which removes the network trip and the third-party server. Privacy still depends on what the app stores, what it logs and what it syncs elsewhere, so the whole app needs review, not only the model.

Match the AI Layer to the Job, Not the Hype

The sensible default is short: use the model Apple already ships, keep recognition work on Core ML, and treat a bring-your-own model as a decision you have to justify. Wire the result to Siri and Spotlight when the feature should live outside the app.

If you are weighing an AI feature for an iOS or Android app, send us the one-line job you want done. We will tell you which layer fits it, what it should cost to run and what to leave out. Contact the 9Byte team to start that conversation.