编者注：作者 @Amos_Wu 为时间志、Amos特斯拉和 Amos评论集等应用的开发者，有着丰富的 iOS 开发经验。这篇文章，就让作者带着我们从开发者的视角，去看看 SwiftUI 背后的故事。

SwiftUI 于 2019 年度 WWDC 全球开发者大会上发布，它是基于 Swift 建立的声明式框架。该框架可以用于 watchOS、tvOS、macOS、iOS 等平台的应用开发，等于说统一了苹果生态圈的开发工具。

本人最早开始 iOS 开发时选择了 OC（Objective-C，一种编程语言），当时 OC 不但拥有各种知名的第三方库和完善的社区支持，同时 Swift 语言本身都还在不断颠覆性改进中。但当我看了 2020 年 WWDC 关于 SwiftUI 一系列课程之后，便从 Swift 语言的学习开始，逐步了解并掌握 SwiftUI，并果断抛弃了OC，将新项目全部迁移到了 SwiftUI 框架。

SwiftUI 到底有没有苹果宣传的那么理想化？资深的 iOS 开发者是否有必要转型，以及如何转型？SwiftUI 在实际使用的过程中真实体验如何？这些问题就是这篇文章希望探讨的话题。

在最后，我会分享一些自己的学习心得和材料顺序，借开源的精神与大家共同进步。

什么是 SwiftUI

对于 Swift UI，官方的定义很好找到，也写得非常明确：

SwiftUI is a user interface toolkit that lets us design apps in a declarative way.
可以理解为 SwiftUI 就是⼀种描述式的构建 UI 的⽅式。

单单通过描述，大部分人其实很难对抽象的编程方法，和其中的改进有直观的认识。这篇文章也希望通过尽量口语化的叙述，减少专业词汇和代码的出现来降低阅读门槛，让更多人了解计算机科学，了解程序的世界。

下面是我手头正在做的一个项目，定位是一个原生全平台的电子阅读应用，正在使用 SwiftUI 构建用户界面。

范例中的界面是书本目录的页面，其中包括了底层的导航栏，分割内容的列表，不同栏目的显示内容等。可以看到，代码部分只有很少的几行，就可以构建出一个简洁却清晰地目录页面，用户点击任意的小标题就会跳转到相应的章节。

得益于SwiftUI的特性，现在将想法落地事实上确实便捷了很多，这与之前UIKit的例子形成了鲜明的对比。

为什么苹果要推出 SwiftUI

SwiftUI 的两个组成部分，Swift + UI，即是这个问题的答案。

Swift：编程语言和体验的一致性

Swift 代表苹果推出的一种现代编程语言。

很多苹果用户之所以喜欢苹果的产品，其中一个原因，是不同产品之间由内而外的统一感和协调感。这一点在硬件层面的感知是最明显的，从早期开始苹果出的硬件就是『果味十足』的。即使是新品迭代或者是开发全新的品类，也一定会带有烙印很深的「果味」工业设计。

仅仅外观的统一还不够，苹果真正追求的是内外一致，也就是体验的统一。

然而工业设计可以交给自家精英团队，系统可以相互借鉴，但用户使用的软件是由广大的开发者自由创造的。让人意外的是，这一点苹果做的也很不错，与别家相比，质量精良是很多人对苹果系统上软件的印象。

为了实现这一目标苹果做了大量不为普通消费者所感知的工作。

在设计上，苹果提供了一整套不断在更新的 Human Interface Guidelines，详细规定了与视觉相关的各个方面。在完成开发，准备上架分发之前，苹果的审核团队会对每一款应用进行审核，根据 App Store Review Guidelines 的条款判断应用是否允许上架 App Store，即使是知名的应用违反规定也是说下架就下架，绝不含糊。对于不越狱的移动设备而言，App Store 是唯一可以安装应用的途径，控制了其中的准入也就等于替整个平台做了筛选。

