当苹果在WWDC上发布macOS Catalina时，一个相关公告引起了Mac用户和开发人员的极大兴趣：一种将iPad应用转变为完全原生Mac应用的新方法。 这一名为＂Project Catalyst＂的项目旨在让开发人员将现有的iOS应用移植到Mac上。不过，这引出了一些问题：这对Mac用户意味着什么？这会改变为Mac制作的软件类型吗？苹果的生态系统是移动端优先吗？ 有开发人员担心：Catalyst只是SwiftUI的垫脚石，在把iPad应用迁移至Mac的过程中，开发人员可能会遇到哪些挑战？ Ars与负责在WWDC开发和推广Project Catalyst的主要成员以及已经用这种方式制作Mac应用的少数开发人员进行了交谈，向他们询问了Catalyst的工作原理、苹果软件的未来发展方向以及用户可以期待的内容等。 Mac平台在开发人员和创意人员中很受欢迎。iPhone和iPad应用商城已经成为业界最具活力的软件生态系统之一，但Mac应用商城却并非如此。 苹果试图通过使用Catalyst将iOS应用商城的一些成功应用转移到macOS上。本文将详细介绍开发人员是如何逐步使用苹果所构建的内容，以及他们面临的挑战；将分享苹果对我们所提出问题的答案，例如随着移动衍生应用涌入该平台，苹果计划如何保持Mac应用的高标准质量；从整个生态系统来看，苹果跨平台应用的长期计划又是什么。 Project Catalyst 据彭博社2017年12月报道，苹果正在开展一个项目，该项目将使得为macOS和iOS并行开发应用变得更加容易。我们今年在WWDC上了解到，推动该项目的一个主要组成部分叫做Project Catalyst，它可以相对快速地将iPad上的应用移植到Mac上。 应用开发人员现在可以开始使用集成开发工具Xcode的测试版本。为了在WWDC舞台上大肆宣传，苹果声称开发人员只需要在Xcode中打开他们的iPad应用项目，然后单击一个复选框就可以构建一个Mac应用。当然，它并不总是这样简单，但应该比你想象的要容易。 •具体运作方式 开发人员用于为iPad和Mac创建应用的许多框架都是相似的。苹果在这方面所做的工作就是弥合iPad和Mac版本共享开发框架之间存在的差异。但最大的差距是UI框架之间的差距。 开发人员使用UIKit框架构建iPad应用的用户界面和功能。与此同时，Mac有一个名为AppKit的框架，可以执行许多与UIKit相同的操作。以前，Mac应用无法运行使用UIKit制作的应用，iOS设备无法运行使用AppKit制作的应用。即使开发人员在构建Mac版本时可以重复使用iPad应用的某些部分，也需耗费额外的大量工作。 有些框架可以在一个平台上使用，但不能在另一个平台上使用。例如，在Mac上无法使用ARKit，那些想用ARKit来提供增强现实体验的开发人员需要考虑这一点。在某些情况下，ARKit会自动过滤与目标设备上不存在的功能和框架有关的代码。 某些情况下，开发人员当然可以在其代码中使用条件逻辑，根据运行软件的设备提供不同的体验和功能。但是，苹果希望保留这种方法，用于应对某种不同设备对不同功能的需求。 ＂我们希望他们尽可能少地使用条件，因为条件是不同的代码路径，＂Catalyst负责人Ozer解释道。＂而且我认为与条件相关的是API和功能，它们实际上只是Mac版本。＂ 苹果表示，许多开发人员构建的第一个第三方Catalyst应用，能在24小时内在Mac上运行可接受的构建版本。但每个应用都面临着一些独特的挑战。 开发人员的经验 少数苹果开发人员已经在使用Catalyst构建第一个第三方应用，他们在WWDC上展示自己的应用。为了获取更多信息，Ars与开发人员讨论了三个不同的应用，即开发人员如何成功地将iPad版本的Twitter、TripIt和Asphalt 9:Legends带到了Mac上。 •Twitter Twitter在2016年停止了对其Mac应用的支持。虽然一些第三方Twitter应用仍可用于macOS，但该公司继续将Web视为Mac用户使用社交媒体平台的主要方式。 今年在WWDC上详细介绍Catalyst时，苹果透露Twitter将重返Mac。苹果邀请Twitter的开发人员通过Catalyst构建原生Mac Twitter应用，而且Twitter支持Mac升级到与iPhone、iPad和iPod相同的水平。 •Asphalt 9:Legends 你可能认为移植像Asphalt 9:Legends这样图形密集型3D游戏会遇到额外的障碍。但这并不完全是Gameloft Barcelona图形工程师Alex Urbano和引擎软件工程师Manu Ruiz所描述的那样。 ＂这个过程非常简单，在新的Xcode上打开当前的iOS项目，标记新的macOS目标选项，并进行编译即可，＂Ruiz说。＂显然，它在第一次尝试时不起作用，因为我们的一些库在非移动设备上不受支持，例如运动控制；而且一些第三方库没有为macOS和x86-64平台做好准备。在重构了一些代码之后，我们设法在大约24小时内编译并运行了整个Asphalt代码库。＂ 关于图像方面的调整，Urbano说道：＂这很简单。我们必须调整一些着色器的精度，使它们在高端Mac中以更高的分辨率正常工作，以便进一步提高性能。我们稍微改变了Metal缓冲管理的工作方式，这允许我们实现一些在其他平台中不存在的效果，同时保留60fps目标的原始分辨率。＂ •TripIt iOS开发人员Rich Shimano向Ars发送了一封电子邮件，其中列出了将旅行计划应用TripIt从iPad迁移到Mac的每个详细步骤： 在Xcode中构建当前的iPad应用，只需要几次迭代即可识别并删除不支持资源上的各种依赖项，例如特定电话呼叫的框架或尚未构建以支持MacOS的第三方iOS SDK。 遍历所有用户流和数据同步方案，并关闭不支持或不可用的功能。 在Mac的多窗口点击环境中定制UI以提高用户效率。 至于在过程中会遇到哪些挑战，Shimano表示，最重要的是＂旧的代码库依赖于已弃用的苹果框架和API以及旧版本的Swift，可能需要对现在的API进行重大改写＂。此外，＂不具有多任务友好性和灵活布局的iPad应用可能需要进行大量重写，更多地依赖于自动布局，以便在桌面窗口上进行适当渲染，即使在单个用户会话中，这些窗口的大小和宽高比也会有很大差异。＂ 苹果保证Mac应用质量达到桌面级 苹果及其合作伙伴开发人员表示，Catalyst能将iPad上的应用轻松导入macOS，但用户对Mac上未来应用质量的担忧仍然存在。 Project Catalyst是建立在macOS 10.14 Mojave之上，这是该公司去年推出的macOS年度重大升级。该公司推出的新闻、股票、语音备忘录和家庭应用也是建立在这一系统之上。 Mac高级用户担心，将iPad应用迁移至Mac的简单途径将使开发人员无法提供过去用户在Mac上享受的功能，以及功能强大且全面的桌面应用。一部分原因是因为移动应用往往侧重于较窄的任务，并且它们通常不具有与良好的桌面应用一样强大的功能集。另一部分原因在于，如果他们使用AppKit从头开始构建原生Mac应用，UIKit和Catalyst都不会为Mac开发人员提供他们可以访问的全部功能和框架。 当然，我们采访过的苹果团队成员并没有此类担忧。Ozer表示，首先，UIKit确实为开发人员提供了访问AppKit的权限。＂当你将UIKit应用带到Mac上时，我们会大量使用AppKit，例如，当你使用工具栏、触控条或菜单时，这些都是AppKit，＂他说。＂因此开发人员不必直接使用AppKit，但他们可在其UIKit应用中使用AppKit。＂ 当然，苹果认同AppKit是提供高端Mac应用的方式。苹果开发人员关系高级总监Pruden说，她认为Catalyst是为开发者提供了选择，但那些创建强大桌面应用的团队将知道它是否适合自己的产品。 •专用应用与广泛应用 Benjamin认为有多种类型的应用，并且它们在平台上并不相互排斥。这是了解苹果新方法的关键。他说：＂我认为Mac上一直是些庞大而复杂且功能强大的应用，它们的范围十分广泛。我认为iOS上的应用设计精良，本质上更有针对性。现在人们知道这些东西是什么，他们也希望在电脑桌面上拥有这些简单易用的体验。虽然网页可以做到这一点，但应用带给用户的体验感更有优势。现在你习惯于在手机和iPad上使用相对较新的体验，那为什么不能将相同的体验迁移到Mac上呢？＂ •为什么在有Web应用时仍要制作原生Mac应用？ 虽然苹果和微软正在花费相当大的努力来吸引开发人员为他们的桌面操作系统制作原生应用，但谷歌正在根据不同的财务激励来采取不同的策略。 谷歌新兴的Chromebook本质上是21世纪的虚拟终端，从头开始设计用于Web浏览体验和使用基于Web的应用。但Mac有着悠久的专注于原生应用的传统。苹果的开发人员为什么要通过从iPad移植软件而不是让Mac用户在Safari或Chrome中访问他们的Web应用呢？ Benjamin认为这与性能有关。＂应用作为原生应用，与用户在Web上体验的性能截然不同，＂他说。此外，＂还有另一个好处，这样做能让用户在不同设备上获得相同的体验。＂ macOS和iOS：先有鸡还是先有蛋 鉴于iOS和iPadOS似乎是这种新模式的核心，我们询问苹果是否认为iOS（和iPadOS）是其生态系统的主要开发平台。苹果是否希望开发人员首先支持移动设备？ Pruden回答说，不同的设备和操作系统适用于不同的用例，对于开发人员来说，没有哪一个平台比其他平台更重要。 ＂从数量上来看，显然iPhone应用是最多的，＂Pruden继续说道。＂但我不认为我们会把数量作为投放精力的主要考虑因素，它也不会影响我们决定下一步支持开发人员的方式。＂ 然后是SwiftUI。虽然Catalyst旨在帮助开发人员将已有的iPad应用带到Mac上，但苹果建议将SwiftUI视为开始新的跨平台项目的起点。在这种情况下，首先要开发iOS或iPadOS，然后再开发macOS，就像开发所有原生苹果平台一样。 •了解SwiftUI 对于WWDC的开发人员而言，Catalyst并不是其唯一的重要公告，此外还包括SwiftUI。SwiftUI是一个框架，旨在使用Xcode和苹果的Swift编程语言＂在每个平台上声明应用的用户界面和行为＂。 我们从苹果开发者处了解到，SwiftUI提供视图、控件和布局结构，用于声明应用的用户界面。该框架提供事件处理程序，为你的应用提供点击、手势和其他类型的输入，以及管理从应用模型到用户将看到的交互视图和控件的数据流。 你可以将SwiftUI视图与来自UIKit、AppKit和WatchKit框架的对象集成，以进一步使用该平台特定的功能。 虽然很难量化Swift的采用速度，但工程师和macOS及iOS开发人员Andrew Madsen最近提出了一种可行的方法，来估计Swift在苹果应用商城中广泛运用的程度。 Madsen发现42%的应用使用了Swift，但是当他撇去游戏应用时，这一比例上升到了57%。实际上，列表中没有一个游戏使用Swift，因为它们大多数是用Unity等跨平台工具编写的。 ＂一开始，只有少数应用使用Swift；但三年后，有约一半的应用在使用Swift，这也表明了苹果在引入新语言方面做的很不错，＂他总结说道。这对SwiftUI来说是个好兆头。 至于开发人员方面，Shimano表示，TripIt在使用SwiftUI时已有一些重要的促进因素，独立于Mac应用。也就是说，它允许TripIt团队与watchOS应用共享公共代码以改进功能校验，并将简化和减少显示快速变化的旅行数据所需的代码量，例如航班延误和更改登机口。 ＂但是，我们正在尝试特定的桌面视图，这些视图有可能找到支持iPad甚至iPhone的方式，＂他补充道。＂通过在单个代码库中编写SwiftUI，我们应该能够通过Catalyst快速轻松地为我们的iPad和iPhone应用带来增强功能。＂ Twitter的O'Brien说：＂现在，我们专注于将非常庞大的代码库与许多传统的UIKit接口一起移植到Mac上。目前，Project Catalyst对我们来说是一个很好的解决方案。＂Twitter团队对SwiftUI带来的可能性感到非常兴奋，并且该公司愿意在未来采用SwiftUI来获取新功能。 制作Mac应用的三种方法 总结一下，现在有三种不同的方法可以使用苹果自己的工具和框架开发原生Mac应用： •使用UIKit构建iOS或iPadOS应用，然后使用Project Catalyst将其转换为macOS应用。根据苹果的说法，这是针对那些迄今为止在移动设备上更常见而不是在桌面设备上使用的专用应用。 •使用AppKit及相关框架和API为macOS构建应用，充分利用平台的全部功能。苹果表示，这适用于传统的重型Mac专用应用。 •使用SwiftUI从头开始为多个苹果平台构建应用，SwiftUI可与其他现有框架配合使用。这是苹果期望开发人员在未来为多平台应用所做的事情。 一些Mac用户认为苹果的关注点在iOS上，从而将Mac降级为替补角色。但是对于iOS、iPadOS、watchOS和tvOS而言，Mac必须取得成功。Catalyst致力于支持Mac，同时保持与公司移动平台的紧密联系。从长远来看，这将如何发挥作用还有待观察。大家需要为苹果、开发者和用户所希望看到的最佳结果做准备。 如果你看了苹果产品的营销，你可以清晰地了解到各类产品的目标客户。如今，大多数Mac主要销售给创意人士和专业人士，从作家到平面设计师，从视频编辑到开发人员再到3D动画师。那么将Mac视为创作者的平台，将iOS视为消费者的平台，从定义来看，后者的平台更广。但是，如果用Xcode为Mac开发的应用不能得到关键目标客户的青睐，那么从长远来看，移动平台也无法生存下去。 所以苹果面临的第一个问题是：先有鸡还是先有蛋？Mac还是移动端？要么两个都要，要么两个都不要，二者是共生关系。 但是如果一些iOS软件来到Mac上，会不会出现用户对两者都不买帐的情况呢？添加了铃声就是一个很好的桌面应用吗？这些情况是否会发生不仅取决于开发人员，还取决于苹果如何听取和回应开发人员在建立Catalyst和SwiftUI过程中提出的反馈。 苹果首席执行官蒂姆·库克此前向用户和开发人员保证，苹果致力于将Mac、iOS和iPadOS打造为真正独特的平台。现在，苹果依然如此。但是，该公司的用户和开发者社区正在进入未知的领域，较之前，这些平台很快会紧密联系在一起。这样做的有益程度到底如何，还将拭目以待。