AVP 初印象 - 软件（1）

这是一个系列文章里的第二部分，前面我们聊了硬件…

第二部分我们来聊聊软件。Not all softwares are equal，本章主要说的是 VisionOS 和一些内置的系统软件。因为再往上一层的软件，跟内容的边界已经很模糊了，就留到内容部分去说。

VisionOS

Facts

个人认为，VisionOS 是苹果在 AVP 上最重要的创新。

因为前面说的那些 AVP 在硬件上取得的领先，大概率会让其他从业者觉得：「Wow，但，好像这个我也可以。」比如 micro-LED 的供应链应该现在就有挺多人在看了。

出原生操作系统让开发人员上来搞生态，就不是所有人都可以的了。

不是不想：任何吃内容的硬件平台，都想。因为一方面网络效应会带来内容上极高的壁垒，一方面还可以躺着抽水。

主要是这活确实不好干。

PC 时代，「Wintel」算是这个玩法的鼻祖。移动互联网这么多年，也就出了 iOS并且 iOS 也是在第三代左右才开始有 App Store。 、Android脱钩或许会让中国的鸿蒙等系统壮大， 两个体系。微软这么强的公司，几次尝试都宣告失败。

XR 领域，Meta 花了好几年才把基于 Android 的 QuestOS 功能填充出来，就已经就算做得最头部的。

算法那边，nVidia 倒是好像通过「CUDA+卡」把「Windows+Intel」两家的事儿都办了，所以现在各路人马都在想办法突围。

Apple 比 Meta 轻松，因为它手里已经有了 iOS、macOS、iPadOS、watchOS、tvOS，需要想的不过是基于哪套生态来拓展比较合适。

大家现在都知道答案了，因为官方文档说：「VisionOS 基于 iPadOS，但围绕视觉驱动和低时延做了很多定制和优化，使其更加适用于空间计算。」

这里有些很有趣的话题，比如为什么 AppleTV 也有一个 OS，比如为什么最后选择了 iPadOS 等等，先不去展开。

只聊 visionOS 最终的表现的话，我用下来觉得设计和完成度上有感动到我。

这之前的 XR 世界的主机系统有些像个菜市场。用户从 launcher 启动任何应用，都可能看到完全不同的按钮、交互、拖拽方式，内容的尺寸和距离也是各自发挥。一旦应用崩了，整个系统基本上也就崩了。

visionOS 上，每个应用就比较一致的设计元素和基本交互，跑在各自的 Space 或者 Shared Space 里，就有点精品购物中心的样子了。

感动之后，既然我知道它基于 iPadOS，我还是会说 visionOS 更像一个实习生作品，虽然是那种你想留下来的实习生的作品。

这好像已经在吐槽了，那不如我们就开始 rants。

Rants

考察操作系统，一般来说有用户和开发者两个视角：

• 用户看安不安全，好不好用，应用是不是多，质量是不是好等等；
• 开发者看工具链是不是好用，商务和服务是不是给力，能不能赚到钱等等；

所以我们分两部分。

开机进入visionOS对齐手眼的过程是魔法秀：用户几乎没有理解成本就能理解系统需要它做什么，在学会手眼配合的过程中，会被这个系统识别精度之高延迟之低所震撼，以至于觉得自己好像开发出了一种超能力。

不过，稍微使用一段时间，就会发现不少的问题。比如虚拟键盘的设计，比如窗口的控件太小用眼睛去选择很累，比如和其他 Apple 设备的互联互通还不够好等等。

这里以图形化操作系统最基础的工作「窗口管理」深入一下。

说它是你想要留下来的实习生写的，是因为目前的实现在实用和酷两方面都做得不错。用户刚刚开始感受一个离自己面部如此近的窗口时，会像我们读中学的时候把《足球世界》附送的海报贴到自己房间墙上一样兴奋，并且会很快贴得满墙都是。

如果去看网上的评测，会发现很多人都扔了一堆一堆的窗口，甚至有人给自己的不同房间扔下一些不同的窗口，比如卧室看片，客厅办公。

说它是实习生作品，是因为用户跟窗口做的交互比海报复杂得多。 和 iPadOS 显然经过仔细考虑的窗口管理相比，很快就会因为下面的事情感到痛苦：

• 我们实际上工作的时候往往需要在不同的窗口里来回切换，AVP 上寻找和定位自己想要去的窗口非常困难；
• 一些已经是标准的窗口行为，比如「隐藏」、「最小化」等，在 AVP 上面还没有实现；
• 当窗口内容比较多的时候，下面哪个拖动和关闭的横条很难被找到；
• 我还可以说十五条；

