What Apple shipped on June 9 and the procurement surface that lands with it
At the June 9, 2026 Platforms State of the Union, Apple shipped the biggest expansion of the Foundation Models framework since its debut at WWDC25. The framework — the native Swift API that gives an app direct access to the same on-device model that powers Apple Intelligence — moved from a single-vendor SDK that talks to Apple's on-device model to a uniform Swift surface that talks to any model that conforms to a new Language Model protocol. The on-device foundation model still lives in the framework. Claude and Gemini are now reachable through the same API via server-side calls. Any third-party provider that ships a conforming implementation lands behind the same import.
The operationally important pieces, summarized from the WWDC26 sessions and the developer-tooling rollouts:
- Language Model protocol — the Swift protocol any provider can conform to. The app code that calls Apple's on-device model is the same shape as the app code that calls Claude or Gemini. The routing decision sits at the call site, not at the SDK boundary.
- Image input as a first-class modality — the framework now accepts image inputs against the conforming model. The multimodal app workload — receipt parsing, screenshot analysis, accessibility surfaces, visual question-answering — runs against the on-device tier where the provider supports it, against the server tier where the workload requires the larger model.
- Dynamic Profiles — a runtime swap of models, tools, and system instructions inside a continuous session. The app can run the cheap on-device model for routine turns and escalate to a cloud flagship for the workload tail; it can trim or summarize the running transcript to keep it inside the context window; it can change the system instruction mid-session without rebuilding the conversation. Critically, the swap does not require shipping a new app binary — the team revises the prompt and the routing policy without going through an App Store review cycle.
- Free Foundation Models access on Private Cloud Compute — for developers under the two-million-first-time-downloads threshold, the on-device-and-PCC tier ships with no per-token bill. The price floor on the workload that runs against the Apple tier is zero against the deployment volume.
- Open source later this summer — Apple confirmed the Foundation Models framework will be open-sourced later in 2026. The framework that has been an Apple-platform binding becomes a portable surface the developer community can extend.
The rest of the WWDC26 developer rollout — Xcode 27 with the integrated coding intelligence pulling against the same framework, the Apple Intelligence guides for App Intents and the on-device personalization surface — sits underneath the framework expansion. The framework is the procurement object the app team now writes against; the rest of the toolchain is the substrate that lets the framework run.
Why a Language Model protocol on a billion-device install base changes the consumer-AI architecture
For the last three years the consumer-AI app architecture has had a predictable shape — the app team picks a single LLM vendor at the start of the project, integrates against that vendor's SDK, and pays the migration tax every time the routing decision changes. The platform pressure was on the vendor side: the SDK was the lock-in surface, the prompt format was tied to the vendor's tool-calling conventions, the iteration loop on prompt and routing changes ran through the App Store review pipeline because the prompts lived inside the binary. The procurement conversation defaulted to which vendor's SDK do we bet the app on — a decision made once at project start and revisited only on a forced migration.
A Language Model protocol on the iPhone install base resets the architecture on three structural axes.
The vendor decision moves from the SDK boundary to the call site. The app team writes against the protocol, not against the vendor's branded SDK. The conforming implementation for the Apple on-device model is the default; the conforming implementation for Claude and Gemini ships through Apple's server-side integration; any third-party provider that ships a conforming implementation lands behind the same import. The procurement object the team negotiates against is which model do we route each workload class to, not which vendor's lock-in do we accept. The portability that the MCP-native server-side stack delivered to the enterprise developer in 2025 just landed on the consumer-mobile developer in the same shape.
The iteration loop on prompts and routing decouples from the App Store review cycle. The single largest hidden tax on LLM app iteration through 2024 and 2025 was the App Store review latency — every prompt revision, every system-instruction tweak, every routing change required a new binary submission and a multi-day approval window. Dynamic Profiles let the team revise the prompt, the system instruction, and the routing policy at runtime, against the same compiled app. The iteration loop on prompt and routing changes drops from days per round to minutes per round. The eval-and-revise discipline that the enterprise team has been running against the server-side endpoint can now run against the mobile app surface at the same cadence.
The on-device-first deployment surface lands with no per-token bill against the Apple tier. The privacy-and-residency conversation in consumer AI — do we want the user's data leaving the device for the model call — has been a real procurement question for the regulated, the accessibility-sensitive, and the privacy-conscious app team. The Apple on-device-and-PCC tier delivers the model call without a network egress against the cloud provider, with no per-token bill against the developer under the two-million-downloads threshold, and against the same uniform Swift surface the team writes the rest of the app against. The on-device tier is now a real procurement position rather than a marketing posture.
What changes about the consumer-and-pro AI app architecture
Four shifts that follow when the iPhone becomes a vendor-neutral AI surface with a runtime model swap.
The routing decision becomes a first-class architecture concern. A team writing against the protocol is writing against the abstract model interface — the routing logic that decides which workload class runs against which model is engineering work the team owns, not a vendor decision the SDK encodes. The honest read on every workload class: does this turn run against the on-device tier with no bill and no network call, against the server tier through a PCC-routed Claude or Gemini call for the capability ceiling, or against a third-party provider for the capability the cloud flagships do not deliver. The routing matrix is the architecture; the protocol is the substrate.
The eval discipline has to grade the on-device tier honestly against the cloud flagships per workload. The temptation reading the WWDC release is to assume the on-device model is a cheaper alternative on the volume turns and the cloud flagships are the ceiling on the hard turns. The honest read is workload-distribution-dependent — the on-device model is competitive on a meaningful subset of the workload classes, and the routing decision per class needs the workload-specific eval to decide where the line actually falls. The team that routes on vendor positioning will pay the productivity cost on the routing decisions where the positioning was wrong; the team that routes on its own eval data will catch the capability per class and the cost per successful turn at the same fidelity.
Dynamic Profiles change the app-iteration cadence and the alignment loop together. A runtime model-and-prompt swap is the operational surface; the alignment loop that grades each profile against the workload is the discipline the team has to stand up. The app that ships with three Dynamic Profiles — fast and cheap, balanced, quality ceiling — needs the gold sets that grade each profile per workload class, the senior-review queue that catches the failure modes specific to each profile, and the per-profile cost-and-quality dashboard that decides which profile auto-routes for which user state. The iteration loop accelerates; the discipline that keeps the loop honest has to accelerate with it.
The procurement contract surface against the cloud providers gets simpler and more competitive. A protocol-mediated surface against Claude, Gemini, and the third-party providers means the app team's negotiating position changes — the team is no longer locked into a vendor's mobile SDK and can move workload between providers as the per-workload-class cost-and-quality math evolves. The cloud-flagship providers know this; the procurement contracts the app team signs in the next renewal cycle will reflect the new portability. The team that walks into the negotiation with the workload-class-specific eval data already in hand will get a meaningfully better contract than the team that walks in with the prior vendor-lock-in posture.
What this does not change
Three honest caveats.
It does not eliminate the eval discipline at the workload boundary. The protocol delivers the substrate; the eval discipline that grades each model per workload class on the team's specific app is the engineering work the team has to do. The temptation will be to read Apple ships a uniform Swift API as we can route anywhere on vibes, and the team that ships the routing matrix without the per-workload-class evaluation will discover the productivity cost on the routing decisions where the capability ceiling actually mattered, in production rather than in the eval dashboard.
It does not collapse the multi-vendor procurement contract. A protocol-mediated surface lowers the migration cost between providers; it does not eliminate the contract surface against the cloud-flagship providers. The app team that routes a meaningful fraction of the workload against Claude or Gemini still negotiates the per-token contract, the data-handling terms, the SLA, and the residency commitments with each provider. The portability changes the leverage; it does not eliminate the contract.
It does not eliminate the App Store review surface for the larger product changes. Dynamic Profiles decouple prompt and routing changes from the App Store review cycle; they do not decouple the larger product surface — new features, new entitlements, new external API integrations, new content surfaces — from review. The team that reads the release as we never have to submit to the App Store again will discover the residual review surface on the next product cycle. The acceleration is real on the iteration axis; it does not collapse the review surface to zero.
Where Sonnet Code fits
A vendor-neutral Foundation Models framework with runtime model swap on the iPhone install base is the easy half of the consumer-AI architecture conversation. The hard half is the engineering and human-judgment work that turns the framework is open into the routing matrix is encoded against the team's specific workload distribution, the on-device-versus-server boundary is set per workload class from data rather than from vendor positioning, the Dynamic Profiles surface is wired to a per-profile eval-and-cost dashboard with the senior-review queue calibrated to each profile's failure-mode shape, and the alignment loop runs at the cadence the runtime swap unlocks. AI development at Sonnet Code is the engineering half: writing against the Language Model protocol so the app code is vendor-neutral from day one; encoding the routing matrix that decides which workload class runs against which model from the team's own eval data; instrumenting the per-workload-class cost-per-successful-turn attribution across the on-device, PCC, Claude, and Gemini tiers; and standing up the Dynamic Profiles surface against a runtime configuration plane the team can revise without shipping a binary.
AI training is the human-judgment half: senior engineers and domain experts who author the gold sets that grade the on-device model honestly against the cloud flagships per workload class, calibrate the senior-review queue for the failure modes each Dynamic Profile exposes, build the rubrics that decide which profile auto-routes for which user state and which escalates to the cloud flagship, and serve as the senior-judge pool whose calibrated decisions feed the alignment loop the runtime swap unlocks.
The iPhone just became a vendor-neutral AI surface with a runtime model swap that decouples the iteration loop from the App Store review cycle and ships open-source later this summer. The app teams that walk into Q3 with the routing matrix encoded against their workload distribution, the on-device-versus-server boundary set from data, the Dynamic Profiles surface wired to a per-profile eval-and-cost dashboard, and the senior-review queue calibrated to each profile's failure-mode shape are the teams that turn the framework expansion into the compounding productivity delta the next App Store cycle will resolve against. The teams that read the release as another Apple SDK update and renew the prior vendor-lock-in architecture into FY27 will discover, two release cycles later, that the app down the road that built the protocol-native architecture is shipping iteration cadence and per-turn economics the prior architecture could not reach.
