When Apple opened its on-device language model to developers with iOS 26, the pitch was hard to ignore. App makers could add AI features that run entirely on the iPhone, work offline, keep user data private, and cost nothing per request. No API bills, servers or token math.
For small teams and startups, that sounds like the end of the AI cost problem. But there’s a detail that rarely makes the headline: Apple’s model only runs on some iPhones, for some users, some of the time. An app that treats on-device AI as a given will quietly break for a large share of its audience.
Here’s what the catch looks like, and how smart teams design around it.
Who can actually run Apple’s on-device AI
Apple’s Foundation Models framework depends on Apple Intelligence. For an app to use it, three things have to be true on the user’s phone.
- The iPhone has to be eligible. iOS 26 runs on phones as old as the iPhone 11, but Apple Intelligence doesn’t. Only these models qualify:
| Supports Apple Intelligence | Runs iOS 26, but no Apple Intelligence |
|---|---|
| iPhone 15 Pro and 15 Pro Max | iPhone 15 and 15 Plus |
| All iPhone 16 models, including 16e | iPhone 14 lineup |
| All iPhone 17 models, including 17e | iPhone 13 lineup |
| iPhone Air | iPhone 12 and 11 lineups, iPhone SE (2nd and 3rd gen) |
That means someone who bought a standard iPhone 15 in 2023 is locked out, even on the latest software.
- Apple Intelligence has to be turned on. It’s a setting. Users can switch it off, and some never turn it on. The device and Siri languages also need to be supported.
- The model has to be downloaded. Apple downloads the model in the background based on factors like network status, battery level, and system load. A brand-new phone may not have it yet.
Apple’s own framework reflects all of this. Before running a request, an app checks the model’s status, which can come back as unavailable for three reasons: the device isn’t eligible, Apple Intelligence isn’t enabled, or the model isn’t ready. Only the last one fixes itself.
The gap is getting wider, not smaller
At WWDC 2026, Apple added a second layer. Its most powerful on-device model, announced for iOS 27, is limited to the iPhone 17 Pro, iPhone 17 Pro Max, and iPhone Air, along with high-memory iPads and Macs. Even an iPhone 16 Pro owner won’t get everything.
So instead of one line between “has AI” and “doesn’t,” app teams now face at least three groups of iPhone users with different capabilities.
Why this matters for your business
It’s easy to read a device list and assume the problem will solve itself as people upgrade. But iPhone owners keep their phones for years, and many buy standard models rather than Pros. For the foreseeable future, a meaningful share of any app’s audience will be on phones that can’t run Apple’s model.
If an app is built as if every user has on-device AI, here’s what happens:
- Features vanish for paying customers. A user on an iPhone 14 opens the app, and the “Summarize” button does nothing or shows an error.
- Reviews take the hit. People don’t blame Apple’s hardware rules. They leave a one-star review for the app.
- Marketing promises break. If the App Store listing advertises AI features, users who can’t access them feel misled.
- Support costs rise. Every “why doesn’t this work?” ticket costs time.
The opposite mistake is also common: skipping on-device AI entirely and sending everything to a cloud model. That works on every phone, but it gives up the privacy, offline access, and zero inference cost that make Apple’s framework appealing in the first place.
The better answer is to design for both.
The three-tier approach to AI in iPhone apps
The most resilient AI apps treat on-device AI as an upgrade, not a requirement. They check what each user’s phone can do and route the request accordingly.
| Tier | Who it serves | How it works | Trade-offs |
|---|---|---|---|
| On-device AI | Eligible iPhones with Apple Intelligence on and the model ready | Requests run locally through Apple’s Foundation Models framework | Free, private, offline. Smaller model, so best for focused tasks |
| Cloud fallback | Everyone else who’s online | Requests go to a cloud model through the app’s own secure backend | Works on any iPhone. Costs money per request and needs a privacy disclosure |
| No-AI mode | Users who are offline on older phones, or who opt out | The app works without the AI feature, using simpler logic or manual tools | Always available. Less helpful, but never broken |
Tier 1: On-device first
When the model is available, use it. It’s well suited to focused jobs like summarizing a note, tagging content, pulling key details from text, or suggesting a reply. These tasks fit a smaller model and benefit most from privacy and speed.
Tier 2: A cloud fallback that matches
When the model isn’t available, send the same task to a cloud model. The key is consistency. The user should get a similar result in the same format, whether it came from the phone or the server. That usually means defining the expected output structure once and holding both paths to it.
Two cautions. First, the cloud call should always go through your own backend with proper authentication, never directly from the app with a provider key. Second, be upfront with users that their data leaves the device in this mode, especially in health, finance, or journaling apps.
Tier 3: A graceful no-AI mode
Some users will be offline on an older phone. Others will prefer not to use AI at all. The app should still do its core job. A journaling app still saves entries. A recipe app still shows recipes. The AI feature simply steps back instead of breaking the experience.
Building it right: practical tips for product teams
A three-tier setup isn’t complicated, but it does need to be planned from the start rather than bolted on after launch. A few habits make the difference:
- Check availability every time. Don’t check once at install. A user can turn Apple Intelligence off, change languages, or wait on a model download. Check before each AI session.
- Treat “model not ready” differently. Ineligible devices will never get the model, but a phone that’s still downloading will. Show a short “AI features are getting ready” message instead of hiding the feature for good.
- Pick tasks that fit the small model. Apple’s on-device model is built for focused work, not open-ended research or long documents. Match the task to the tier.
- Use one output format for both paths. Define what a result looks like once, then make both the on-device and cloud paths return that same shape. It keeps the interface consistent and testing simpler.
- Test on old phones, not just new ones. Most teams build on the latest iPhone. Keep an iPhone 13 or standard iPhone 15 in the test lab to see what most users will actually experience.
- Write honest App Store copy. Mention when AI features need a newer iPhone. Clear expectations prevent bad reviews.
This kind of device-aware logic is where native development pays off. Apple’s newest frameworks land in Swift first, and checks like model availability are built to work naturally in native code. For businesses without an in-house team, working with experienced iOS app development specialists who build in Swift and SwiftUI can make it easier to ship on-device AI with a fallback that works on every supported iPhone.
Free AI is real, but plan for everyone
Apple’s on-device model is one of the most useful things to happen to iPhone app development in years. Free, private, offline AI changes what small teams can afford to build.
But “free” only applies to users with the right phone, the right settings, and a downloaded model. Everyone else still needs a working app. The teams that win with Apple’s AI won’t be the ones that adopt it fastest. They’ll be the ones that make sure no user is left with a broken button.
Related: AI Knows More About You Than You Think. Can You Stop It?
