使用 Image Playground 制作高质量图像
Create high quality images using Image Playground
2026年6月10日
一句话判断
✅ Apple 把 AI 画图从“开发者自己接 API 造轮子”变成了“系统级标准 UI 组件”,彻底终结了 App 内集成第三方生图 SDK 的乱象。
这场 Session 讲了什么
这场 Session 最值得关注的一件事是:Apple 正式把 Image Playground (图像游乐场) 的底层模型迁移到了 Private Cloud Compute (私有云计算,简称 PCC),并顺势废弃了允许后台静默生图的 ImageCreator API。以前你想在 App 里加个 AI 画图功能,得自己搞定 Midjourney 或 Stable Diffusion 的 API 鉴权、后端代理、按量计费,还得自己手写一套 Prompt 输入和风格选择的 UI。现在 Apple 直接扔给你一个原生的 Sheet (表单),底层算力走 PCC,隐私拉满,你只需要把 App 里的上下文丢进去,然后接收生成的图片 URL 就行了。
这对所有想在 App 里蹭 AI 生图热度的开发者影响巨大。你不再需要维护昂贵的 GPU 服务器,也不用担心用户乱发 Prompt 导致你的 API 账号被封。代价是你失去了对生图过程的绝对控制权,必须接受 Apple 规定的交互范式:用户必须在系统提供的 Sheet 里确认和微调,App 不能躲在后台偷偷生成。
值得深挖的点
废弃 ImageCreator 与强制 UI 交互背后的阳谋
Apple 这次直接把非 UI 的 ImageCreator 标记为废弃 (deprecated),强制所有开发者使用 .imagePlaygroundSheet 或 ImagePlaygroundViewController。这个设计选择非常坚决。为什么不让代码直接拿图?因为 PCC 的算力是极其昂贵的公共资源,且受限于用户的 iCloud+ 订阅状态。如果开放后台 API,必定会有 App 在后台疯狂循环调用来薅羊毛,或者用于生成违规内容。
通过强制弹出系统 Sheet,Apple 把“触发成本”和“合规责任”转移给了用户。用户必须主动点击、输入、确认。这牺牲了诸如“根据用户聊天内容自动生成配图”这种自动化场景,但换取了零后端成本、系统级隐私合规,以及全平台一致的交互体验。对于开发者来说,这是个巨大的 trade-off:你省去了 90% 的工程和运维工作,但必须把生图功能设计为用户主动触发的 Feature,而不是后台静默的 Magic。
ImagePlaygroundConcept 的上下文注入设计
旧的生图 API 往往只接受一个干瘪的 String 作为 Prompt,导致生成结果像开盲盒。这次 Apple 推出的 ImagePlaygroundConcept (图像游乐场概念) 彻底改变了上下文注入的方式。它不只是传文本,而是传“意图”。
你可以用 .text 传简短的主题,用 .extracted 传一整段长文本(比如用户写的贺卡祝福语),让系统自己去提取关键视觉元素。最惊艳的是 .drawing,它直接接收 PencilKit 的 PKDrawing (手绘数据)。这意味着用户可以在 App 里随便画个草图,系统会把这个草图作为视觉建议传给模型,引导构图而不是死板地临摹。这种设计把生图从“凭空捏造”变成了“基于当前 App 上下文的精准创作”,极大提高了出图的可用率。
代码片段
1. 基础调用与上下文注入
场景:在 SwiftUI 中弹出生图 Sheet,并传入当前卡片的文本和手绘草图作为灵感。
@State private var showingPlayground = false
@State private var drawing = PKDrawing() // 用户的手绘草图
var concepts: [ImagePlaygroundConcept] {
var result: [ImagePlaygroundConcept] = [
// 直接传入短文本主题
.text(card.theme),
// 传入长文本,让系统自动提取视觉元素
.extracted(from: card.message, title: card.theme)
]
// 如果用户画了草图,将其作为视觉建议加入
if !drawing.strokes.isEmpty {
result.append(.drawing(drawing))
}
return result
}
var body: some View {
Button("生成专属配图") {
showingPlayground = true
}
.imagePlaygroundSheet(
isPresented: $showingPlayground,
concepts: concepts,
onCompletion: { url in
// 注意:url 是临时文件,必须在会话结束前拷贝到持久化目录
store.saveImage(url, for: &card)
}
)
}
坑:onCompletion 返回的 url 指向 App 容器内的临时目录,如果你不立刻把它移到持久化存储里,Sheet 关闭后文件就会被系统删掉。
2. 尺寸适配与风格限制
场景:根据当前卡片的横竖版式,动态请求最接近的图片尺寸,并限制用户只能选择特定的艺术风格。
var options: ImagePlaygroundOptions {
var opts = ImagePlaygroundOptions()
// 传入期望的 CGSize,系统会自动映射到最接近的支持分辨率
opts.sizeSpecification = .closest(to: card.format.size)
return opts
}
var body: some View {
Button("生成配图") { showingPlayground = true }
.imagePlaygroundSheet(
isPresented: $showingPlayground,
concepts: [.text(card.theme)],
onCompletion: { url in store.saveImage(url, for: &card) }
)
.imagePlaygroundOptions(options)
// 默认选中插画风格,且只允许用户选择插画和素描
.imagePlaygroundGenerationStyle(
default: .illustration,
allowed: [.illustration, .sketch]
)
}
坑:.closest(to:) 并不是任意尺寸都支持,它会在系统预设的几个宽高比和分辨率里找最接近的。不要指望能精确控制到具体的像素级别。
最佳实践
如果你的老项目还在用 ImageCreator 在后台偷偷生图,赶紧停下。现在的迁移策略是:把生图入口改造成一个显眼的按钮,点击后弹出 .imagePlaygroundSheet。把原来拼接 Prompt 的逻辑,拆解成 ImagePlaygroundConcept 的 .text 和 .extracted。
新项目强烈建议把 Image Playground 作为“用户赋能”工具,而不是“自动化”工具。比如在一个日记 App 里,不要让用户一打开日记就自动在后台生成四张配图(这会触发 PCC 限制且体验突兀),而是提供一个“为这篇日记画个插图”的按钮,并把日记正文通过 .extracted 传给 Sheet。
实战中最容易踩的坑是忽略了 iCloud+ 的限制。Image Playground 依赖 PCC,而 PCC 的配额是跟用户的 iCloud+ 订阅绑定的。你不需要自己写 UI 去提示用户“额度不足”,系统 Sheet 会自己处理这些恶心的边界情况,这也是 Apple 强制使用系统 UI 的原因之一。
还有什么值得关注
- 支持第三方 Provider:
.allowedStyles里可以加入.externalProvider,如果用户在系统设置里绑了 ChatGPT 等第三方服务,Sheet 里会直接多出对应的 Tab。 - Genmoji 风格返回特殊对象:当选择
.emoji风格时,触发的不是onCompletion,而是onAdaptiveImageGlyphCreation,返回的是NSAdaptiveImageGlyph而不是图片 URL,专门用于文本内嵌。 - 个人化 (Personalization) 选项:可以在
ImagePlaygroundOptions中开启个人化,允许用户在 Sheet 里直接从 Photos (照片) 库选熟人进去合影,系统会自动处理人脸特征提取。