WWDC 2023 正在如火如荼地进行。苹果不仅带来了全新形态的硬件产品，还推出了几个适当震慑的新结构。本文将聊聊我对本届 WWDC 中 SwiftUI 5.0 和 SwiftData 的开始印象。

原文宣布在我的博客wwww.fatbobman.com

欢迎订阅我的大众号：【肘子的Swift记事本】

SwiftUI

如果说从 SwiftUI 1.0 到 4.0 每年的晋级是一种小修小补的行为，那么今年苹果在 SwiftUI 5.0 上做出的努力至少算得上是中期改款了。

今年 SwiftUI 的提高适当的大，有些改动能够视为革命性的改变。

全新的数据流声明和注入办法

利用 Swift 5.9 的新特性，关于引用类型的 Source of truth，只需运用 @Observable 进行标示，视图将对数据源的改变以特点为粒度进行呼应。这从根本上解决了当时影响 SwiftUI 使用（ 过渡核算 ）的效率问题。让开发者能够愈加自在的来设计数据结构以及为所欲为的注入数据源。

不过很惋惜，这项新特性只能在 SwiftUI 5 上完结。如果你计划开发 iOS 17+ 的使用，那么就应该立刻抛弃 @ObservableObject 这样的声明办法。

由于在同一个体系中存在了两种不同的数据源声明逻辑，这也给初学者带来了更多的困扰。

革命性的动画和视觉作用晋级

SwiftUI 原本欠缺一些高级的动画和视觉功用在本次晋级中一并被补上了，而且苹果大幅更新了动画、转场、Shape、作用等方面的内部完结。

本次晋级带来了动画完结回调、阶段性动画、关键帧动画、全新的 Transition 协议（ 支撑转场状况 ）、全新的 Shape 协议（ 支撑 Shape 之间的运算 ）、全新的 TransactionKey（ 支撑自定义 Transaction 特点 ）、Shader 支撑（ 完结某些特殊作用将反常容易 ）、类型安全的图片和颜色资源类型（ Assets 会主动生成对应的代码 ）、便捷的 Symbol 动画、全新的 CustomAnimation 协议（ 支撑自定义动画函数 ）、绷簧动画等很多新功用。总之，当时制约动画或视觉作用的将不再是 SwiftUI 的能力，而是开发者的创意。

大幅改善了 ScrollView 的控制力

本次晋级中，为 ScrollView 带来了新的动态翻滚定位体系（ 不依赖 ScrollViewReader 和显式的 id 声明）、一次性的定位体系（ 在视图进入后，直接定位到翻滚视图的特定方位，只能运用一次 ）、全新的翻滚条控制（ 闪耀 ）、可自定义行视图在翻滚区域的顶端和显现区域的显现状况（ 例如可用其完结类似 watchOS 中的翻滚到顶端子视图缩小的视觉作用 ）、支撑分页翻滚（ 开发者长时间期望的 ）、自定义翻滚内容的缩进、为翻滚内容（非翻滚容器）添加安全区域等很多功用。

其他功用

本次的晋级内容非常多，导致苹果给出的 更新文档 中，很多的新功用也没有列出。在接下来的一段时间中，互联网上应该会有不少的文章对这些功用进行进一步的阐明和讲解。

不过极为惋惜的是，苹果并没有充分的利用 Swift 的 @_backDeploy 功用，在 SwiftUI 5.0 中，仅有很少切不太重要的功用或类型完结了低版本的适配：topBarLeading: SwiftUI.ToolbarItemPlacement、topBarTrailing: SwiftUI.ToolbarItemPlacement、accessoryBar<ID>、horizontalSizeClass、verticalSizeClass、typeSelectEquivalent 。

在不考虑兼容旧版本的情况下，我认为 SwiftUI 5.0 的晋级能够打 95 分（满分 100 分），不过考虑到很多的开发者在适当一段时间内还无法运用这些新功用，心境就会反常的低落。

SwiftData

