Routing Foundation Models Through Private Cloud Compute: The LanguageModel Protocol in iOS 27

Beta notice. This guide is written against the iOS 27 / macOS 27 developer beta. PrivateCloudComputeLanguageModel and the surrounding API are marked Beta and may change before the public release. Verify signatures against the SDK you target.

iOS 27 introduces a clean abstraction that most teams will get wrong on the first pass. The on-device model and the new Private Cloud Compute (PCC) model both conform to a shared LanguageModel protocol, which means the same session API runs against either backend with a one-line change. The mistake is treating PCC as a default upgrade. It isn't — it trades away the two properties that made on-device compelling. This guide covers what actually changes, how to route correctly, and when PCC earns its cost.

What PCC gives you, and what it takes away

The on-device SystemLanguageModel is always available, works offline, has no usage limits, and runs in a 4K context window with no separate reasoning control. PrivateCloudComputeLanguageModel keeps Apple's privacy guarantees but changes the tradeoffs:

| Capability | SystemLanguageModel (on-device) | PrivateCloudComputeLanguageModel (PCC) | |---|---|---| | Preserves privacy | Yes | Yes | | Works offline | Yes | No — requires network | | Usage limits | Unlimited | Daily limit per person | | Reasoning | Not supported | Multiple levels | | Context size | 4K | 32K |

So PCC buys you an 8× larger context window and explicit reasoning effort, at the cost of offline support and unlimited use. That is the entire decision in one table: reach for PCC when a feature genuinely needs to reason over long documents or sustain long multi-turn conversations, and stay on-device for everything else.

Apple's own guidance is to start on-device, evaluate the feature, and only move to PCC if the evaluation shows you need more reasoning or context. Don't pre-optimize for PCC; measure first.

The one-line switch

Because both models conform to LanguageModel, you pass either into the session initializer. Routing through PCC is a single change to the model you instantiate:

// On-device (default).
let session = LanguageModelSession()

// Private Cloud Compute — same session API, larger context, reasoning support.
let session = LanguageModelSession(model: PrivateCloudComputeLanguageModel())

Everything else — your respond calls, instructions, and tools — carries over unchanged. That uniformity is the point of the protocol: your feature code doesn't fork based on backend.

One developer-experience note that removes a real friction point: with PCC you don't manage API keys or authentication. The user needs a device that supports Apple Intelligence and gets a daily request allotment; they can raise it via iCloud+. You write zero auth code.

Gate availability and version correctly

PrivateCloudComputeLanguageModel exists only on iOS 27 / macOS 27 / watchOS 27 / visionOS 27 and later, so version-gate it and fall back to the on-device model on earlier systems:

if #available(iOS 27.0, macOS 27.0, watchOS 27.0, visionOS 27.0, *) {
    // Create a session using the server-based model.
} else {
    // Use the on-device model on older versions.
}

PCC also requires the device to support Apple Intelligence, so check availability before issuing a request — and note the reasons differ from a transient state you can wait out:

let model = PrivateCloudComputeLanguageModel()

switch model.availability {
case .available:
    // Show your intelligence UI.
case .unavailable(.deviceNotEligible):
    // Permanent for this device — show an alternative, non-PCC path.
case .unavailable(.systemNotReady):
    // Transient — PCC isn't ready to serve requests yet.
case .unavailable(let other):
    // Unknown reason — degrade gracefully.
}

This is the same availability discipline the on-device model needs, with one addition below: the network.

The network fallback nobody remembers

PCC needs a connection. The on-device model doesn't. So the correct architecture isn't "use PCC" — it's "try PCC, fall back to on-device when the network is unavailable." If a PCC request fails because there's no connection, retry against SystemLanguageModel rather than surfacing an error. Your feature stays alive offline, just with the smaller context and no reasoning.

