WWDC23 带来的变化同时发生在几个层面：Swift 开始提供更强的代码生成与所有权控制能力，SwiftUI 的状态、动画和数据接口继续扩展，Vision Pro 则让开发者重新思考应用能出现在哪些地方。这场《新技术，新特性，新机会》先拆解技术，再用 UIKit 现场编码检验其中一种思路，最后把话题放回开发者的工作环境与产品选择。
录播于 2023 年 6 月 15 日发布，时长约 108 分钟；技术体验、就业观察和产品预期均保留当时语境。尤其 Vision Pro 部分发生在产品发布初期，嘉宾讨论的是预期与机会，并非长期使用评测。
Swift 宏：让重复代码成为编译期可以处理的工作
第一部分把宏放在 Swift 语言持续演进的背景里理解。分享者建议开发者阅读 Swift Evolution：提案中的问题定义、替代方案和讨论过程，本身也是学习技术设计的材料。知道一个特性为何出现，往往比记住它的写法更有帮助。
Swift 宏的用途是根据输入语法生成代码。例如，一个表达式宏可以同时保留表达式与它的求值结果，使断言、调试或日志不必把同一份信息手写两遍；附加在类型或成员上的宏，则可以生成相关成员与辅助实现。宏的角色决定了它出现的位置以及允许增加哪些代码。
现场用 #stringify、预览、可观察模型等例子说明：开发者写下较短的声明，编译器执行宏展开，随后继续检查和编译展开后的程序。这与 C 预处理器直接进行文本替换的体验不同。宏的声明有类型信息，实现会处理语法树；写宏也因此需要理解 SwiftSyntax，而不是只拼接几段字符串。Apple 的宏教程给出了完整的模板、展开和测试过程。
讨论还比较了宏与 Property Wrapper 的可理解性。两者都能减少样板代码，但读者可能不知道简短标记背后究竟做了什么。Xcode 的展开能力让开发者可以就地查看生成结果，这是宏易于调试的一面。另一方面，少写源码并不意味着最终程序一定更小，宏的正确性也需要测试。
嘉宾感兴趣的应用包括生成初始化或包装代码、让某些字面量在编译阶段接受检查，以及把重复的框架接入方式封装成声明。它们共享的判断标准是：生成规则是否明确、错误能否清楚地反馈给调用者、展开后的行为是否仍容易理解。
所有权控制，以及语言变复杂之后如何学习
接下来的讨论转向 borrowing、consuming 和不可复制类型。以往很多所有权和复制细节由编译器按照默认规则处理，新能力让开发者在需要时更明确地表达参数使用方式与值的生命周期。
借用允许函数使用一个值，而不取得它的所有权；消费则表达所有权的转移。不可复制结构体与枚举进一步约束值的使用，适合表达不能随意复制的资源。这里讨论的是内存与资源管理、复制成本等问题，不能据此认为代码自动获得完整的多线程安全保证。Swift 5.9 发布说明将这些能力定位为对性能敏感代码的控制手段。
对日常开发者来说，新的问题是学习负担：语言的表达能力增加了，是否意味着每个人都必须立即掌握每一项机制？嘉宾的看法较为务实。大多数业务代码仍可以使用熟悉的写法，遇到资源、性能或库设计问题时，再深入相应特性。把高级能力当作必须同时学完的清单，反而容易阻碍开始使用。
讨论也延伸到 Swift 在 Apple 平台之外的可能性，包括服务端、C++ 互操作以及其他计算场景。嘉宾用不同语言与生态的发展作为比较，强调技术能力和生态基础不是同一件事：一种语言能表达某类程序，不代表它已经拥有成熟的库、工具和人才供给。现场提及的 Swift for TensorFlow 等历史探索，属于这一背景，并非仍在持续发展的产品承诺。
SwiftUI：状态管理、滚动与动画的表达继续变化
@Observable 是这一段的重点。过去使用 ObservableObject 和 @Published 的模型，开始有了通过宏接入 Observation 的新方式。视图跟踪实际读取的属性变化，模型本身的声明也更简洁。需要从模型属性创建双向绑定时，则可以使用 @Bindable。WWDC23 的 Observation 专场解释了这些关系。
嘉宾并没有把它描述成完全消除学习成本的机制。已经熟悉旧方案的团队，需要重新理解哪些状态由视图持有、哪些对象来自环境、哪些地方只是需要绑定；新旧项目并存时，迁移本身也会成为工作。好的 API 能减少一类重复代码，但开发者仍需要理解状态如何流动。
滚动与动画是另一组直接影响应用体验的变化。讨论涉及滚动过渡、更多定制能力、多阶段动画、关键帧和自定义动画。过去为了完成某种交互，需要退回 UIKit 或手写状态切换；新的接口让部分常见需求可以在 SwiftUI 中表达。
containerRelativeFrame 则引出了布局思路的变化：当需求是根据受支持容器的大小计算布局时，不一定要先通过 GeometryReader 读取尺寸再自行传递。嘉宾关注的是代码能否更直接地对应布局意图，而不是把某个接口当作适用于所有父视图的通用答案。
现场也提出了不同意见。配置越来越多地进入闭包，可以提高组合能力，却可能让一段视图声明嵌套得更深。如何抽取小组件、给闭包命名、保持修改时的可读性，仍是应用代码自己的责任。围绕 RealityView 的讨论进一步提醒：SwiftUI 视图的组织与 RealityKit 场景对象的加载、更新有关联，但不是同一种对象模型。
SwiftData：现代接口值得看，迁移仍要对照项目需要
SwiftData 让数据模型、查询与 SwiftUI 集成成为这一年非常直观的变化。嘉宾关注它如何利用宏，把模型声明和持久化接入写得更接近普通 Swift 代码，以及 @Query 等接口怎样连接界面和数据。其基础与 Core Data 有关联，但使用方式面向 Swift 的语言特性重新设计。Apple 的介绍展示了这条使用路径。
现场反应并不一致。有的嘉宾期待更好的开发体验，有的已经使用其他数据库，不准备只因为发布了新框架就立刻迁移。两种态度可以同时成立：新 API 值得试验，既有项目的模型、迁移成本、兼容范围和性能需求，也需要单独评估。
这段讨论还出现了一个有价值的修正。有人最初依据身边经验觉得 Core Data 使用者不多，后续又提到朋友所在的大型团队仍在使用它。个人接触到的项目不能代表整个生态。评估框架时，比“大家都用不用”更可靠的是查清自己的数据关系、查询模式、维护历史和平台约束。后续补充 37:49–38:20
UIKit、WidgetKit 与跨设备体验
UIKit 仍有实际更新。现场提到了 viewIsAppearing 生命周期、Trait 系统及预览能力，并讨论在早期测试版中尝试新工具的不同体验。有人遇到问题，也有人已经跑通；这类交流适合帮助定位测试环境差异，不能由一次失败推导出框架永久不支持某项能力。
WidgetKit 的意义则体现在出现位置与交互方式的扩展：桌面、锁屏、StandBy，以及可直接完成某些操作的小组件。嘉宾尤其关注 iPhone 上的数据和能力如何进入 Mac 上的小组件体验。过去为了分开数据与视图所做的工程设计，在更多设备和展示环境出现后，会产生新的价值。
讨论用健康提醒等场景举例说明产品想象：信息不一定只在打开完整 App 后才有用，也可以在适合的时间与位置呈现。这里的关键不是把所有应用能力都塞入小组件，而是选择少量、明确、适合短交互的任务。可交互小组件也不意味着可以自由使用所有手势或无限制更新。
空间界面让原有的框架设计有了新去处
从 SwiftUI 的大会内容数量，嘉宾感受到 Apple 对它的持续投入。但已有 UIKit 项目、平台兼容和具体组件仍然存在，不能把这种观察解释为 UIKit 已经失去用途。
空间计算带来的变化，是界面不再只有平面上的宽和高。深度、空间坐标、手势以及沉浸场景，开始进入开发者熟悉的应用组织方式。Scene、窗口与沉浸空间之间的关系，使此前积累的一些框架知识可以继续使用。
嘉宾由此产生的信心，来自阅读当年的 Session 和早期开发材料。新的抽象让入门看起来不必完全重来，但真正的空间交互质量、性能与舒适度，仍需要在合适的运行环境中检验。
一次 UIKit 现场实现：从 UIView 数组到声明式布局
第二段技术分享没有要求旧项目整体迁移到 SwiftUI。演示从一个具体目标出发：能否继续使用 UIKit，同时把子视图的组织写成更容易阅读的声明式结构？
分享者先回顾手写 Frame、Auto Layout、UIStackView 到 SwiftUI 的路径。底层布局能力和上层表达方式可以分别考虑。Result Builder 是 Swift 的语言机制，可以为特定领域组织结果，并非 SwiftUI 独占。
现场从返回 [UIView] 的构造过程开始。最简单的 buildBlock 接受多个视图，组合成数组。随后加入条件语句：如果某个视图只在条件成立时出现，就需要处理可选分支。此时统一中间组件类型很重要，将单个 UIView 转成数组，再让多个数组合并，能减少不同语法结构之间的不一致。
演示逐步补充了几类构建方法：
buildExpression把单个视图转换为约定的中间组件。buildBlock合并顺序出现的组件。buildOptional处理没有else的条件分支。buildEither接收二选一分支的结果。buildArray组合循环产生的多组组件。
这些方法由编译器对构建器函数体进行转换时使用，并不是另外启动一个运行时脚本解释器。SE-0289规定了它们对应的转换规则。
声明式外观背后，布局约束仍要设计
有了视图构建器之后，演示把结果交给 UIStackView，再封装水平与垂直方向、边距和嵌套容器。一个容器最终仍返回 UIView，因此可以继续成为另一个容器的子节点，形成与界面层级接近的代码结构。
接下来出现了真实布局问题：标签为何被拉伸，剩余空间应该分给谁？解决它依靠 UIKit 的布局机制，而不是声明式语法本身。调整 Content Hugging 优先级，可以影响视图抵抗拉伸的程度；用于占位的 Spacer 则需要更愿意接受剩余空间。
现场继续实现 Spacer 和 Divider。Spacer 可以根据所在轴承担弹性空白，或者在某些场景指定长度；Divider 则需要明确固有尺寸、颜色和边距。将这些小能力组合起来后，循环生成列表、嵌套横纵布局和调整对齐方式就更直观。
这次演示展示的是如何构建适合自己项目的布局表达层。它没有自动带来 SwiftUI 的状态系统、差异更新或全部组件能力。对于仍有最低系统版本与历史代码约束的团队，这种渐进改进可能有价值；代价则是自己维护封装边界和布局行为。
同一场 WWDC，不同地区的开发者看见什么
圆桌从技术转向社区。台湾的嘉宾谈到与熟悉的开发者一起在线关注大会，以及通过社群持续交流的方式。新加坡的嘉宾提到自己接触到的学生社团、朋友间的观看活动，也观察到当地不同技术话题的热度。这些都是个人所处社区的切片，并非地区开发者规模统计。
在英国工作的嘉宾，从公司和本地聚会谈到应用所服务的业务。部分团队的 App 是物流等现实服务的一环，移动端并不总是唯一产品。这会影响团队大小、跨平台选择以及工程师的工作边界。有的人因此接触更广的技术，也有人走向独立开发或持续创作技术内容。
他也谈到 2023 年求职环境带来的压力：在自己的接触范围里，移动开发岗位似乎减少，招聘更偏向能承担资深工作与架构责任的人。这是嘉宾当时的个人观察，不能外推成整个地区的岗位统计，也不代表今天的招聘状况。原片 71:18–71:44
新技术同样会带来热烈讨论。Web3、生成式 AI、Vision Pro 相继出现，开发者不断提出新的尝试。但嘉宾也区分了讨论热情与实际落地：新的架构是否值得整体替换，产品是否有明确需求，仍需要回答。
香港的嘉宾则分享了与本地开发者合作的经历。他看重基础能力、沟通和表达，也提到创业公司与金融等业务中的移动开发需求。早年在团队里尝试 Reactive Extension 相关框架的经历，用来说明某些团队对新工具较为开放。这一部分保留的是 2023 年嘉宾的职业观察，不作为当前招聘行情或求职结果保证。
几段交流共同反映出一个现实：工程师能接触到什么机会，既受技术能力影响，也与当地的产业、服务对象、团队组织和社区连接有关。理解这些差异，比把某一个地区简单判断为“先进”或“落后”更有帮助。
Vision Pro 的第一轮讨论：交互方式与生产力需要验证
最后一部分明确定位为初步讨论，更深入的 XR 技术另有活动展开。现场嘉宾尚未亲自体验 Vision Pro，因此把已有 VR 使用经验、发布会展示和外部试用反馈分开谈。
眼动定位与手势确认是大家关注的交互变化。一位嘉宾用自己体验过的 PS VR2 说明眼动追踪能带来怎样的感受，同时回忆过去专门眼动实验设备的使用。这类比较有助于理解交互方向，不能直接当作两款设备精度或体验的实测结论。
谈到是否购买，讨论转向生产力：如果一种新设备能改善工作空间、信息呈现或专注体验，它可能像升级电脑或显示器一样值得投入。不过，现场提到的效率提升是假设情境，没有测量数据。更大的虚拟画面是否适合长期工作、佩戴是否舒适、实际任务能否更快完成，都需要真正使用后判断。
嘉宾还谈到眼动配合轻捏的低学习成本预期，以及媒体对透视画面完成度的描述。大家对技术整合的复杂度感到兴奋，但这些内容仍属于发布初期的理解，不能替代他们自己的使用评测。
多年技术积累如何汇入一个新平台
圆桌把 ARKit、RealityKit、空间音频、Apple Silicon、窗口与 Scene 等长期投入重新联系起来。此前看似分别发展的能力，在一个新设备上同时出现，使开发者更容易理解它们之间的产品关系。
嘉宾也从表冠、连接与佩戴细节等设计元素里，联想到 Apple 其他产品的经验。这里的重点是系统整合：单项技术并不一定足以形成一种新的使用方式，硬件、软件、交互和内容如何共同工作才更关键。
至于这些能力是否从一开始就为 Vision Pro 规划，现场也保留了不同解释。可能有长期方向，也可能是持续积累之后形成了新的组合。它是开发者对产品路线的解读，并没有内部决策材料作为证明。
开发者的机会：参与寻找场景，而不是提前宣布答案
对移动开发者来说，新平台同时带来兴奋和不确定。已经投入开发的 iPad App 是否仍有机会？现有技能可以迁移多少？新平台究竟适合什么？嘉宾没有给出手机将被替代的确定预测，而是回忆智能手机早期大量尝试的状态：一些应用后来消失，另一些探索才逐步找到价值。
这种过程需要开发者参与。平台提供能力，但有用的场景、交互惯例和产品类型，往往在真实应用中逐渐形成。熟悉 Apple 生态可以降低一部分起步成本，却不能替代需求判断。
讨论的另一条线索是内容。大屏幕般的观看体验、空间音频、3D 影像以及可交互内容，让嘉宾把设备理解为创作和消费内容的新媒介。现场提及可参与的电影或新的游戏形式时，说的是探索方向，没有把设想写成已经存在的成熟产品。
录播最后回到这场活动的结构：先理解语言与框架，动手检验其中一种工程方法，再把技术放到人的工作与产品体验中。对于后来回看这段讨论的开发者，有价值的材料既包括具体实现，也包括新平台发布时，人们如何提出问题、形成假设并保留验证空间。