visionOS 新特性
What's new in visionOS
2025年6月13日
一句话判断
visionOS 26 把空间计算的开发门槛砍掉了一半——你不再需要学 RealityKit 就能做出像样的 3D 应用,但这也意味着 RealityKit 的定位正在被重新定义。
这场 Session 讲了什么
visionOS 26 干了一件大事:让 SwiftUI 开发者直接用写 2D 界面的方式构建 3D 场景。VStack3D、depthAlignment、frame3DSize 这些新 API 意味着,一个熟悉 SwiftUI 的开发者可以在不懂 RealityKit 实体-组件架构的情况下,做出体积化(Volumetric)应用。体积化体验现在支持在内部和上方展示弹窗、表单这些 UI 元素,之前这种交互只能在 2D 窗口里完成,打断沉浸感。
输入端也有大动作。Vision Pro 发布以来被喷得最惨的就是缺乏精确输入——手势追踪在精细操作场景下精度根本不够。visionOS 26 直接引入了 Sony PS VR2 Sense 控制器和 Logitech Muse 两种空间配件,手势追踪速度也提了三倍。游戏和 3D 建模这类场景终于有了可用的交互基础。
AI 能力方面,Foundation Models 框架让应用可以直接调用设备端语言模型,配合 SpeechAnalyzer 的完全离线语音转文字,空间计算应用第一次有了不依赖网络的 AI 能力。这对企业场景和离线使用尤其重要。
值得深挖的点
SwiftUI 3D 布局:降低门槛还是制造新问题?
SwiftUI 的 3D 布局支持听起来很美好,但这里有个 trade-off 值得想清楚。VStack3D、depthAlignment 这些 API 本质上是把 2D 布局思维延伸到 Z 轴——你还是在用”堆叠""对齐”的概念来组织空间内容。这适合 UI 密集型应用(设置面板、信息展示、表单),但对于需要物理模拟、光照交互、粒子效果的场景,SwiftUI 的抽象层级太高了,你根本控制不了底层渲染管线。
对比旧方案:之前做 visionOS 应用,要么用 RealityKit 从零搭场景(学习成本高但控制力强),要么用 SwiftUI 做 2D 窗口再嵌入 RealityView(两种范式割裂)。现在 SwiftUI 3D 布局填补了中间地带——它不是 RealityKit 的替代品,而是一个更轻量的选项。Apple 的意图很明显:用 SwiftUI 吸引大量 iOS 开发者进入 visionOS 生态,RealityKit 留给需要深度控制的专业场景。问题是,当开发者发现 SwiftUI 3D 布局的能力天花板时,迁移成本会比一开始就学 RealityKit 更高。
空间配件:硬件补完计划的战略含义
PS VR2 控制器的支持不是简单的”兼容外设”。Apple 一直强调 Vision Pro 的手势+眼动交互范式,现在突然拥抱第三方控制器,背后是对现实的妥协——纯手势交互在游戏和专业创作场景下确实不够用。Logitech Muse 的定位更有趣,它瞄准的是生产力场景:3D 建模、精细标注、空间绘图。这说明 Apple 开始区分”消费级空间交互”和”专业级空间交互”两条路线。
对比 Meta Quest 的策略:Quest 从一开始就绑定了控制器,手势追踪是后来加的。Apple 走了反方向的路——先推手势,再补控制器。两条路各有道理,但 Apple 现在面临的问题是控制器生态的冷启动:开发者凭什么花精力适配一个用户保有量未知的外设?这需要 Apple 在第一方应用和 SDK 层面给出足够的激励。
代码片段
用 SwiftUI 3D 布局构建体积化界面
// 场景:教育应用里展示一个可交互的 3D 科学模型
struct VolumetricScene: View {
@State private var showPopover = false
var body: some View {
VStack3D(spacing: 0.05) {
Model3D(named: "robot")
.frame3DSize(width: 0.3, height: 0.3, depth: 0.3)
Text("Hello, visionOS 26!")
.font(.system(size: 24))
.depthAlignment(.front) // 文字始终面向用户
Button("Interact") { showPopover = true }
.frame3DSize(width: 0.2, height: 0.05, depth: 0.01)
}
.popover(isPresented: $showPopover) {
Text("弹窗出现在 3D 空间内部")
}
}
}
坑:frame3DSize 的单位是米,设置太大会超出用户视野,太小会被忽略——需要在真实设备上反复调试。
启用 Object Manipulation 手势操控
// 场景:室内设计应用让用户用自然手势摆放虚拟家具
struct ManipulableObject: View {
@State private var entity = ModelEntity(mesh: .generateBox(size: 0.1))
var body: some View {
RealityView { content in
content.add(entity)
}
.gesture(
TapGesture()
.targetedToEntity(entity)
.onEnded { _ in /* 显示详情面板 */ }
)
.objectManipulation(enabled: true) // 一行启用捏合缩放、旋转、拖拽
}
}
坑:系统提供的标准手势不会帮你做边界检查,用户可以把物体拖进墙里——你得自己处理物理约束。
SwiftUI 与 RealityKit 的状态同步
// 场景:游戏里需要 SwiftUI 状态变化自动驱动 3D 场景更新
@Observable
class GameEntity {
var position: SIMD3<Float> = .zero
}
struct GameSceneView: View {
@State var gameEntity = GameEntity()
var body: some View {
RealityView { content in
let entity = ModelEntity(mesh: .generateSphere(radius: 0.05))
content.add(entity)
} update: { content in
// SwiftUI 状态变化时自动触发
if let entity = content.entities.first {
entity.position = gameEntity.position
}
}
.gesture(
DragGesture()
.targetedToAnyEntity()
.onChanged { value in
gameEntity.position = value.convert(
value.location3D, from: .local, to: .scene
)
}
)
}
}
坑:update 闭包在每一帧都可能被调用,做重计算会卡顿——只在这里做轻量的状态同步。
最佳实践
建议把 SwiftUI 3D 布局当作快速原型工具来用。它的价值在于验证空间交互设计——用最小成本确认一个 3D 界面方案是否值得做。但如果产品需要复杂的物理交互、自定义渲染效果,直接上 RealityKit。不要被 SwiftUI 3D 布局的”易用性”迷惑而把整个应用建在上面,等发现天花板时迁移成本会很高。
输入适配方面,优先支持手势(用户基数最大),同时为 PS VR2 控制器做一套精简的适配层。Logitech Muse 的适配可以等生态成熟再投入——除非应用明确面向专业创作者。设备端 AI 能力应谨慎使用,Foundation Models 的能力边界还不清晰,先在非关键路径上做实验,确认质量够用再上核心功能。
还有什么值得关注
- 沉浸式媒体生态扩展:180 度/360 度/广角视频现在有系统级 APMP 格式支持,兼容主流第三方相机,不用自己造播放器了。
- 空间持久化 API:窗口和内容重启后保持物理位置,这对生产力应用是刚需——你不会想每次打开 Vision Pro 都重新布置工作区。
- 内存限制提升:visionOS 26 放宽了内存上限,但 3D 资源的内存管理仍然不能大意,低端场景下 OOM 风险依然存在。