除了控制终端以外，苹果也在想方设法增加开发者的数量，提升单个应用质量。方式也非常符合第一性思维原则——降低开发的难度。所以先有了 Swift，紧接着又推出了 SwiftUI。苹果希望直接优化语言本身，并统一所有设备的开发体验，让开发者更容易上手，也更容易将心里的想法转化为运行的程序。

虽说在 2015 年推出 Swift2.0 的时候就进行了开源。但这些年Swift在后端或是跨平台的发展上并不是非常顺利。提起 Swift，圈内还是会被默认为特指苹果平台内使用的编程语言，地位有些类似 OC 的接班者。其实为了推广这门语言，苹果本身也做了非常多的工作，像是推出SwiftUI，基本就可以看做苹果在推广新语言的过程中一个里程碑式的节点。

SwiftUI 使用了大量 Swift 的语言特性，特别是5.0之后新增的特性。Swift 5.1 的很多特性几乎可以说都是为了 SwiftUI 量身定制的，比如 Opaque return types、Property Delegate 和 Function builder 等。

UI：开发的困局

在 SwiftUI 出现之前，苹果不同的设备之前的开发框架并不互通，移动端的⼯程师和桌⾯端的⼯程师需要掌握的知识，有很⼤⼀部分是差异化的。

从 iOS SDK2.0 开始，移动端的开发者⼀直使⽤ UIKit 进⾏⻚⾯部分的开发。UIKit 的思想继承了成熟的 AppKit 和MVC（Model-View-Controller）模式，作出了⼀些改进，但本质上改动不⼤。UI 包括了⽤⼾能看到的⼀切，包括静⽌的显⽰和动态的动画。

再到后来苹果推出了Apple Watch，在这块狭小屏幕上，又引入了一种新的布局方式。这种类似堆叠的逻辑，在某种程度上可以看做 SwiftUI 的未完全体。

截止此时，macOS 的开发需要使用AppKit，iOS的开发需要使用 UIKit，WatchOS 的开发需要使用堆叠，这种碎片化的开发体验无疑会大大增加开发者所需消耗的时间精力，也不利于构建跨平台的软件体验。

即使单看 iOS 平台，UIKit 也不是完美的开发⽅案。

UIKit 的基本思想要求 ViewController 承担绝⼤部分职责，它需要协调 model，view 以及⽤⼾交互。这带来了巨⼤的 sideeffect 以及⼤量的状态，如果没有妥善安置，它们将在 ViewController 中混杂在⼀起，同时作⽤于 view 或者逻辑，从⽽使状态管理愈发复杂，最后甚⾄不可维护⽽导致项⽬崩溃。换句话说，在不断增加新的功能和⻚⾯后，同⼀个ViewControlle r会越来越庞杂，很容易在意想不到的地⽅产⽣ bug。⽽且代码纠缠在⼀起后也会⼤⼤降低可读性，伤害到维护和协作的效率。

SwiftUI的特点

在很多地方都能看到 SwiftUI 针对现有问题的一些解决思路，而且现在的编程思想经过不断以来的演化，也一直就软件工程在开发过程中的各种问题在寻找答案。

近年来，随着编程技术和思想的进步，使用声明式或者函数式的方式来进行界面开发，已经越来越被接受并逐渐成为主流。SwiftUI 不是第一个，也不会是最后一个使用声明式界面开发的框架。

声明式的界面开发方式

在计算机科学的世界内，抽象是一个很重要的概念。从底层的二进制逻辑门，到人类可以阅读和理解的编程语言之间，是由很多层的抽象将它们关联起来的。所谓抽象，简单解释就是通过封装组件，将底层细节打包并隐藏起来，从而明确逻辑降低复杂度。就像把晶体管打包成逻辑门，以及软件工程中的函数对象。在软件开发的过程中，工程师只需负责某个具体功能的实现，而其他人则通过开放的 api 使用该功能。

与曾经的布局方式相比，声明式的页面开发无疑又加了一层抽象。