The design rule: PCC is the enhanced path, on-device is the floor. Build the floor first (it's always reachable), then route to PCC when the network is present and the feature benefits.

Handle the daily quota as first-class UI

PCC's per-day limit is not an error to swallow — it's a state to surface, because the user can do something about it (wait for reset, or upgrade iCloud+). Apple gives you a structured quota model rather than a single throw, and recommends a status indicator over a dismissible alert:

let model = PrivateCloudComputeLanguageModel()

// Keep the user aware of their daily-limit status.
if model.quotaUsage.isLimitReached {
    Text("Usage limit exceeded")
        .foregroundStyle(Color.red)
} else if case .belowLimit(let info) = model.quotaUsage.status {
    if info.isApproachingLimit {
        Text("Nearing usage limit")
            .foregroundStyle(Color.orange)
    }
}

// Surface the system upgrade options when available.
if let suggestion = model.quotaUsage.limitIncreaseSuggestion {
    Button("Show options") {
        suggestion.show()
    }
}

When a request actually crosses the limit mid-interaction, the framework throws a quota error (PrivateCloudComputeLanguageModel.Error.quotaLimitReached). Treat it differently from rate limiting: rate limiting is "wait a moment and retry"; quota exhaustion is "wait for the reset date, or upgrade." Inspect the error's resetDate to tell the user when their allotment refreshes — it's empty when the reset isn't known or the person is well under their limit.

Xcode lets you test both states without burning real quota: in the Scheme editor's Run → Options tab, the "Simulated Apple Foundation Models Availability" menu offers "Approaching Quota Usage Limit" and "Quota Usage Limit Reached." Wire your UI against both before shipping.

Use reasoning levels deliberately

PCC supports explicit reasoning effort via ContextOptions, with three levels — .light, .moderate, and .deep:

let response = try await session.respond(
    to: "What are the tradeoffs in this architecture?",
    contextOptions: ContextOptions(reasoningLevel: .deep)
)

Reasoning isn't free: higher levels generate intermediate reasoning text that consumes part of the context window and adds latency. Apple's guidance — and the right default — is to start at .moderate, and reserve .deep for genuinely hard, multi-constraint problems (architectural decisions, long analyses) where catching what lighter levels miss is worth the slower response. The reasoning segments don't appear in the final content, but you can review them when debugging why the model produced a particular answer.

A complete routing pattern

Putting it together: floor on-device, enhance with PCC when present, degrade on network loss, surface quota as state.

func respond(to prompt: String, needsLongContext: Bool) async -> String {
    if needsLongContext,
       #available(iOS 27.0, macOS 27.0, watchOS 27.0, visionOS 27.0, *) {
        let pcc = PrivateCloudComputeLanguageModel()
        if case .available = pcc.availability, !pcc.quotaUsage.isLimitReached {
            do {
                let session = LanguageModelSession(model: pcc)
                return try await session.respond(
                    to: prompt,
                    contextOptions: ContextOptions(reasoningLevel: .moderate)
                ).content
            } catch {
                // Network failure or quota — fall through to on-device floor.
            }
        }
    }
    // On-device floor: always reachable.
    let session = LanguageModelSession()
    return (try? await session.respond(to: prompt).content)
        ?? deterministicFallback(for: prompt)
}

Production checklist

• Start on-device; move to PCC only after evaluation shows you need 32K context or reasoning.
• Version-gate PrivateCloudComputeLanguageModel behind #available(iOS 27.0, …) with an on-device fallback.
• Always build the on-device floor first — PCC is the enhancement, not the baseline.
• Retry on-device when PCC fails for lack of network.
• Surface quota as UI state, not a dismissible alert; expose the upgrade suggestion.
• Distinguish quota exhaustion from rate limiting — use resetDate to inform the user.
• Default reasoning to .moderate; reserve .deep for hard multi-constraint tasks.
• Test quota states via the Xcode scheme simulator before shipping.

Why this matters for shipped apps

The LanguageModel protocol is quietly one of the most important things Apple shipped in iOS 27: it makes the on-device/PCC choice a runtime routing decision instead of an architectural fork. The teams that get this right will offer a feature that works offline at a 4K floor and transparently scales to 32K with reasoning when the network and quota allow — all behind one session API, with no keys to manage. The teams that get it wrong will either default everyone to a metered, online-only path, or never build the offline floor that makes the feature dependable.

Designing the on-device/PCC routing layer for a feature is exactly the kind of architecture decision we work through in our on-device AI integration and architecture audit engagements at 3NSOFTS.