果园鸽鸣

A version of this article appears on Aug. 5, 2022 on SSPAI as a member-only post. Learn more or subscribe

8 月 3 日，Bloomberg 撰稿人、苹果小道消息达人 Mark Gurman 发文（付费墙，存档版本）称， 苹果计划将 iPadOS 16 的发布推迟到十月，打破此前 iOS 与 iPadOS 同步发布的惯常模式。

Gurman 称，延期的部分原因在于 iPadOS 16 的重要新功能「台前调度」（Stage Manager）的开发进展落后于预期。

如果你还不熟悉台前调度这个功能，简单来说，它允许同屏显示多个应用窗口、调整窗口大小，并将应用布局编组、在不同组合之前快速切换；这使得 iPad 第一次具有了接近于桌面操作系统的多任务处理能力，一经宣布就受到广泛期待。

然而，自六月推出测试版以来，台前调度功能的进展并不顺利。由于故障频发、交互逻辑不明晰，台前调度目前只是看起来耀眼，并没有发挥出提高操作效率的实际效果。不仅如此，苹果还将该功能的支持范围划定为很少一部分新机，虽然试图以性能门槛为由解释，但很快就被指出各种自相矛盾之处。

Gurman 表示，通过推迟 iPadOS 的发布，苹果可以先集中精力完成 iOS 16，以便赶上 9 月推出的新 iPhone。而 iPad 新品本来就一般安排在十月或更晚发布，届时再一并推出软件更新也说得过去。

一般来说，与延期相关的消息都不会得到什么积极评价。但 iPadOS 延期的新闻传出后，圈内的媒体和开发者的反应普遍是「预料之外，情理之中」。这倒不是因为他们偏袒苹果，而是因为苹果近年来软件质量普遍受到诟病，人们宁可看到一个延迟推出的稳定版，也不愿尝鲜一个打着正式版名号的半成品。

的确，随着苹果近年硬件口碑逐渐转好，持续疲软的软件质量就显得格外不相称。在著名英文苹果博客 Six Colors 开展的苹果年度口碑调查中，圈内人士连续多年对苹果在软件质量方面的表现给出了及格线上下的评分。在少数派去年底开展的类似调查中，软件可靠性也是分数最低的一项。

iOS 要放缓开发节奏的说法也不是新闻。至少从 2016 年的 iOS 9 开始，苹果就将一些原本可以随大版本发布的新功能「下放」到小数点更新中，特别是每年春季推出的 x.3 版本。2018 年，Mark Gurman 还报道称，苹果出于保证软件质量考虑，将会推迟一些重要 iOS 特性的发布，采取一种类似「大小年」的做法，避免年年步子迈得太大。（我当时写文章介绍过此事。）

实际上，近几年来，苹果在第一个正式版中「放鸽子」已经成了不成文的规矩。iPadOS 本身就是在放鸽子中诞生的：2019 年，iPadOS 13 虽然和 iOS 13 同步开始测试，但却没有跟 iOS 13.0 一起发布正式版，而是迟到了几天，以 iPadOS 13.1 的名义发布。此后，iOS 14 时代的广告反追踪、iOS 15 时代的 SharePlay 都经历了不同程度的延期。今年，苹果更是从一开始就主动摊牌：Live Activities（锁屏动态小组件）、Freeform（共享白板）等功能要到后续版本才会发布。

此外，由于 x.0 版本非常不稳定，坊间一种常见的经验之谈，就是不要急着上车这种版本，而是等待不久后更稳定的 x.1 版。这是有据可循的：从 iOS 8 以来，各个 x.0 版本的寿命就从来没有超过一个半月，最长寿的 iOS 12.0 也只过了 43 天就被 12.1 取代，最短命的 iOS 13.0 更是只活了 5 天。

因此，iPadOS 的延期与其说是对开发周期的新调整，不如说只是将此前各种不成文的「躺平」行为公开化，通过推迟提升版本号的方式明确表达出来。虽然不免令人失望，但至少不会造成预期和交付结果的错位，某种程度来说也不是坏事。

