Software Development

Apple's Foundation Models Framework Now Lets iOS Apps Swap AI Providers

Adam Wattis
Adam Wattis
3 minute read

Article

Apple's Foundation Models framework now supports swapping between its on-device model and cloud models like Claude with one line of code. Here's what that means for iOS development.

Apple's Foundation Models framework, the API that lets iOS apps tap into on-device Apple Intelligence, picked up a change at WWDC that's easy to miss in a keynote full of bigger announcements. A new shared protocol lets a developer's app use Apple's on-device model, or swap in a cloud model like Claude, by changing a single line of code. The session logic, prompts, tool calls, and conversation structure stay the same either way.

For any team building an iOS app with AI features, that's a real shift in how the architecture decision gets made.

The problem this actually solves

Before this update, choosing between an on-device model and a cloud model wasn't just a capability tradeoff. It was an engineering tradeoff. On-device models run cheap, fast, and private, but they're limited in what they can reason through. Cloud models handle harder tasks but require managing a completely separate API client, a different response format, and a different way of stitching context across a conversation. Building an app that used both meant maintaining two parallel systems and wiring the handoff between them yourself.

The new LanguageModel protocol removes that duplication. A developer writes session logic once against Apple's standard API, and the model powering any given exchange, on-device or cloud, is a configuration choice rather than a separate code path. A journaling app, to use Apple's own example, can generate a daily prompt on-device where speed and cost matter, then hand off to a larger model when a user asks a question that needs real reasoning across months of past entries, all inside what looks like one continuous session to the user.

Why this matters beyond convenience

The practical benefit isn't just less code to maintain. It's that cost and capability become a per-task decision instead of an app-wide architecture commitment. A team no longer has to choose upfront, for the whole app, between "cheap and fast" and "capable and expensive." They can route the easy 90 percent of interactions to the on-device model at effectively no marginal cost, and send only the genuinely hard cases to a cloud model, without building custom routing logic to manage that split.

That pattern, tiering tasks by actual difficulty rather than routing everything through the most capable and most expensive option by default, is one of the more consistently underused cost optimizations in AI-powered products generally. Apple building it into the platform layer, rather than leaving every team to solve it themselves, lowers the bar for doing this correctly.

What to know before building on it

The framework is in beta, tied to the OS 27 release line across iOS, iPadOS, macOS, visionOS, and watchOS, all currently in beta themselves. Apps built against it now need a conditional path for users on older OS versions, or a separate client for those users, until OS 27 reaches general availability later this year. Worth building against now if an iOS AI feature is on the roadmap, but not yet something to ship as the only path into a production app.