Private Cloud Compute Language Model Protocol: What the New API Exposes and What Stays On-Device

Apple's Private Cloud Compute (PCC) architecture raised an immediate question for iOS developers the moment it shipped: when your app calls a foundation model, where does the request actually go? The answer isn't simply "on-device" or "in the cloud." It depends on which API surface you're using, what the model size is, and how Apple's orchestration layer decides to route the inference request.

This article breaks down what the PCC language model protocol exposes at the API level, what genuinely stays on-device, and what that means if you're building privacy-sensitive features on Apple platforms.

What Private Cloud Compute Actually Is

PCC is Apple's confidential compute infrastructure for AI requests that need a larger model, longer context, or stronger reasoning than the system's on-device model provides. When an app uses PCC, the system is designed so that even Apple cannot inspect the request contents. The servers run a hardened, verifiable software stack, and cryptographic attestation verifies an approved server image before sensitive data is sent.

That's a meaningful privacy improvement over a conventional cloud API. But it is not on-device inference. Data still leaves the device.

That distinction matters enormously if you're building for regulated industries, enterprise clients, or any user base with explicit data residency expectations.

The Foundation Models Framework and How Routing Works

Apple's Foundation Models framework gives developers one session API for multiple model implementations. In iOS 27, that includes the on-device SystemLanguageModel, the server-based PrivateCloudComputeLanguageModel, and third-party or custom implementations of the LanguageModel protocol.

The interface is consistent, but model selection is explicit. A normal SystemLanguageModel session does not silently become a PCC request because a prompt is difficult or the device is warm. To use PCC, an eligible app selects PrivateCloudComputeLanguageModel, holds Apple's com.apple.developer.private-cloud-compute entitlement, and passes that model to LanguageModelSession.

That distinction makes the privacy boundary reviewable in code. The session API may look the same, but the model instance defines whether inference is local or server-based. Apple documents this model-selection approach in the Foundation Models framework and its Private Cloud Compute access requirements.

For a closer look at how on-device inference compares to cloud inference across latency, cost, and privacy dimensions, the Core ML vs Cloud API comparison for iOS in 2026 is worth reading alongside this.

What the Protocol Exposes

When an app explicitly creates a PCC-backed session, the server must receive enough information to perform generation:

The prompt content. The text or structured input you pass to the model is transmitted. It's encrypted in transit and processed inside a confidential compute environment, but it does leave the device.

Relevant transcript and generation configuration. A multi-turn model needs the context required to continue the session. Developers should therefore treat the relevant prompt history, tool results, attachments, and generation options as potentially outbound when using a server model.

Protocol and security material. PCC uses authenticated, encrypted requests and server-image attestation. These mechanisms protect the request path; they do not turn a network request into local inference.

Apple's PCC design minimizes linkability and is built to avoid retaining request data after processing. That is materially different from a conventional cloud API, but teams should base disclosures on Apple's current documentation and on the exact data their own prompts and tools include.

That design is auditable in principle. Apple has made the PCC software image available for security researchers to inspect, which is a stronger claim than most cloud AI providers make. But "auditable" and "on-device" are not the same guarantee.

What Stays On-Device

The clearest on-device path is to select an on-device model explicitly: SystemLanguageModel for Apple's built-in model, or Core AI/Core ML for a custom model. Useful local tasks include:

• Summarisation of short documents
• Basic text classification and sentiment
• Writing suggestions and autocomplete
• On-device image understanding for certain vision tasks

When these run locally, nothing leaves the device. The Neural Engine handles inference, latency is low, and there's no dependency on network availability. This is the architecture that makes sense for features where user data is sensitive by nature: health notes, financial records, private messages — anything a user would reasonably expect to stay on their phone.

The on-device AI guide covering Core ML and the Neural Engine covers how to structure a project so local inference is an architectural guarantee rather than a marketing assumption.

How to Know Which Path Your App Is Taking

Start with the model passed to LanguageModelSession. In iOS 27, the call site makes the main boundary explicit:

A few practical approaches:

Select SystemLanguageModel for Apple's on-device model. Check its availability and degrade gracefully when it is unavailable instead of substituting a cloud model without a clear product decision.

Use Core AI or Core ML for custom local inference. This gives the app control over the shipped model and keeps the full inference path on Apple silicon.

Test the complete feature offline. This catches tools, retrieval, analytics, and fallback services that may still make network calls even when the primary model is local.

Audit the model factory and entitlements. Search for PrivateCloudComputeLanguageModel, third-party LanguageModel providers, and the PCC entitlement. Review tool calls too: a local model can still send data away through a network-backed tool.

For teams building privacy-preserving features at the architecture level, the privacy-preserving AI architectures guide covers how to structure data flows so that sensitive inference stays local by design, not by accident.

The Developer Trust Model

Apple's PCC architecture asks you to trust several things at once: that the software image running on their servers matches the published binary, that the attestation mechanism works as described, and that the stateless design holds under real operational conditions.

For most consumer apps, that trust model is reasonable. Apple's privacy track record is stronger than most cloud AI providers, and the auditable server image is a genuine differentiator.

For enterprise apps, regulated verticals, or any product where "data never leaves the device" is a contractual requirement rather than a preference, PCC isn't sufficient. You need the on-device path, full stop. That means scoping your feature set to what Core ML and the Neural Engine can handle today, and being explicit with your users about where that boundary sits.

The good news is that Apple's on-device model capabilities have expanded significantly. The overview of on-device AI across Apple platforms in 2026 covers what's genuinely possible without any cloud dependency.

Building for the Right Guarantee

The Private Cloud Compute language model protocol is thoughtful infrastructure. It's not a privacy loophole, and it's not equivalent to sending data to a conventional cloud API. But it's also not on-device inference, and conflating the two will cause problems when clients or compliance teams start asking hard questions.

The right approach is to be deliberate. Choose the model explicitly, inspect every tool and fallback, and build the feature around the guarantee the product actually needs—not the one that is easiest to imply.

If you're working on an iOS or macOS product that handles sensitive data and want to get the architecture right from the start, 3Nsofts offers a fixed-scope on-device AI integration engagement designed exactly for this kind of decision.

---

FAQs

Does Private Cloud Compute mean my data never leaves the iPhone? No. PCC routes certain AI requests to Apple's confidential compute servers. Data is encrypted and processed in an isolated environment, but it does leave the device. True on-device inference through Core ML or local Foundation Models variants is the only path where data stays on the phone.

Does LanguageModelSession automatically switch between on-device and PCC? No. The developer selects a model. SystemLanguageModel is Apple's on-device option, while PrivateCloudComputeLanguageModel is the explicit PCC option. Both conform to the same session-facing abstraction.

What data does a PCC-backed session send? At minimum, it sends the prompt and the context required for generation. Depending on the feature, that may include relevant transcript entries, attachments, tool results, and generation configuration. Treat all content supplied to the server-backed model as outbound.

Is PCC suitable for apps in regulated industries like healthcare or finance? That depends on your specific compliance requirements. If your obligation is "data must not leave the device," PCC doesn't satisfy that. If your obligation is "data must not be accessible to the cloud provider," PCC's confidential compute model may be relevant — but get legal review before relying on it.

How do I verify that my app's AI feature is fully on-device? Inspect which LanguageModel implementation is created, audit tools and fallback providers, then test the complete feature in airplane mode. A local primary model is not enough if retrieval, analytics, or a tool still sends user content over the network.

What is the latency difference between on-device inference and PCC-routed inference? On-device inference via the Neural Engine is typically faster for supported model sizes because there's no network round-trip. PCC adds latency proportional to network conditions plus server processing time. For real-time features like live text suggestions, the on-device path is generally preferable on both latency and privacy grounds.

Does using the Foundation Models framework require a PCC entitlement? The on-device system model does not require the PCC entitlement. PrivateCloudComputeLanguageModel does require com.apple.developer.private-cloud-compute, along with Apple’s current eligibility and distribution requirements.