如何评价 SwiftUI？
从两方面评价 SwiftUI。 Swift 语言很适合编写 DSL，另外为了让 SwiftUI 的语法更易写易读，苹果也可以稍微修改 Swift 编译器。就算苹果不提供这套 UI 库，第三方开发者其实也可以开发出类似的库和声明式语法。 SwiftUI 在 iOS 13 中成为标准库，大家达成共识，容易推广。现在 SwiftUI 实现时用到了 UIKit、CoreGraphics、CoreText 等，可看成是这些库的高层封装。以后也可能底层换掉 UIKit，独立存在。 但假如 SwiftUI 仅仅是对 UI 的语法封装，就类似 SnapKit 对 AutoLayout 的封装。虽然 DSL 写起来方便些，但跟以前的开发流程没有本质区别。开发者已习惯了老一套的 UIKit 写法，假如写法区别太大，很可能不愿切换。 SwiftUI 真正改变开发者的开发流程，是其跟 Xcode 深度集成，实时刷新预览。这点第三方开发者没有办法做到，以前的 UIKit 也没有办法做到。 界面编程，会有一些图形化辅助工具。之前的图形化工具，比如 xib，是使用鼠标拖拉生成界面模板。模板用配置文件保存下来，之后动态载入模板，重新生成界面。这种方式就如同用 Word 来编辑文档，是设计师所喜欢的，但这并非开发者喜欢的方式。 开发者喜欢灵活控制、追求复用、后期容易修改，会更喜欢用 LaTeX 或 MarkDown 去写文档。鼠标拖拉的方式，对于刚入门，写些不会修改的 Demo 还适合。但大规模，各界面风格保持统一，要求多人不断协作维护的 App，往往会直接采用代码。 编写界面，真正的问题并非是编写代码，而是从写代码到预览界面的时间太长了。图形化辅助工具，目的并非是不用写代码，而是要缩短修改到预览的反馈过程。让我们眼睛可以实时看到变化，而不仅仅通过想象。 使用网页的方式去编写 UI，往往会比原生平台的 UI 快得多。并非不用写代码，而是网页编写时可以实时刷新，立即看到反馈。 我认为，SwiftUI 实时刷新预览，代码和界面保持同步，这才是它改变开发流程的方式。而不是它的表面语法。设计师可以鼠标键盘编辑界面，从而修改代码。程序员可以编写代码，从而刷新界面，并可代码复用。 Xcode 11 最重要的两个功能 都需要在 macOS 10.15 才能使用，估计是 10.15 才有 Project Catalyst 所依赖的库，才能模拟出 UIKit。 从 WWDC 2019 的 Keynote 上看，那些新硬件，各系统更新自然让人感兴趣。但对于我们开发者，Project Catalyst 和 SwiftUI 才是最重要的变革。 近期 Swift ABI 的稳定，现在 SwiftUI 的发布，也标志着 OC 向 Swift 的转折。这些并不会立即发生，但对未来有所预期。记住冰球明星韦恩·格雷茨基的名言：“要向着冰球运动的方向滑，而不是它现在的位置。”