Craig Federighi announced at WWDC26 that Apple Intelligence runs on Google Gemini models, with a new CoreAI framework exposed to app developers. If you ship iOS or macOS software, the model powering your AI features changed this week. Capabilities, model behavior, and on-device API surface all changed with it. The developer documentation is live now.
CoreAI is Apple's abstraction play. The framework creates a layer between your app code and the underlying model, the same way Metal sits between your rendering code and whatever GPU is in the device this quarter. Apple has run this playbook across hardware transitions for decades: the developer writes to the framework, Apple manages the layer underneath. The chip is a procurement decision Apple makes on behalf of its ecosystem. Gemini is the same kind of decision, applied now to the model layer.
I started reading Horace Dediu in the early 2010s because he was one of the few analysts making the case that Apple was being priced like a company in terminal decline while its operating results said the opposite. That valuation-versus-operating-reality gap was the framework Dediu kept returning to, and it matched what I was tracking as someone watching the consumer tech market closely. Dediu carried Clay Christensen's disruption theory, and the observation that stuck was this: the theory works in B2B markets where buyers evaluate feature lists. It breaks in consumer markets where the purchase decision weights experience over specs. Apple's moat was never hardware capabilities. Android matched specs at lower prices, and disruption theory predicted Apple should lose. It didn't, because the high end of the consumer market was paying for an abstraction: the value of something that works without requiring the buyer to understand how it works. The threat model assumed functional-rational buyers. Most of them weren't.
CoreAI extends that thesis into the model layer. Apple is betting that its users will not evaluate Apple Intelligence on whether Gemini is underneath. They will evaluate it on whether the experience holds: whether writing suggestions land, whether screen awareness feels fluid, whether the on-device privacy story is credible. The model is a spec. Apple is managing the spec so the experience can remain Apple's.
For consumer-facing iOS features where AI runs in the background (photo enhancements, ambient writing suggestions, Siri improvements), that abstraction is probably durable. The same dynamic that kept Apple intact through the Android era applies: most users are not doing model comparisons. They want the output, not the mechanism.
The risk lives in a different part of the stack. If your app exposes explicit AI capability that users evaluate on performance (document summarization, code explanation, complex question answering), the model quality becomes visible. You are now building on Google's model accessed through Apple's abstraction, and those two vendors do not have identical interests in how that layer evolves. Apple controls what CoreAI exposes. That is not the full Gemini API surface. The capability your users encounter on-device is whatever Apple has decided to surface through the framework, and that decision belongs to Apple.
There is also a practical divergence problem for teams running cross-platform AI features. The on-device experience looks capable to casual users; anyone who has tested frontier models directly will find it several generations behind at the ceiling. That gap is partly Apple's framework choices about what to expose, not purely Gemini's ceiling. What you test against Google's cloud API and what CoreAI delivers on device may diverge in ways that matter for your specific use case.
Two decisions are worth working through this week. The first is classification: whether your product's AI features are ambient intelligence, where Apple's experience abstraction will hold, or explicit capability, where model quality is user-visible and the framework constraints become product constraints. An app that uses AI to enhance photos silently is not in the same position as one that lets users draft documents or reason through problems. That classification changes how you think about CoreAI dependency and what you owe your users by way of capability transparency. The second is mapping: if your team runs cloud-side Gemini integrations you intend to also surface through CoreAI on Apple devices, the time to find capability gaps is now, before production divergence generates user support tickets. The documentation is available. The gap between what CoreAI exposes and what Google's cloud API exposes is the thing to understand before it surprises you in production.
The CoreAI framework documentation tells you what Apple is selling. The model spec is Google's problem to manage. Apple has been right about the abstraction holding every time a new hardware layer shifted underneath the framework. The difference this time is that the layer underneath has its own developer ecosystem and its own roadmap. Watch what CoreAI exposes at WWDC27 relative to Gemini's cloud API surface at that same moment: that delta is the number operators will care about, and it will not appear in today's documentation.