经过开发者长时间的期盼，苹果终于推出了根据 Swift 开发的目标图管理和耐久化结构 —— SwiftData。与之前的预判一样，在数据存储范畴，苹果不会贸然地另起炉灶，创建一套全新的逻辑。SwiftData 本质上便是一套官方推出的，根据 Swift 5.9 新功用完结的 Core Data 的 Swift 封装库。

从我这两天的运用来看，在其功用和稳定性得到进一步改善和增强的情况下，它确实会给开发者带来更多的便利。

这是我现在整理的一些有关 SwiftData 的问题和注意事项（ 原文宣布在推文中，没有进行更体系的概括）：

  • 尚不支撑公共和共享数据的云同步
  • 在当时版本中，经过其他上下文（ModelContext）创建的数据并不会主动合并到视图上下文中
  • 自定义搬迁 plan 在第一版中有问题
  • 能够与 Core Data 代码混用，需经过 entityVersionHashesByName 来判别 SwiftData 与 Core Data 两者的模型是否完全共同
  • PersistentModel 和 ModelContext 都不是 Sendable 的（ModelContainer 符合 Sendable），与 Core Data 一样，相同有线程约束
  • 敞开 com.apple.CoreData.ConcurrencyDebug 1 后，即便在新的 Context 中运用 transaction 尝试坚持线程共同，仍会强制报错（即便是在一个新创建的 actor 中进行）
  • 相同遭到 CloudKit 同步的约束，演示中的 Attribute(.unique) 并不适用于同步场景
  • 现在功用比 Core Data 少，没有新的添加
  • PersistentModel 的性质与经过宏创建的 Observed 状况类似，可直接驱动视图更新（传递时无需运用特点包装器）
  • Attribute 的派生选项被废弃了
  • 能够在 Xcode 中运用 Model Editor 将 Model 转化为 SwiftData 代码，但现在问题还不少，当有多个选项，或特点类型为 transformable ，无法很好地应对
  • Model 原来设置的 Index，现在无法转化（可生成对应的代码，但 Attributed 没有完全）
  • 所有针对 Core Data 的发动参数现在相同适用
  • modelContext 的主动保存有问题，当时仍应调用 save 办法
  • 与 Core Data Stack 混用时，Core Data 端要敞开耐久化历史盯梢
  • Query（FetchRequest 的替代品）没有提供动态切换 predicate 和 sort 的办法

从代码风格和完结来看，SwiftData 有着光明的未来，但由于现在仍存在不少问题，即便你计划开发 iOS 17+ 使用，现在也不建议直接运用 SwiftData。

为配合 SwiftData，Core Data 做了很小起伏的晋级，其间一个值得关注的功用是 自定义 composite 类型。

然而，Core Data with CloudKit API 在客户端方面没有任何调整，很令人失望。

开心还是无奈

在今年的 WWDC 中，苹果为 SwiftUI 带来了非常大的革新，并推出了开发者向往已久的 SwiftData。一开始看到这些信息时，我心里无比振奋，但很快就平静下来了，终究还有些无奈。

关于绝大多数开发者来说，一旦能够在使用中运用这些新功用，苹果或许又会带来更多的新诱惑。SwiftUI 的新特性极大拓展了其表达能力，但同时也添加了其学习曲线，特别是对初学者而言。SwiftData 尽管简化了 Core Data 的开发，但作为一款新结构，其稳定性与健壮性还有待进一步验证。

在过去几年，苹果推出的新技术层出不穷，开发者要不断学习与习惯，这无形中也添加了开发成本与风险。尽管苹果的新技术遍及都具有实用价值，但在追新与稳定之间，开发者也需要稳重地权衡。

不过关于我来说，本次 WWDC 提供了不少学习和写作的素材。在接下来的一段时间里，我将在博客中介绍和讨论 SwiftUI、SwiftData 以及几个我比较感兴趣的新结构 TipKit 和 CKSyncEngine。

欢迎你经过 Twitter、 Discord 频道 或博客的留言板与我进行沟通。

订阅下方的 邮件列表，能够及时取得每周最新文章。

原文宣布在我的博客wwww.fatbobman.com

欢迎订阅我的大众号：【肘子的Swift记事本】