在 UIKit 框架中，界面上的每一个元素都需要开发者进行布置，期间有不少计算工作，例如长宽的改变或是屏幕可视面积的变化等。这种线性的方式被称为指令式 (imperative) 编程。以一行文字为例，放置在哪个坐标、宽度多少、在哪里换行、怎么断句、字形字号是多少、最终高度多少、是否需要缩小字号来完全显示等，这些都是开发者在制作界面时要考虑和计算妥当的问题。到了第二年，用户可能会换更大屏幕的手机，系统支持动态字体调节等新功能，此时原先的程序不进行适配就可能出现显示问题，开发者就需要回头进行程序的重新调试。

换做 SwiftUI 之后，上述的很多变量就被系统接管了。开发者要做的就是直观的告诉系统放置一个图像，上面加一行文字，右边加一个按钮。系统会根据屏幕大小、方向等自动渲染这个界面，开发者也不再需要像素级的进行计算。这被称为声明式 (declarative) 编程。

对比同一个场景界面的实现

作为常用的列表视图，在UIKit中被称为 TableView，而在 SwiftUI 中被叫做 List 或 Form。同样是实现一个列表，在 SwiftUI 仅需要声明这里有一个 List 以及每个单元的内容即可。而在UIKit 中，需要使用委托代理的方式定制每个单元的内容，还需要事无巨细的设置行和组的数量、对触摸的反应、点击过程等各方面。

在我的另一个早期项目Amos时间志中就可以看到，为了绘制主页就需要几千行代码。

智能适配不同尺寸的屏幕

除了不同尺寸的屏幕，SwiftUI 还能根据运行平台的区别，将按钮、对话框、设置项等渲染成匹配的样式。由于声明的留白是很大的，当开发者不需要事无巨细的安排好每一个细节时，系统可操作的空间也会变大。

可以想象，假如苹果推出新品例如眼镜，或许同样的界面代码会被展示成与 iPhone 中完全不同的样式。

提高了解决问题时所需要着手的层级，这可以让开发者可以将更多的注意力集中到更重要的创意方面。

链式调用修改属性

链式调用是 Swift 语言的一种特性，就是用来使用函数方法的一种方式。可以像链条那样不断地调用函数，中间不需要断开。使用这种方式开发者可以给界面元素添加各种属性，只要愿意，同样能够事无巨细的安排页面元素的各种细节。

除了系统预制的属性可以调节外，开发者也可以进行自定义。例如将不同字体、字号、行间距、颜色等属性统合起来，可以组合成为一个叫「标题」的文字属性。之后凡是需要将某一行文字设置成标题，直接添加这个自定义的属性即可。

使用这种方式进行开发无疑能够极大的避免无意义的重复工作，更快的搭建应用界面框架。

界面元素组件化

理论上来讲，每一个复杂的视图，都是由大量简单的单元视图构成。但是函数方法可以包装起来，做到仅在有需要的时候进行调取使用。在 UIKit 框架下的页面元素解耦却不太容易，一般都是针对某种特定情境，很难进行移植。有时候可能手机横屏就会让页面元素混乱，就更别论页面元素的组件化了。

不过 SwiftUI 在布局上的特点，却可以便捷的拆分复杂的视图组件。单一的组件不仅可以自由组合，而且在苹果的任意平台上都可以使用该组件，达到跨平台的实现。

一般我个人会将视图组件区分为基础组件、布局组件和功能组件。因为 SwiftUI 的界面不再像 UIKit 那样，用 ViewController 承载各种 UIVew 控件，而是一切都是视图。这种视图的拼装方式提高了界面开发的灵活性和复用性。

响应式编程框架 Combine

在构建复杂界面的过程中，数据的流通一直是指令式编程中相当让人头疼的部分。

在UIKit框架下时，会配合 Target-Action 或者 protocol-delegate 模式来交换信息，使用 Key-Value Observing (KVO) 或者 Key-Value Coding (KVC) 来监测变化和读写属性。但即便开发者熟练地使用这些工具，面对日益增长的应用复杂性，掉坑里的可能性还是非常大。因为有太多需要开发者妥善处理的数据流动，例如数据改动后需要通知相关的页面进行刷新，或是让关联数据重新计算等。

