iOS 26 gives your app a free, private AI model

Apple now lets any iPhone app run a small AI model on the phone itself. What it is good for, where it falls short, and the catch for Arabic and Hindi.

Reviewed by Ali Hassan · Founder

4 min read ·

iOS 26 reached iPhones on 15 September. Most of the coverage went to the new glassy look. For anyone who owns an app, the more interesting change is a developer tool Apple calls the Foundation Models framework. It lets any app use the language model that lives on the phone, the same one that powers Apple Intelligence.

That is different from adding ChatGPT to an app in ways that matter to a business. Each request costs nothing, because the work happens on the user's device. It keeps working with no signal, in a lift or on a flight. And the text a user types never leaves their phone, which makes the privacy conversation with your customers much shorter.

The model is also small. That one fact decides where it fits and where it does not.

What the model actually is

Apple describes it as a model of roughly 3 billion parameters. The models behind ChatGPT, Gemini and Claude are many times larger and run in data centres. A model this size is good at working with text you hand it and weak at knowing things about the world. Ask it to summarise a customer's notes and it does a decent job. Ask it what a product costs or who won last night's match and it may invent an answer with complete confidence.

The framework adds a few tools that make it practical. An app can ask for an answer in a fixed shape, say a title, a category and three tags, and get exactly that back instead of loose text it then has to untangle. The model can call functions inside your app, such as looking up an order. And each session has a working memory of around 4,000 tokens, a few pages of text, so it is built for short jobs rather than long documents.

Jobs it does well

  • Summarising what the user has written: a long note, a meeting transcript, a support thread.
  • Sorting and tagging: putting an expense in the right category, marking a lead as warm or cold, suggesting labels for a photo.
  • Pulling structure out of messy text, so "collect 3 boxes from the Al Quoz warehouse tomorrow at 10" becomes a task with a place, a time and a quantity.
  • Rewriting a message to be shorter, clearer or more polite before it is sent.
  • Small generation from your own content: quiz questions from a lesson, a first draft of a product description from a few bullet points.

Notice the pattern. In every case the information is already inside the app, and the model only reshapes it.

Where it falls short

Facts are the first gap, for the reason above. Anything that depends on current prices, policies or news needs to come from your own data, passed to the model, or from a larger model in the cloud.

Language is the second, and for businesses in the Gulf and India it is the big one. Apple Intelligence currently works in English, French, German, Italian, Spanish, Brazilian Portuguese, Japanese, Korean and simplified Chinese, and the languages Apple has promised for later this year do not include Arabic or Hindi. If your customers write to you in Arabic, Hindi or Malayalam, the on-device model is not ready for anything customer-facing. It is still useful for features that run in English, or for staff apps where the team works in English anyway.

Devices are the third. The model only runs on hardware that supports Apple Intelligence, which means the iPhone 15 Pro and newer, plus recent iPads and Macs, and only when the user has Apple Intelligence switched on. In markets where people keep a phone for four or five years, a large share of your users will not have it. There is no Android version either. Google offers its own on-device model on a limited set of recent Android phones, and it works differently, so a cross-platform app needs a separate plan for each.

How we would use it in a real app

The pattern that makes sense is a split. Small, frequent, private jobs, where a slightly weaker answer is fine, run on the phone. Heavier work goes to a cloud model, where it is worth paying for. A field service app could summarise a technician's notes on the device, offline and at no cost, and only call a cloud model when it is time to write the formal report for the client.

Design the fallback before the feature. If the phone cannot run the model, the feature should either call a cloud model quietly or not appear at all. A button that does nothing on half your users' phones is worse than no button.

Then test with real text from real users. Small models are sensitive to how the instructions are worded, and fifty genuine examples from your support inbox will teach you more in an afternoon than any polished demo.

Is it worth adding now?

For an iPhone app with an English-speaking audience, yes, as a small experiment. There are no API keys to manage, no usage bill to forecast, and no customer data going to a third party. Pick one task your users do often and find tedious, build it with a fallback, and watch whether people use it.

For an app whose users mostly write in Arabic or Hindi, wait. Apple adds languages every year, and the right time to build is when your customers' language is on the list.

// Keep reading

Recommended for you

All articles