What Is Apple’s LanguageModel Protocol? A Plain-English Guide

At WWDC 2026, Apple shipped a small change with surprisingly big consequences. Let me explain the LanguageModel protocol the way I wish someone had explained it to me.
Written by

Chris C

Updated on

Jun 19 2026

Table of contents

    If you have been anywhere near Apple developer news since WWDC 2026, you have probably seen the phrase LanguageModel protocol thrown around. It sounds like the kind of thing only a framework engineer needs to care about. It is not. It is actually one of the more useful ideas to understand if you want to build AI features into an iOS app, and you do not need a computer science degree to get it.

    Here is the one-sentence version. The LanguageModel protocol is a standard “shape” that any AI model can fit into, so your app can switch from one model to another without rewriting your code. Apple’s own on-device model fits that shape. So does Claude. So does Gemini. They all plug into the same spot.

    In this guide I will walk you through what problem this solves, how the pieces fit together, and why it matters for what you build. No prior AI experience needed. Let’s start with the big picture.

    Your app’s code LanguageModel Session the one API you write against LanguageModel the standard plug On-device Private Cloud Claude Gemini Open models
    Your code talks to one session. Any model that fits the standard plug can sit behind it.

    First, a Quick Refresher: The Foundation Models Framework

    To understand the LanguageModel protocol, you need to know about the framework it lives inside. That framework is called Foundation Models, and Apple introduced it at WWDC 2025 with iOS 26.

    In plain terms, Foundation Models is the official Apple way to use an AI language model from inside your app using Swift. Before it existed, if you wanted AI in your app, you had to sign up with an outside provider, manage an API key, write networking code, and send your users’ data off to someone else’s servers. Foundation Models changed that by giving you a built-in, on-device model with a clean Swift API.

    The center of that API is something called a LanguageModelSession. Think of a session as a single conversation with a model. You create one, optionally give it some instructions, and then send it prompts. Here is roughly what that looks like:

    import FoundationModels
    
    // Open a conversation with Apple's on-device model
    let session = LanguageModelSession()
    
    let response = try await session.respond(to: "Summarize this note in one sentence.")
    print(response.content)

    That is the whole idea. A few lines of Swift and you are talking to a real language model, running right on the device, with no API key and no network call. For a lot of everyday tasks like summarizing, rewriting, tagging, or generating short content, that is genuinely all you need.

    Worth knowing: The Foundation Models on-device model is small and fast, but it is not a frontier model. It is great for focused text tasks. It is not designed to answer broad “ask it anything” questions the way a large cloud model can. Keep that distinction in mind, because it is the whole reason the LanguageModel protocol exists.

    So What Changed at WWDC 2026?

    Here is the catch with the original version. Until WWDC 2026, the Foundation Models framework had one rule: you used Apple’s on-device model, or nothing. If your feature needed something more powerful, like a big cloud model for harder reasoning, you were back to square one. You had to bolt on a completely separate SDK, manage your own message history, write your own error handling, and basically duplicate everything Foundation Models was already doing for you.

    WWDC 2026 fixed that. Apple introduced the LanguageModel protocol, which opens up that same clean session API so it can sit in front of almost any model, local or cloud. Here is the before and after.

    BEFORE · iOS 26 AFTER · iOS 27 Your app Apple on-device model only anything else = a separate SDK One model. No choices. Your app LanguageModel Session Apple on-device Private Cloud Compute Claude / Gemini / more Same code. Swappable model.
    Before, your app was wired to one model. After, your app talks to a session and the model behind it becomes a choice you make.

    What the LanguageModel Protocol Actually Is

    Let’s slow down on the word “protocol,” because it trips people up. In Swift, a protocol is just a list of requirements. It says “if you want to be considered one of these, you need to do these specific things.” It is a contract. Anything that fulfills the contract counts, no matter who made it.

    My favorite way to picture this is a wall socket. The socket has a standard shape. A lamp, a phone charger, and a toaster look nothing alike on the inside, but they all end in the same plug, so they all work in the same socket. You do not rewire your house to switch from a lamp to a toaster. You unplug one and plug in the other.

    The LanguageModel protocol is that standard socket shape, but for AI models. Apple defined the shape. Any model that conforms to it, which is just the Swift word for “fits the shape,” can be dropped into a LanguageModelSession. Your session code does not know or care which model is plugged in. It just knows the model fits.

    The key insight: The protocol is not the model. It is the agreed-upon shape that lets many different models be used interchangeably. That separation is the entire point, and it is why this matters more than it first appears.

    The Two Pieces Under the Hood

    If you peek inside, the protocol is built from two cooperating parts. You do not need to memorize this to use the framework, but understanding it makes everything else click into place.

    LanguageModel “the spec sheet” • declares what the model can do • hands over a Configuration • stays small and simple Configuration LanguageModelExecutor “the engine” • warms up the model • translates the conversation • runs it and streams the reply The Configuration is the handoff: the model describes itself, the framework builds the engine.
    The model describes itself, then hands the framework a configuration it uses to build the engine that does the work.

    The first part, LanguageModel, is the description. It tells the framework what the model can do and hands over a configuration object. Think of it as the spec sheet. It is intentionally lightweight.

    The second part, LanguageModelExecutor, is where the real work happens. It warms up the model so the first request is faster, translates your conversation into whatever format that specific model expects, runs the request, and streams the answer back. Think of it as the engine.

    You almost never write this yourself: Apple, Anthropic, and Google have already implemented these pieces for their models. As an app developer, you just pick a model and use it. You would only implement the protocol directly if you were a model provider shipping your own model as a Swift package for other people to use.

    Which Models Already Speak This Protocol?

    This is the fun part. Several models already conform to the protocol, and more are on the way. Here is the lineup as of the iOS 27 developer beta.

    ModelWhere it runsBest for
    SystemLanguageModelOn the deviceFree, private, offline. Everyday text tasks like summarizing and tagging.
    PrivateCloudComputeLanguageModelApple’s private cloudBigger context and stronger reasoning while keeping Apple’s privacy guarantees.
    CoreAILanguageModelOn the deviceRunning a model you package and bundle yourself. Open sourced by Apple.
    MLXLanguageModelOn Apple siliconRunning open models from the community. Aimed at the Mac in the current beta.
    Claude (Anthropic package)Anthropic’s cloudFrontier quality for genuinely hard tasks.
    Gemini (via Firebase SDK)Google’s cloudFrontier quality and the Google ecosystem.

    Apple’s own models sit at the top two rows. The on-device model handles quick, private work. When a task needs more horsepower, Private Cloud Compute steps up while still keeping your data inside Apple’s privacy boundary. The third-party models from Anthropic and Google arrive as Swift packages you add to your project, and once added, they slot into the exact same session API.

    What This Means for You: The One-Line Swap

    Here is the payoff, and it is genuinely satisfying. Because every model fits the same shape, LanguageModelSession now takes a model parameter. Swap that one value and you swap the entire engine behind your feature. Nothing else in your code has to change.

    Start with the free on-device model while you build and test:

    import FoundationModels
    
    // Apple's on-device model: free, private, works offline
    let model = SystemLanguageModel.default
    let session = LanguageModelSession(model: model)
    
    let response = try await session.respond(to: "Summarize this contract.")

    Later, when a feature needs heavier reasoning, point the same session at a cloud model. Look closely. Only one line is different:

    // Same session code. Just point it at a different model.
    let model = PrivateCloudComputeLanguageModel()
    let session = LanguageModelSession(model: model)
    
    let response = try await session.respond(to: "Summarize this contract.")

    That single swap is the whole architectural win. You are no longer locking your app to one vendor on day one. You can prototype on the free on-device model, then choose a more powerful model only for the features that truly need it. If pricing or quality changes down the road, switching is a small edit instead of a rewrite.

    A practical way to think about it: You are no longer picking a vendor. You are picking a policy. Run this task locally for free and privately, route that harder task to a frontier cloud model, all from the same code. That flexibility used to require a pile of custom plumbing. Now it is built in.

    A Few Things Worth Clearing Up

    Whenever I explain this, the same questions come up. Let me answer them directly.

    Does this mean my app now sends data to the cloud?

    No, not unless you choose a cloud model. The on-device model stays on the device, free and offline. The one place your users’ data leaves Apple’s boundary is if you deliberately pick a third-party cloud model like Claude or Gemini. That should be a conscious decision, not a default. Treat it that way and be honest with your users about it.

    Do I have to learn a whole new API?

    No. That is the beauty of it. The session, the prompts, the structured output, the tool calling, all of it works the way it did before. The protocol does its job quietly underneath. If you already know LanguageModelSession, you already know how to use any conforming model.

    Is this set in stone yet?

    Not quite. As I write this, the LanguageModel protocol is in beta, available across the iOS 27, iPadOS 27, macOS 27, visionOS 27, and watchOS 27 developer betas. Apple’s documentation labels it as preliminary, which means names and small details can still shift before the final release. The core idea is stable, but do not be surprised if a method signature changes between now and launch. Always check the current docs before you ship.

    My honest take: This was one of the quieter WWDC 2026 announcements, and I think it is one of the most important for app developers. It does not add a flashy feature. It removes a ceiling. That kind of change tends to matter more over time, not less.

    Using AI to Go Deeper on This

    A lot of you are learning iOS with an AI assistant open in another window, and that is a great way to work as long as you stay in the driver’s seat. The goal is always to understand the concept yourself, not to have the AI understand it for you. Here are a couple of prompts that use AI as a tutor rather than a shortcut.

    Deepen Your Understanding Use AI as a patient tutor, no code generation required
    Explain the difference between a Swift protocol and the thing that conforms to it, using a real-world analogy. Then tell me how Apple’s LanguageModel protocol uses that idea.
    I think I understand why the LanguageModel protocol matters, but I am not 100% sure. Quiz me on it. Ask one question at a time and tell me when I get something wrong.
    Connect It to Your Project Make the concept concrete for what you are building
    Here is a feature idea for my app: [describe it]. Help me reason through whether it should run on the on-device model or a cloud model, and explain the tradeoffs before recommending anything.
    The rule I always come back to: If an AI tool writes code for you, you should be able to explain every line of it before you move on. If you cannot, ask it to walk you through the code until you can, or write it yourself. Understanding is the whole job.

    Summary

    Here is the quick recap of what the LanguageModel protocol is and why it matters:

    • The Foundation Models framework (from WWDC 2025) lets you use an AI model from Swift through a LanguageModelSession.
    • At WWDC 2026, Apple added the LanguageModel protocol: a standard shape that any model can fit into.
    • Picture it as a wall socket. Apple’s on-device model, Private Cloud Compute, Claude, and Gemini all plug into the same spot.
    • Under the hood it has two parts: LanguageModel describes the model, and LanguageModelExecutor runs it.
    • The payoff is a one-line swap. Change the model you pass to a session and the rest of your code stays the same.
    • On-device stays free and private. A cloud model is a deliberate choice you make for the features that need it.

    The best way to make this stick is to open Xcode 27, create a LanguageModelSession with the on-device model, and send it a prompt. Once that works, try swapping the model and watch how little of your code has to change.

    Now that you understand the protocol that ties it all together, a great next step is learning how to use guided generation with the @Generable macro to get clean, structured data back from a model instead of plain text. That is where Foundation Models starts to feel like a real superpower.



    Get started for free

    Join over 2,000+ students actively learning with CodeWithChris