像是 React Native 和 Flutter 这样的移动端跨平台方案，由于采用了声明式 UI 的编写方式和严格的数据流动方向，就能够大幅减轻开发者的思考负担。

SwiftUI 很明显也吸收了这些现代的编程思想，在另一个重量级系统框架Combine的协助下，实现了单一数据源的管理。

响应式编程的核心是将所有事件转化成为异步的数据流，这刚好就是 Combine 的主要功能。Combine 采用观察者模式，对应多个观察者，可以分别订阅感兴趣的内容。在 SwiftUI 的界面布局过程中，不同的 View 就是观察者，分别订阅了相关联的属性，并在数据发生变化之后就能够自动的重新渲染。

单一数据源

在 WWDC 的介绍视频中，「Source of truth」这个词反复出现，中文可以将这个词理解为单一数据源。

一直以来复杂的UI结构都会创造更为复杂的数据和逻辑管理需求，每次在用户交互，或是数据来源发生变化的时候，能否及时更新相关界面组件，不然就会引起显示问题。

但是在 SwiftUI 中，只要在属性声明时加上@State等关键词，就可以将该属性和界面元素联系起来，在每次数据改动后，都有机会决定是否更新视图。这样就可以将所有的属性都集中到一起进行管理和计算，也不再需要手写刷新的逻辑。因为在 SwiftUI 中，页面渲染前会将开发者描述的界面状态储存为结构体，更新界面就是将之前状态的结构体销毁，然后生成新的状态。而在绘制界面的过程中，会自动比较视图中各个属性是否有变化，如果发生变化，便会更新对应的视图，避免全局绘制和资源浪费。

使用这种方式，读和写都集中在一处，开发者就能够更好地设计数据结构，比较方便的增减类型和排查问题。而不用再考虑线程、原子状态、寻找最新数据等各种细节，再决定通知相关的界面进行刷新。

与UIKit彼此相容

一般开发者学习新技术有一个最大的障碍就是原先的项目怎么办。但 SwiftUI 在这一点上做的相当不错。由于是一个新发布的框架，UI 组件并不齐全，当 SwiftUI 中并没有提供类似的功能时，就可以把 UIKit 中已有的部分进行封装，提供给 SwiftUI 使用。需要做的仅仅是遵循UIViewRepresentable协议即可。相反，在已有的项目中，也可以仅用 SwiftUI 制作一部分的UI界面。

当然两种代码的风格是截然不同的，但在使用上却基本没有性能的损失。到最终成品时，用户也无法分辨出两种界面框架的不同。

从开发者的⻆度看 SwiftUI

回到开头的问题：SwiftUI到底有没有苹果宣传的那么理想化？

在WWDC发布SwiftUI时，有一句话让我印象深刻：「不论多复杂，原先布局的99%现在都可以使用SwiftUI进行构建」。当我查询 SwiftUI 是否可以承担大型项目开发时，又一次从资深开发者那里看到了这句话。

在我实际体验一段时间，并最终将一款全 SwiftUI 开发的应用上架后，认为这句话并没有什么问题，但前提是对编程这件事需要有比较基础且深入的理解。

这有点像我们学习一些优秀的第三方库时候的感受，同样是用 Xcode 写代码，有些人写出来就是白开水，而另一些人就是黑魔法。学习同样的语言特性，但由于理解的深刻程度不同，在使用时也会大不一样。仅仅依靠一些标准的自带组件无法做出一款出色的应用，即使如 UIKit 那样拥有如此丰富的组件也不行。很多时候还是要根据业务需要，或者是一些独特的脑洞做出最合适的界面。

对于个⼈开发者而言，意味着什么？

SwiftUI 的上限有多高，还要看未来一年一度的更新。但与之前的 UIKit 相比，下限被大大拉低已是不争的事实。这里的所谓下限，指的是学习的难度。由于描述性的布局方式与我们平时的阅读习惯非常接近，告诉系统在页面中间放一个图片就像告诉别人在桌子中间放一个苹果那么直观。我认识的好多 UI 设计师就通过短时间的自学掌握了 SwiftUI，并且搭建起可以直接在真机上使用的 Demo。

