应用层面将macOS和iOS合并是怎样的体验?

Fighting

去年年底知名用户自动化专家（User Automation）Sal Soghoian 从苹果离职。Soghoian 是一名用户自动化专家、作家和音乐家。上世纪 90 年代主要工作于出版业，并发现了用户自动化的强大。作为顾问，他编写了许多脚本文件，允许企业通过自动执行繁复的计算机任务来节省资金和时间。他还乐于分享自动化脚本，于各地宣讲自动化的强大之处。
他于 1997 年 1 月加入苹果，作为一名自动化技术产品经理一直任职到 2016 年 10 月。在苹果公司，他推动了广泛的用户自动化技术，包括：UNIX CLI（shell、python、ruby、perl）、系统服务、JavaScript，AppleScript、AppleScriptObj-C、Scripting Bridge、Automator、Apple 配置器、iTunes 工具、Dictation 命令和应用程序脚本支持的照片、iWork、Finder、邮件、备忘录和其他苹果应用程序。
最近他发表了一篇文章——App Extensions Are Not a Replacement for User Automation（应用扩展不能替代用户自动化），在 iOS 社区引起了广泛的关注和讨论。iMore 资深编辑 Rene Ritchie 就以这篇文章为基础，讨论了从应用层面去合并 macOS 和 iOS 的话题。全文如下：
苹果前自动化专家 Sal Soghoian 最近在文章里这么写：接下来让我们做一个思维的实验：假设苹果决定把他们的工程资源都集中到一起，建立应用小组，这个小组专门开发应用的 iOS 和 macOS 版本。
基于我（Rene Ritchie）自己的理解，这应该是最近软件工程部门中一种很流行的做法，其背后的理念其实已经不新鲜了。一直以来苹果公司内部有一个 CoreOS 小组，他们的任务就是开发 iOS 和 macOS 非常重要的底层支持技术。它们拥有相同的基础上，所以继续以尽可能统一的方式去建设这个基础就有了很重要的意义。
同样地，还有一些全新开发出来的技术也是同时为这两个操作系统设计的。苹果公司前几年推出的 Swift 编程语言就是例子之一，它体现了未来开发者会如何为 macOS 和 iOS 进行编程。苹果公司去年推出的 Apple File System（简称APFS）也是一样，它可以部署在 Apple Watch 至 Mac Pro 等所有苹果产品线上。
如今内置应用层面也是一样的。一代 iPhone 和 iPad 的诞生不易，苹果需要付出很多的努力，建立专门的团队，进行大量的资源分配。在这几年里我们看到差异渐渐突现。几年前苹果决定让高级副总裁克雷格·费德里希(CraigFederighi)负责旗下的软件工程，现在在应用上苹果也采用同样的战略。从代码的层面上来说，Safari 就是 Safari，邮件就是邮件，信息就是信息，日历就是日历。
虽然一款应用在 iOS 和 Mac 上使用同样的名字，可是 iOS 版和 Mac 版本均有其各自的代码基础，而苹果此举不是为了突出 iPhone、iPad 和 Mac 的差别，而是希望应用的界面能够最大程度上为不同平台的交互模式提供支持。这就是终端用户体验——界面和交互模式，其他东西都被隐藏在底层。两个东西它们之间的相似点越多越好，因为这能提高兼容性和效率。
iPhone 和 iPad 仍然是针对直接操作优化的多点触控设备，是为现代主流社会而重新想象的移动计算器，它们便携易用。而 Mac 也仍然是鼠标和指针系统，是为那些仍需要它们的任务而生的传统计算机。
理想情况下，iOS 和 macOS 仍然会是互利发展的两个平台，iOS 能够受益于 macOS 深厚的根基，而 macOS 则会继续因为 iOS 的创新而得到发展。可惜，这真的只是一个理想情况下的假设而已。有时候，从短期来说，我们得到的是能够在两个平台上都运行的子集。而从长期来说，我们能够得到的可能就是苹果选择在其中添加的、促进两个平台进一步发展变化的任何东西。
在这里我们就不详细讨论 iWork 中的回流了。我们可以看看 Sal Soghoian 在文章中是怎么写的：保留应用在两个平台中都有的特性，同时删除掉那些被认为是需要额外资源的特性，其实这种做法看起来还是很符合逻辑的。当然在这方面自动化是会被人们拿来进行对比，很多人认为，在 macOS 中应用扩展是等同于用户自动化的，或者说前者是可以被后者所替代的。在这里我所说的用户自动化指的是 Apple Event scripting、Automator、Services和UNIX 命令行公用程序等。

我仍然认为 iOS 8 的 Extensibility 扩展性是这个平台发展史最重要的一项开发之一。它在支持可互通操作的同时保护了用户隐私和安全。通过 Share Sheet 以及其他表现形式，扩展性极大地促进了系统的感知速度，让一切变得简单方便。但扩展性并不在自动化的范畴之内。
Workflow 这款 iOS 应用能够证明“真正的”自动化在 iOS 平台上会有多强大。用户可以通过扩展性来访问它，但这还是不能让扩展性具有自动化特性。
我不想看到苹果在系统层面上“复制粘贴”Worklow，我更喜欢的是在 iOS 内置自动化。表面上看来这是一个利基特性，但 iOS 的影响力足以让整个利基特性变成主流特性。
Sal Soghoian 在文章中还写道：也许现在不管是苹果还是整个行业，在用户自动化和应用扩展的问题上，我们需要考虑的不是二者选其一，而是要做到二者兼有。要支持新的跨平台自动架构（这个架构可能命名为“AutomationKit”）的发展，那就需要将用户自动化“面向所有人开放”的特性和开发者插件的集中式特性结合起来。应用扩展可以成为新 macOS 系统服务，Automator 可以将工作流程以 Extensions 扩展的形式保存起来。AutomationKit 甚至还可以将 Apple Event 整合其中，这样它就能够支持现有的 macOS 自动化工具。
有时候我（Rene Ritchie）觉得苹果就是担心把 iOS 做得太过复杂——太像 macOS——所以他们花了好长的时间去简化复制粘贴、拖放这样的功能。我可以理解苹果的心情，但是在我看来，iPhone 和 iPad 应该是能够不断演变发展的，即使哪天Mac不存在了也能够继续发展（反之亦然）。他们唯一的目标应该是做到最好。像菲尔·席勒曾经说过的——iPad 很好所以它给Mac带来了压力，而 Mac 也很好所以它也给 iPad 带来了压力。
有一个小组专门负责两个平台上的 Safari、邮件和信息等应，我觉得这样的安排挺好，这也意味着以后在 Mac 上我就再也不用看到“已用烟火效果发送”这样的东西了。不过同时我也希望最终，这个小组能够以前所未有的方式去提升两个平台的内置应用。

Everley

顶贴不认真，大脑有问题。

Christ

楼主，涨姿势呃。。。。。。

Burnell

这个貌似最近用得上了。。

Christian

是爷们的娘们的都帮顶！大力支持

Olive

路过的帮顶

Dave

为保住菊花，这个一定得回复！

Alma

小白一个 顶一下

Kent

本宫准楼下的继续跟帖。。。

Phoebe

高手云集 果断围观