结论： visionOS 还不能用来办公。不仅仅是不能用来写程序，我尝试这篇日志在里面敲出来最后都放弃了（因为我写的过程中要查各种东西，还常常要处理别的事情，窗口切换和输入效率都太低了）。当然：

• 作为 FITURE 人，其实是理解这里面的难度的。小屏（比如手机）和大屏（比如电脑、电视机）上窗口切换实际上已经有工业标准了。在中等大小的屏上窗口如何管理其实有很多难题，特别是穿戴设备还会涉及到交互方式不同且用户在不断移动；
• 这个实际上也符合 AVP 自己的发展阶段（生产力还不是重点，比如和 macOS 打通也做得略等于无），所以长期来看可能是比较乐观的。

开发者视角

2008 年 7 月，iPhone 到了第三代，Apple 推出了应用商店，上面有大约 500 个应用。

AVP 推出时就有应用商店，上面大约 150 个应用。

iPhone 在应用商店发布后经历了 App 的指数级增长（两年后的 2010 年就有十万个应用），虽然早期的 SDK 也跟今天 visionOS 的一样糟糕，所以看起来 AVP 应用增长会比较乐观。

但 AVP 应用市场未必有指数增长。

因为 iPhone 和 AVP 开发上一个比较大的区别是，手机软件和之前的桌面软件一样，都是平面程序。而 XR 领域涉及 3D，主要的开发团队和人员，都是通过使用相对成熟的游戏引擎（比如 Unity）做这部分工作。

所以现状是 Apple 生态内的开发工具（XCode、SwfitUI 等），主要都是面向平面程序开发，新增的 RealityKit、 ARKit、RealityComposerPro 等工具在 XR 行业内比较冷门。

反过来，XR 领域的资深开发者，又对 Swift、XCode 这套工具链比较陌生。

因此在 AVP 上面做游戏或者说一般意义上做任何涉及 3D 的开发，其实是需要在两个技术栈选一个：

• Native stack：XCode、Swift、SwiftUI、RealityKit、RealityComposerPro…
• Unity stack：Unity、C#、XR SDK、PolySpatia…

除此之外，进入 AVP 的开发，还需要 Apple 芯片的机器最少 16GB 的 RAM 和 512GB 的硬盘。XCode 下的 AVP 模拟器从目前来看支持除开 SharePlay 和 Personas 之外的所有功能，因此不需要人手一个 AVP 真机。

选择 Native stack：

• 好处：启动比较便宜（100 美金的苹果开发者账户）；
• 缺点：学习成本比较高，并且不能跨平台，比较适合跟 Apple 生态绑的比较紧（比如同时开发一个应用的 Apple Watch、iPhone、iPad、AVP 等各种平台的版本）的团队；

而选择 Unity stack：

• 好处：可以利用 Unity 实现一定程度这里说一定程度，是指 Unity 为 AVP 开发的那个 Polyspatial 还很不完整，并且进度受到 Unity 裁员的影响一直不及预期。 的跨平台；
• 坏处：除开上面的费用，还需要一个 2040 美金的 Unity Pro license。比较适合想要一套内容在多个 XR 平台上变现的团队（实际上以目前 AVP 的量，大团队肯定还会惦记着 Quest）；

无论选哪套的团队，要具备生产力都还需要一些时间。所以短期内，应用市场很难有大规模的上架。

Thoughts

Apple 虽然做了个 VR 头显，但看上去基于对 AR 的执念，选择了和 Meta 完全不同的方式去建生态：游戏在里面重要性没有那么高。

但这个差异背后核心的原因恐怕不是理念不同，而是身位不同。

Meta 本身没有生态，它做新东西新体验，元宇宙、VR/MR 游戏、3D 内容，来构建生态：所以它短期内核心是把出货量拱上去，然后支撑那些 Unity 开发者在 Quest 上赚到钱。

Apple 本身有庞大的生态，它可以先兼容 Mac、iPad 甚至手机上的一些应用，把大屏看片、大屏办公往前稍微推进一下，就能让一些开发者「赚到额外的钱」。所以它短期内的核心任务是让 AVP 和 Apple 其他设备互联互通，包括开发者工具链的互联互通。

结论： 作为创业团队，我们不要在 Apple 做好 Unity 兼容前上去搞游戏，也不要在 Quest 就是个娱乐机的今天上去搞应用。也许有天两条路会交叉，但那只跟那时候还活着的团队有关系。