降低学习成本这件事是非常有意义的，不仅可以增加开发者数量，降低学习门槛，而且就学习本身而言，让初学者感受到成就感和明确学习方向，长久而言是比短时间的学习效率更重要的事情。只有开始的时候培养足够的兴趣，在后期才可能自主自发的研究更深入更困难的问题。

SwiftUI 和 Combine 大量借助了 Swift 的语法特性，尤其是5.0之后的几个更新，新特性就仿佛是为了这两个系统及框架量身定做的一般。虽然将 Swift 开源，但苹果无疑还是牢牢地把握着这门语言的发展。这两个框架和编程语言之间的配合默契，也仿佛让开发者体会到了软硬件一体带来的发展潜力。无论 Swift 出圈后的成果能有多少，在苹果的体系内，无疑是能够将各种消费层面的软件体验整合统一。

只要使用 SwiftUI，系统会默认支持白天和黑夜模式的自动切换；在各种尺寸的屏幕间自动适配；为任意控件添加 Haptic Touch 或是动画；在Apple Watch上带来独立而完整的体验；将iOS 的应用转换为 macOS 的原生应用，会以最快的速度支持第一方的各种新特性。这种对苹果硬件的深入支持是那些跨平台方案无论如何无法实现的。可以看一些采用第三方框架的知名应用，像是横屏、黑夜模式、小组件等基础的特性，到现在都迟迟没有适配。

所以 SwiftUI 对小工作室或是独立开发者来说是件好事，可以让新的想法快速落地并且接受市场验证，真正的做到敏捷开发。以这种方式在市场中的细分领域获得一席之地，也能让更多人体会到编写程序的感受，甚至是创造财富。

开源我的学习心得

在最后的部分我会分享一些自己学习 SwiftUI 的过程和介绍相关的资源，给一些也对开发感兴趣的小伙伴们做个参考。

首先要学习的是 Swift 编程语言，它与 OC 之间的差别还是挺大的，学习也没有什么捷径，直接阅读官方教程，对照着实例自己写一遍就行。国内有几个非常好的汉化网站，可以一起对照学习。基本上没有必要特意买书，反而不如直接电脑上看了就敲来的方便。

1. 官网
2. SwiftGG
3. Github汉化库

对语言有了大概的了解后，就可以开始对 SwiftUI 的学习，假如遇到问题可以反复回去查看之前的资料。很多被忽略的细节，或是当时初看没概念的部分，结合具体的案例就能够有比较透彻的理解。

1. 斯坦福公开课CS193P·2020年春：该课程强推，我当年学习OC看的就是它，现在到SwiftUI了还是先看这个，系统且细致，结合案例和编程过程中的小技巧介绍，是很好的入门课程。
2. 苹果官方SwiftUI课程：打开Xcode，照着官方的教学，从头到尾学着做一遍应用。
3. Hacking with swift：这是国外一个程序员用业余时间搭建的分享网站，有大量的文章可以阅读，还有推荐初学者跟着做的「100 Days of SwiftUI」课程。
4. 苹果官方文档：文档是必读的，虽然很多文档缺乏工程细节，但是文档涉及很多概念性的内容，你可以知道官方是怎么思考的，并且有很多具体的机制参数。我本人有一个习惯，要是工程涉及某个框架，会把相关的文档都翻译一遍。
5. Stack Overflow：有问题查询专用，在谷歌中搜索错误代码或者关键词基本都会由该网站给答案。
6. 阅读 SwiftUI 库的源代码。

基本到此假如能够顺利完成下来，就可以开启自己的项目。开发想要提高的关键就是亲自写代码和不断地阅读学习。初期学习的关键能力就是英语和翻墙，而到后期需要的就是真正的兴趣和一些数学能力。

© 本文著作权归作者所有，并授权少数派独家使用，未经少数派许可，不得转载使用。