Apple's Cloud AI Now Runs on Google Gemini. If Your iOS App Calls Foundation Models in the Cloud, You Just Inherited a $1B Dependency.
At WWDC on June 8, Apple and Google confirmed a multi-year collaboration in which the next generation of Apple's cloud Foundation Models, and a more capable Siri, run on Google's Gemini models and cloud technology. Reports put the Siri arrangement at roughly $1 billion a year. Google published its own post the same day announcing that Gemini is available to Apple developers through the Foundation Models framework and inside Xcode 27. So here's the thing nobody is saying plainly: if your iOS app calls the cloud tier of Foundation Models, you're calling Google, and you didn't sign that contract: Apple did.
I want to be careful and fair about this, because the coverage has been sloppy in both directions. Let me separate what's confirmed from what's disputed before I tell you what to actually do.
What's confirmed, and what's still in dispute
Confirmed: Apple's cloud-side AI and the next Siri are built on Gemini, under a multi-year deal. Confirmed: developers can now call Gemini (and Claude) through the same Swift API as Apple's own model, and Google integrated Gemini into Xcode for agentic coding help. That part isn't rumor: Apple and Google both said it on the record.
Disputed: whether Apple's on-device Foundation Models are distilled from Gemini. Some outlets reported the new local models were trained off Gemini; others, including AppleInsider, reported the opposite: that the on-device models contain "not a drop" of Gemini and remain Apple's own work. I can't resolve that conflict from the outside, so I'm not going to build an argument on it. The honest position is: the on-device model is, as best anyone can confirm, still Apple's. The cloud tier is Google's.
That distinction is the whole story for a developer, so hold onto it.
Where the dependency actually lands
Your app interacts with Foundation Models at two tiers, and they have completely different dependency profiles.
When you call the on-device model, you depend on Apple, same as you always have. It runs on the user's silicon, it works offline, and Google isn't in the loop. Nothing about your supply chain changed for that path.
When you call the cloud tier, your request leaves the device and gets served by infrastructure that now runs on Gemini. That means a feature you ship as "Apple Intelligence" is, underneath, a Google model answering your user's prompt. Your latency, your refusal behavior, your model quality, your privacy surface for that call: all of it now traces back to a Gemini deployment you have no relationship with and no visibility into. You inherited a vendor by reaching for a convenient API.
For most apps, most of the time, that's fine. But "fine until it isn't" is exactly the kind of dependency that bites a solo operator at the worst moment: when Google changes Gemini's behavior, when the deal terms shift, when a model update quietly changes how your feature responds and your users notice before you do.
The escape hatch Apple built in
Here's what makes this manageable, and it's the same mechanism I praised in the free-inference story: the LanguageModel protocol.
Because Apple shipped a provider-agnostic Swift interface, the cloud model behind your feature is a configuration choice, not a hardwired fact. At launch, both Google and Anthropic implement the protocol. If you don't want Gemini serving your cloud calls, you can route them to Claude instead by swapping the Swift Package Manager dependency: your session logic and tool calls stay the same. The dependency is real, but it isn't a lock-in. Apple, perhaps deliberately, made the thing you depend on swappable.
That's the practical out. You're not stuck with whichever model Apple wired to its own Siri. You get to decide which cloud provider sits behind your feature, and you can change your mind later without a rewrite.
What I'd actually decide before shipping
Decide, per feature, whether it needs the cloud at all. A lot of what you'd reach to the cloud for (short summaries, classification, simple rewrites) the on-device model now handles. Every feature you can keep on-device is a feature with zero third-party dependency, zero per-call cost, and offline support for free. Default to on-device and escalate to cloud only when the task genuinely needs the bigger model.
For the features that do need the cloud, pick the provider deliberately instead of accepting the default. If your app's positioning leans on privacy or independence, routing your cloud calls to a model of your choosing, and being able to say which one, is worth the five minutes it takes to wire the protocol. If you don't care, the default is genuinely fine.
And write your code through the protocol regardless. The entire reason this dependency is survivable is that Apple made it swappable. Take the win. Wire every cloud call through LanguageModel so that when the deal terms change, or Gemini's behavior shifts, or you simply want to test Claude against Gemini for your specific use case, it's a config change and not a sprint.
The honest counter-take
The dependency framing can be overplayed, and I don't want to scare you off a genuinely good deal. A managed, Google-backed cloud model that Apple runs the infrastructure for, and that's free up to 2 million downloads, is, for a solo operator, mostly a gift. You get frontier-class cloud inference without standing up a backend, without a contract with Google, and with the option to switch providers whenever you like. That's a better starting position than "rent an API and run your own server" by almost every measure.
The dependency is real and worth being conscious of: your cloud features now ride on a Google deal you don't control. But Apple gave you the escape hatch in the same release. Use the on-device model where you can, route the cloud calls where you want, and wire everything through the protocol so the dependency stays a choice instead of a trap.
Author
Lukas
@lukcombinator