但这次延期也可能带来一些意料之外的麻烦。正如开发者 James Thomson 在 Twitter 上指出的那样，根据苹果的政策，提交 App Store 审核的应用必须使用稳定版的开发工具编译。如果 iOS 已经发布稳定版，而 iPadOS 还在测试阶段，是否意味着只能推迟发布新版应用？由此延伸，如果 iOS 和 iPadOS 进一步分立，开发者是否会被迫再次把针对 iPhone 和 iPad 的版本分开上架，就像 iPad 诞生之初那样，推出标着「HD」「for iPad」后缀的专版？这似乎不符合苹果一直以来鼓励「通用」（universal）应用的导向；在 App Store 的授权机制仍然呆板的现状下，也将给开发者和用户双方造成很高的迁移成本。

还应当指出，无论是推迟发布正式版，还是调整开发周期搞「大小年」，都只是治标不治本的做法。即使将更新周期翻倍到两年，是不是就意味着新系统的质量能翻倍呢？恐怕未必。

正如资深用户 Howard Oakley 曾指出的，「要提高质量，最重要的方法是在整个开发过程中加强质量管理。原则上应该追求开个好头，而不是把更多的精力花在检测和纠正错误上。」Nick Heer 则援引 macOS 的历史观察到，macOS 采取过各种长度的更新周期，从最开始的几个月，到中期的一年半左右，再到近年的年更；每个阶段的大版本中，都有口碑特别好的，也都有口碑特别不好的，可见时间和质量未必相关。

我以为，要走出更新周期的困境，iOS 应该借鉴其他系统的经验，将系统更新模块化，并将框架更新、功能更新和安全更新剥离开来，为每个大版本提供更长的支持周期。

目前，苹果对 iOS 的更新策略是将功能更新和安全更新紧紧绑定在一起，并且随着下一个大版本的推出完全终止（只在罕见情况下会为老旧型号推出「特供」更新）。环顾操作系统的世界，这实际上是一种比较奇葩的做法。

iOS 和 macOS 一根同源，具有分层式的系统架构。自下而上，依次是内核和基础库、程序运行环境、用于实现各种功能的框架，以及一系列预装应用程序。因此，没有任何技术上的障碍阻止苹果在一年之后，继续为旧版 iOS 提供安全修补，甚至提供一些不涉及底层的功能更新。

同门的 macOS 一直就是这么做的。 尽管没有明文承诺，但规律上看，近年每个大版本 macOS 都能获得大约三年的支持周期。虽然一个大版本在发布一年过后，就不再获得功能更新，但苹果仍然会不时以补充更新（supplemental update）、安全性更新（security update）等名义继续修补安全漏洞（详见官方日志）。Safari 浏览器等内置软件也会在推出新版时支持前两个版本的系统。

就连苹果每年在发布会上嘲笑的 Android，也一直允许厂商在停止提供大版本更新的情况下，继续提供安全更新；Android 10 以上的版本还支持所谓「模块化系统组件」，允许厂商单独更新多媒体、网络等系统的特定部分。对于 Linux 用户，功能更新和安全补丁不能分开，简直就是歪理邪说了。

因此，只要苹果愿意，完全有条件将较为底层、更多面向开发者的框架更新和较为上层、主要为用户可感的功能更新分开，并为旧版 iOS 提供更长时间的安全补丁。这样，几部分工作都能按照各自的节奏开展，而不用为了一个共同的「年更」幻想，争取一个最大公约数。用户也得以各取所需，根据自身偏好、使用场景和设备性能选择最合适的系统版本。

但现实是，苹果即使在反复呼吁下，也只是很有限地允许用户推迟大版本更新；更多场合，都是以持续不断的弹窗和通知红点「威逼」、以新版 emoji 这样的甜点功能「利诱」用户安装新版。它似乎坚持认为，只有通过促使最多用户在最短时间升级到最新系统，才能确保自己对设备和生态的绝对控制；不仅不会借鉴 macOS 相对宽松的做法，反而有将 iOS 的政策反向推广到 macOS 的苗头。如果这种思路不改变，我们也许还是只能继续、并且越发受制于苹果的「鸽」与「不鸽」。