春节过去，转眼已经是三月。随着 iOS 11.3 的发布临近，iOS 11 的更新周期基本进入收尾阶段。按照正常规律，苹果应当在今年六月的 WWDC 2018 上公布 iOS 12 的消息。虽然今年 WWDC 的会址和会期尚未公布，但根据观察，圣何塞 McEnery 会议中心（去年 WWDC 会址）在六月后三周已经全部被其他活动预定，只剩下 6 月 4 日（周一）至 8 日（周五）这一空档，这也与苹果往年召开 WWDC 的时间基本吻合，表明那一周有较大可能就是今年 WWDC 的召开时间。
那么，iOS 12 有哪些值得期待的更新呢？可能令人有些惊讶的是，今年 iOS 消息的重点，并不是 iOS 12 会有什么新功能，反倒是不会有什么新功能。供职于彭博的苹果消息达人 Mark Gurman 在 1 月 30 日和 2 月 12 日先后刊发报道，指出苹果出于保证软件质量考虑，将会推迟一些重要 iOS 特性的发布，包括新主屏设计、iPad 多任务增强等一些关注度较高的功能。如果消息准确，今年的 iOS 12 将像它的内部代号「Peace」那样，更注重求稳而不是求新。
当然，这并不意味着 iOS 12 就将是一个毫无看点的迭代版，但它可能确实将标志着苹果软件更新策略的一次重要转变。我们结合目前已有信息、背景资料和主要评论，整理如下了一些你可能关心的问题，希望能让你对苹果这次「减速慢行」的前因后果有一个直观的认识。
根据 Bloomberg 的报道，iOS 12 可能搭载的新功能包括：
而下列功能将可能被推迟到 iOS 13 发布：
彭博报道的原标题《苹果计划结合 iPhone、iPad 和 Mac 应用，打造统一用户体验》已经简要地回答了这一问题。
然而，这并不是一个非常准确的表述。根据内文，苹果这一代号为 Marzipan（「杏仁糖膏」……）的项目旨在让开发者通过一次开发，设计出能够同时适用于 iOS 的触摸屏和 Mac 的鼠标操作两种界面的应用程序。可见，这项新功能的主要目的并不是给用户提供一个全平台统一的体验（手指触摸和鼠标指点本来就是两种不同的「体验」），而是给开发者提供一套一箭双雕的开发框架，使其能以更小的成本开发出支持两大系统的程序。
实际上，一个应用是否「跨平台」，完全是由开发者决定的，并不依赖于苹果的特殊支持。很多热门应用，如 Ulysses、Things 等，从一开始就同时有 iOS 和 Mac 版，并以此为卖点。乔布斯在 2007 年发布初代 iPhone 时，就直接宣称「iPhone runs OS X」，这也是那场发布会中掌声最热烈的场合之一。
问题在于，现有条件下，如果开发者想让应用「跨平台」，必须针对 iOS 和 macOS 分别开发一次。做为一家人，iOS 和 macOS 平台不可能是泾渭分明的，其应用在底层上有很多相通之处；两者主要的隔阂，在于与用户直接打交道的 UI（用户界面）方面。
macOS app 的用户界面使用 AppKit 框架构建，这是一个十分「古老」的框架，其历史可以追溯到乔布斯在上世纪 80 年代参与开发的系统 NeXTStep（这也就是为什么 AppKit 中很多对象和函数的名字还以 NS 打头）。
而 iOS 从诞生之初就采取了一种「另起炉灶」的思路，采用了另一套名为 UIKit 的框架。UIKit 在很多方面明显继承了 AppKit 的功能，但少了很多历史包袱，也不用考虑一些只有 Mac 应用需要考虑的问题（如多窗口）。因此，两者在具体使用上并不像表面看起来的那么类似；一个只接触过 UIKit 的开发者，在上手 AppKit 时仍将面对较高的学习成本。
彭博的简短报道并没有说明苹果将怎样整合两个平台的开发，但顺着上文的逻辑，一个自然的做法就是通过某种方式将 AppKit 和 UIKit 整合起来，或者干脆像当初放弃 Carbon 那样放弃 AppKit，用 UIKit 一统两个平台。
UIKit 确实具有一定的跨平台潜力。例如，用于 Apple TV 的 iOS 变种——tvOS 上的 app，同样是用 UIKit 开发的，但 tvOS 的操作其实更接近于 Mac——用户不是直接用手指与屏幕上的元素互动，而是用遥控器顶部的触摸板控制屏幕上的「焦点」，并通过点按操作来打开和确认。为了适应 Apple TV 的这种交互逻辑，苹果扩展了 UIKit 的功能，为其增加了一套称为 Focus Interactions 的交互机制。从实现效果来看，UIKit 在 tvOS 上并没有显得水土不服；因此，苹果将其再次扩展并反向移植到 macOS 上也是完全可行的。
目前暂时没有更多关于跨平台 app 具体呈现形式的消息。
毫无疑问，最简单粗暴、但也是最差的一种情况，就是直接在 Mac 上显示一模一样的 iOS app 界面。作为用户，我们显然不愿看到这种聊胜于无的实现方式。
不过，macOS 里其实已经「潜伏」着一个官方出品的跨平台 app，那就是内建的照片 app。早在 2016 年，就有人发现，这款随 El Captain 系统一起问世的新 app 虽然长着一张 Mac app 的脸，却有一些与 Mac 格格不入的行为特性：照片不能被直接拖拽到 Finder 以外的任何地方（Safari 都不行！），鼠标连击并拖动将引起一次拖拽操作而不是多选（后者才是标准 Cocoa 程序的应有反应），再加上非标准的快捷键设定，怎么看都像是一个跑在沙盒中、以触摸操作为主的 iOS app 的仪态。
调查发现，Mac 版照片 app 的界面并不是由 AppKit 搭建的，取而代之的是一个名叫 UXKit 的未公开框架。这个框架不仅名字和 iOS app 所用的 UIKit 只有一字之差，而且涉及的类（class）名和 UIKit 也是一一对应的。这个苹果自己新创的「跨平台」解决方案，或许就是 Marzipan 计划的雏形。
不过，UXKit 目前还是一个私有框架，并无任何文档说明其用途和功能，实际应用除了照片 app，就只有 Apple Store 展示机上用来显示型号和定价的 demo app，并不确定苹果是否准备把它开放给开发者。而且，从照片 app 的口碑看，UXKit 的现状并不能让人满意。违反 Mac 平台逻辑的操作、较低的运行效率、奇奇怪怪的 bug——倘若苹果真的要委以 UXKit 打通平台的重任，这座「桥梁」本身恐怕还需要多加打磨。
这么做的主要目的可能是让 iOS 平台「反哺」Mac 平台，改变后者目前「应用荒」的局面。
目前，Mac 平台针对开发者吸引力不足、缺少新鲜的高质量 app 是不争的事实。这一方面因为 iOS 平台日渐强势、普通用户越来越多地倾向于用移动设备而不是桌面设备完成日常任务，另一方面也是因为 Mac 平台应用开发门槛高而产出有限。特别是苹果的官方应用分发平台 Mac App Store 自 2010 年推出以来，从未达到过官方最初所预期的影响力，相反因为限制多、对开发者不友好而先后流失了很多重量级应用。在 iOS 上的 App Store 不断进化，对开发者和用户都作出大量改进的同时，Mac App Store 却还停留在多年前的老样子，处于荒废状态。前不久，Twitter 宣布即时停止官方 Mac 应用的开发和支持，在遭遇广泛吐槽的同时，再次引发了人们对 Mac 应用生态前景的担忧。
如果跨平台 app 这一新策略能够成功，iOS 应用开发者将有很大动力将应用移植到 Mac 平台——既然不需要花费多少额外的开发成本，谁会拒绝赚两个市场的钱呢？不过，由此带来的一个担忧是，这会不会导致 Mac 平台涌入大量设计潦草、功能残缺的「放大版」iOS 应用？这当然是合理的疑问，但似乎「有没有」比「好不好」是更高顺位的问题；另外，iPad 应用的发展历程也证明：只要有好的硬件和市场基础，生态的建立只是时间问题。
根据报道，苹果将把目前「一年一更」的 iOS 升级周期调整为两年。
调整后，苹果仍将每年发布一次新版 iOS 系统，但工程师有更大自由决定是否将一些新功能暂缓发布，继续打磨后留待次年推出，而非为了迎合每年一次「重大更新」的口径而疲于赶制新功能。
据悉，这项变更是由负责软件开发的高级副总裁 Craig Federighi 在今年 1 月告知团队工程师的。其目的是为了降低苹果软件团队的开发负担，留出更多时间打磨功能和修复问题，同时改善苹果近年软件质量和稳定性下降的不利现状。
尽管从未被公开承认，很多事例都表明苹果这种更新周期正在成为一种负担，其在发布软件时承诺的许多功能最终都被推迟发布。例如，iOS 11 发布时宣称将支持通过 iCloud 在各设备间同步 iMessage 消息，但至今（2018 年 3 月）都未能兑现。软件更新的压力甚至反过来影响了硬件的日程。原本定于去年年底出货的智能音箱 HomePod 被推迟到今年初，据悉就是因为一些软件问题未能解决；并且，其发布会上宣传的两台配对实现立体声、AirPlay 2 等软件功能，目前仍处于跳票状态。
另外，苹果的软件质量也成为人们担忧的问题。年初，Jason Snell 邀请了 50 位圈内人士对苹果去年在软硬件产品线上的表现进行了评分。其中，软件质量一项不仅在各分项中的得分最低（2.7/5.0），也是相比前一年度下降幅度最大的（-0.7），最终仅得到了 C- 的评级，几乎是「不及格」。从实际表现看，iOS 11 发布以来，已经依次出现了计算器按键连按、键盘拼写纠正乱码、12 月 2 日设备自动变砖等严重性不一的 bug，让很多用户十分恼火。这还没有算上遭遇广泛批评、甚至为苹果引来各国官司的电池门问题（虽然这与其说是软件问题，不如说是透明度问题）。如何改善软件稳定性，挽回形象，确实是苹果亟需思考和解决的。
可能的原因包括内部和外部两个方面。
从内部看，苹果为了实现紧凑的更新周期，能用于打磨功能和修复问题的精力是十分有限的。根据现状，苹果在每年 6 月的 WWDC 发布会上公布当年的新操作系统（包括 macOS、iOS 及后者衍生的 watchOS 和 tvOS），同时放出第一个开发者测试版，并利用之后的整个夏天进行测试和迭代，直到正式版系统随当年秋季新品一起面世，随后就将进入下一大版本更新的开发周期。由此计算，留给开发新功能的时间不过寥寥数月，同时并行的还有修复旧版问题的任务。相对于 iOS 目前的复杂度和体量，这样的开发时间确实显得有些紧张了。
从外部看，苹果不断提高的用户基数放大了问题暴露的可能性和软件故障的影响范围。根据统计，iPhone 的活跃设备数在 2017 年 2 月已有 8 亿台，并可能在 2019 年达到 10 亿台。换句话说，iOS 的软件问题可能并没有变得比以前更多，而是更容易暴露了。这当然不是为苹果辩护的理由，但也可以为分析提供一个角度。
这种说法并不准确。
首先，苹果并不会推迟 iOS 12 的发布，而只是将一些原本计划今年推出的功能推迟到明年。不出意外，我们仍将与之前的十年一样，随新 iPhone 上市一起用到正式版的 iOS 12。
其次，虽然我们已经习惯了操作系统的「一年一更」，但如果将镜头拉远，这种高频率更新只是随着 iPhone 的问世才逐渐称为新常态的，是移动市场激烈竞争和快速发展的产物。在此之间，OS X（macOS）的更新周期不仅长得多，也很不稳定。Snow Leopard (2009) 与 Leopard (2007) 隔了 22 个月，之后的 Lion (2011) 隔了 23 个月，几乎是两年一更。
实际上，从 2016 年开始，iOS 的更新策略已经悄然发生着变化。一些原本只属于个位数版本重大更新的特性，开始被「下放」到小数点更新中，这可能正是考虑到大版本更新功能过多造成的开发负担。一种新的规律是：每年 9 月底，新版 iOS 随新 iPhone 的上市一起发布；大约一个月后，x.1 版本发布，补正前一版中的一些疏漏（如 10.1 的人像模式、11.1 中 3D touch 多任务手势的回归）；年底前后，x.2 版本发布，再次增加一些小功能以完善体验（如 10.2 的 TV app、11.2 的 Apple Pay Cash 和 7.5W 无线快充）；次年三月前后的 x.3 版本则是一个「小型」重要更新，增加一批用户明显可感的功能，如 9.3 的 Night Shift、内建 Notes app 加密，10.3 的 APFS、App Store 评论机制改进，11.3 的电池检测和性能选项、ARKit 对垂直平面的支持等。
这不会对用户使用产生显著影响；即使有，也是软件质量提升带来的积极影响。
对关心科技动态、热爱尝鲜的用户来说，iOS 功能更新减缓似乎是一种「损失」。但「损失」是相对于「获得」而言的，如果一项功能从未推出，那仅仅推迟发布也称不上什么损失。更何况，绝大多数的普通用户并不关心系统的功能迭代，相反可能对「升级」一事抱有恐惧和抵触情绪——升级就意味着变化和重新学习。与升级带来的新鲜感相比，他们对软件故障造成的不便更为敏感。如果苹果通过放慢新功能推出步伐，确能争取到更多打磨软件的时间，那么对于用户显然是利好的。
目前，圈内人士对于苹果此次策略变更的评价也基本上是正面的，认为可以接受为提高稳定性而牺牲提早体验新功能（例如 ATP 第 262 期和 Upgrade 第 181 期的相关讨论）。不过，最有意思的意见倒是来自微软前高管 Steven Sinofsky。Sinofsky 曾负责过 Windows、IE 等微软拳头产品的开发，后来跳槽到科技风投机构 Andreessen Horowitz（a16z）。他用长达 44 条的推文，从公司发展的角度表达了对苹果此次策略变更的支持。他认为，软件开发的速度、质量、功能是难以兼得的，苹果此前在平衡这几者上的成就令人瞩目。苹果目前遇到的软件质量问题，是软硬件并行开发的压力和用户数量扩大两方面因素的共同产物。将开发进度调整到合理周期，是符合经验和理性的必然选择。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。