Apple 又送钱来了。
如果你正在开发 iOS 或 macOS App，想给用户加入总结、改写、翻译、文档问答等能力，Apple Foundation Models 的 PCC 方案值得认真看一遍。它的关键价值不是“又多了一个大模型 API”，而是：在符合条件并拿到权限之后，App 可以通过原生 Swift 框架访问 Apple 的 Foundation Model，不要求你在客户端塞入 OpenAI、Claude 或 Gemini 的 API Key。
但这件事也最容易被一句“无需 API Key”带偏。PCC 不是一个可以随意调用的通用 REST 服务，申请到 entitlement 不等于所有设备都能用，Xcode 出现 Build Succeeded 也不等于 TestFlight 和真机运行已经验证完成。真正需要理解的，是从账户授权到运行时可用性的完整链路。
先把 Apple Foundation Models、端侧模型和 PCC 分清楚
Foundation Models 是开发者使用 Apple 智能模型的一套统一 Swift API。它至少包含两个对开发者最重要的模型来源：
- • 设备端模型：尽可能在用户设备上完成推理，延迟和隐私表现更好，但模型规模、上下文和复杂推理能力受到设备资源限制。
- • Private Cloud Compute 模型：请求交给 Apple 的 PCC 基础设施处理，用于更大的上下文和更强的推理能力，同时保留 Apple 对云端隐私与无持久化处理的设计承诺。
WWDC26 的官方内容把 PCC 模型描述为拥有 32K 上下文窗口和不同推理级别的服务器模型。这个能力适合更长的文档、需要更多推理步骤的任务，但它不是“任何任务都应该强制上云”。
对应用来说，更合理的抽象不是“我有一个模型”，而是“我有一个模型策略”：
1短文本、轻量改写 ↓设备端 Foundation Model长文档、复杂总结、需要更多推理 ↓Private Cloud Compute超长上下文、特殊领域、复杂 Agent ↓可选的第三方模型服务 2
这里还有一个容易被忽略的边界：Foundation Models 并不会自动把 PDF 变成结构化知识库。你的 App 仍然需要负责 PDF 文本提取、页码保留、分段、上下文拼装，以及结果回写 Markdown。模型只是其中的推理与生成环节，不是整个文档流水线。
PCC 申请的本质：申请的是 Managed Capability
Apple 的 PCC 开发者接入不是注册一个云平台账号，而是申请一项由 Apple 管理的能力。它会进入 App ID、Entitlement 和 Provisioning Profile 组成的签名链路。
可以把四个对象理解成四层：
| 层次 | 对象 | 它回答的问题 |
|---|---|---|
| 账户授权 | Capability Request / Team | Apple 是否允许这个团队使用能力 |
| 应用身份 | App ID / Bundle Identifier | 哪个 App 被授权 |
| 项目声明 | Xcode Capability / .entitlements | 当前 Target 想使用什么 |
| 签名落地 | Provisioning Profile / Code Signature | 最终安装包实际携带什么 |
因此，手动往 .entitlements 文件里写入下面的键，并不能绕过 Apple 的授权：
1com.apple.developer.private-cloud-compute 2
