和很多开发者一样，我今年更看重稳定性与效率方面的改善，也主动降低了对“惊喜型新功能”的期待。带着这样的预期，快速浏览了 WWDC 2026 第一天中几个我比较关心的主题后，本届活动给我的初步印象是：符合预期，而且相当务实。
AI
尽管 Foundation Models 在去年已经推出，但当时提供的能力，对很多开发者来说仍不足以构成足够强的吸引力。今年的变化则明显更务实：API 进一步整合，支持图像输入，可以根据任务选择设备端模型、私有云计算或第三方服务器模型；满足条件的开发者还可以免费使用运行在私有云计算上的 Apple 基础模型。与此同时，系统也开始具备更强的视图感知、App 上下文理解，以及通过 App Intents 将用户重新带回应用的能力。
这些改进大幅提升了 Foundation Models 的实用性和吸引力。它不再只是一个“可以试试”的框架，而是开始具备进入真实产品流程的基础。不出意外，今年会有更多开发者愿意尝试这套系统，并逐步将其纳入应用的核心能力之一。
SwiftUI
对我来说，SwiftUI 最大的变化来自对文档类应用的全面支持。它不仅增加了大量新 API，也将心智模型调整为“可观察文档对象 + 异步快照 + 专用 reader / writer”。这显然更适合复杂文档 App，也更符合现代 Swift 在 Observation 和 Concurrency 方向上的整体演进。
Session 中也提到，SwiftUI 在布局与容器相关实现上继续优化，部分场景下的性能会有明显提升。这是开发者迫切需要的改进。不过，SwiftUI 仍未提供自定义 Lazy 容器的能力，这无疑是一个遗憾。reorderable 和 swipeActions 不再局限于特定容器，这不只是适用范围的扩大，也体现了底层交互逻辑的进一步整合。或许这些整合带来的收益，会在明年的 API 中呈现得更加明显。
@State 支持惰性初始化，iOS 上的 text selection 得到增强，alert / confirmationDialog 提供了 Binding<T?> 支持，这些都很好，只是感觉来得稍晚了一些。interface 中出现了 AnyNavigationTransition，但目前仍没有开放自定义 transition 的能力，只能在系统预设的 zoom 和 crossFade 中切换。
新的 DataDetection 框架为 Text 提供了更好的内容识别能力；toolbar 获得了更多控制力，也能看出 Apple 对使用 SwiftUI 开发 macOS 应用的重视。整体来看，今年的 SwiftUI 并不是靠某个单点 API 带来惊喜，而是通过一组补齐和整合，让它更接近复杂 App 的日常需求。
SwiftData
相较于 @Query 支持 section fetch，以及 ResultsObserver 提供视图外观察查询结果变化的能力，我更看重 @Attribute(.codable)。它提供了更明确的存储意图，也给了开发者一个避免陷入 composition 黑盒的渠道。
当然，@Attribute(.codable) 并不是银弹。它更像是 SwiftData 为不透明 Codable 类型提供的明确出口：适合存储你无法建模、但又确实需要持久化的外部类型；代价则是这部分内容无法参与 SwiftData 的 predicate、sort 和 migration 感知。正因如此，它的价值不在于“更强”，而在于“更明确”。
不过，SwiftData 仍没有提供 public / shared 数据的云端同步能力，也没有看到更明确的性能改善信号。这些问题仍会限制它的采纳率。对许多开发者来说，SwiftData 今年更像是在补齐关键缺口，而不是完成一次足以改变信心的跃迁。
Xcode
过去半年中，我的开发模式基本是 Codex App / Claude App + Xcode，其中 Xcode 的出场时间明显少于前两者。在简单使用 Xcode 27 后，我预计接下来它的出场时间会明显增加。我尤其期待在 UI 精细调整、性能改善、预览验证等方面，Xcode 内置 AI 流程能带来的变化。
Device Hub 无疑是一个巨大惊喜。它将模拟器、实体设备管理、系统状态测试和动态尺寸调整整合到一个新的工作流中，这对日常开发体验的影响可能比很多单个 API 更直接。不过，iPhone 应用也开始支持动态尺寸调整，这会给开发者带来新的挑战，尤其是在数据和状态组织层面。针对不同尺寸的适配，并不是只靠动态布局容器就能解决的。很多场景下，大尺寸和小尺寸对应的导航逻辑会有很大差异。
今年我应该不会第一时间围绕 SwiftUI、SwiftData 的新 API 写文章。相比逐条介绍新增接口，我更想花一些时间系统消化这些变化，梳理它们背后的隐含逻辑：Apple 正在怎样重新组织 SwiftUI、SwiftData、Foundation Models 与 Xcode AI 工作流之间的关系，以及这些变化最终会如何影响我们构建 App 的方式。
原创
Core Data + Observation：从属性级响应到心智解放
Observation 框架的推出，让 SwiftUI 的状态响应从对象级进一步细化到属性级，显著缓解了许多由粗粒度观察带来的无效刷新问题。更重要的是，它让状态管理的声明式逻辑重新变得自然：视图只需要读取自己真正依赖的属性，框架便能据此建立响应关系。为了让 Core Data 这个老牌持久化框架也能享受到现代 Swift 特性的便利，我近期在 Core Data Evolution（CDE）中探索并实现了对 Observation 的支持，赋予 NSManagedObject 属性级的精确观察能力。本文将围绕这一能力的动因、使用方式、实现思路、工程挑战以及开发过程中的一些取舍展开讨论。
近期推荐
用 Swift 和 WebAssembly 把 Goodnotes 带到 Web (Bringing Goodnotes to the web with Swift and WebAssembly)
作为苹果生态中著名的笔记应用，Goodnotes 在走向 Web 平台时，并没有选择完全重写，而是把多年积累的 Swift 代码通过 WebAssembly 带到浏览器环境里。Yuta Saito 在本文中介绍了 Goodnotes 如何在 Web 端保持与原生 App 一致的墨迹渲染、文档同步、CRDT 冲突处理、搜索索引与交互体验。Goodnotes Web 的 Swift 代码规模约 220 万行，其中 147 万行是共享代码；最终生成的 WebAssembly 二进制约 50 MB，经 Brotli 压缩后约 12 MB。这篇文章的意义不只是展示 Swift 可以运行在 Web 上，而是呈现了一个真实的大型 Swift 应用如何借助 WebAssembly，把原本深植于苹果平台的核心能力延展到更多平台。
Yuta 在 iOS Conf 2026 的演讲 Swift at Scale: Where Performance Really Comes From 也很值得观看。相比官方文章对 Goodnotes Web 整体架构的介绍，这场演讲更聚焦一个真实的 Swift 性能案例：Goodnotes 团队发现，一个用于聚合 UI 局部更新的 Update 值类型随着功能增长膨胀到约 6 KB，并包含大量 non-trivial 成员。即使大多数更新只使用一两个字段，热路径中仍要为复制和引用计数成本付费。团队最终通过 hot-cold split 重构数据结构，将高频字段保留在主结构体中，把低频更新移入单独存储，使类型大小从约 6 KB 降到约 300 bytes，并带来约 42% 的 CPU 时间改善。
Swift 官方成立网络工作组 (Announcing the Networking Workgroup)
Swift 现在的网络 API 并不是缺少选择，而是选择过多且存在重叠：从 Apple 平台上的 URLSession、Network.framework，到服务端生态中的 SwiftNIO、AsyncHTTPClient，再到更底层的 HTTP 表示类型，开发者在不同平台、不同抽象层之间往往需要面对不一致的模型和迁移成本。更重要的是，很多 API 出现于 async/await、structured concurrency、actors、Sendable 等现代 Swift 能力成熟之前，因此很难自然地体现今天 Swift 在并发、安全性和跨平台方面的语言优势。这些问题在 A Vision for Networking in Swift 中有更系统的阐述，而 Swift HTTP API Proposal 则可以看作是对这一方向的早期探索。
本次 Swift 官方成立 Networking Workgroup，释放了一个很重要的信号：Swift 生态开始把网络能力作为一项需要长期治理的跨平台基础设施来推进，而不只是让各个框架和包在各自场景中独立演进。工作组的目标不是简单替代现有方案，而是推动更清晰的分层、更一致的类型、更好的互操作性和可观测性，让 Swift 在 Apple 平台、服务端、CLI、WebAssembly、Android、Windows 乃至 Embedded Swift 等场景中，都能拥有更统一、现代且可持续的网络基础设施。
WWDC 26 愿望单汇总 (WWDC 2026 Wish Lists)
Michael Tsai 汇总了多位 Apple 开发者在 WWDC 2026 前的愿望清单。和我在 上一期周报 中的期许类似，大多开发者在呼吁一次偏向 Snow Leopard 式的质量修复：重新审视 Liquid Glass 在 Mac 上的可用性，减少系统和框架层面的不稳定，修复 iCloud 同步、Spotlight、系统设置、错误提示、SwiftUI、Xcode、Simulator、索引和预览等长期影响日常开发体验的问题。也有不少开发者希望今年不要再引入大量为了适配新设计、新框架或新审核要求而产生的“忙碌工作”，而是给现有平台更多打磨时间。
另一个明显主题是 AI Agent 时代下的 Apple 开发工具应该如何演进。多位作者都提到，希望 Apple 提供更官方的 Agent Skills、MCP、CLI 和可自动化接口，让 AI 能更可靠地读取文档、操作 Xcode、管理 App Store Connect、修改项目配置、运行构建、控制 Simulator，甚至以更结构化的方式理解 UI 层级，而不是依赖截图或脆弱的 Accessibility 信息。
与 AI 时代的适配和系统稳定性，确实正在成为更多 Apple 开发者的共同期待。看到本期周报时，WWDC 2026 已经开幕，不知道读完这些愿望再看今年的发布会，大家是否找到了心中期待的答案。
Apple-like
在 WWDC 2026 前后，围绕 Apple 未来方向的讨论明显增多。很多人期待 Apple “回到根本”或重新找回过去的状态，但 David Smith 在这篇文章中选择了一个更有建设性的问题：什么才是 Apple-like？作为一名长期的 Apple 平台开发者，他将这种气质总结为几个方向：The Best, and then Better，Excellence for Everyone，以及 Beneficial and Brilliant。也就是持续追求高质量，即使已经领先也不能消耗用户期待；在价格、可访问性和设计上让优秀体验尽可能服务更多人；并且避免用操纵性的方式追逐短期指标，而是用真正有益、令人惊喜的方式解决用户的问题。
当我们期待 Apple 改善系统稳定性、开发工具和平台体验时，这篇文章也提醒我们，独立开发者和应用团队同样可以用类似的标准审视自己的产品。
工具
MarkdownPDF：纯 Swift 编写的 Markdown 转 PDF 引擎
MarkdownPDF 是 Mihaela Mihaljević 开源的纯 Swift Markdown 转 PDF 引擎。它不依赖 PDFKit、CoreGraphics、WebKit、Chromium、LaTeX、C PDF/Markdown 库等平台或系统能力，Markdown 解析、排版与 PDF 序列化都在 Swift 内完成。正因为核心足够纯净、依赖足够克制，项目具备良好的跨平台潜力，可以适配到 WebAssembly/WASI 运行目标，并在浏览器本地完成 Markdown 到 PDF 的生成。作者提供的 Playground 正是这一能力的演示。
Goodnotes 展示的是大型 Swift 应用迁移到 Web 的工程实践，MarkdownPDF 则提供了另一个角度：当核心逻辑足够纯净、依赖足够克制时，Swift 工具本身也可以自然适配到 WebAssembly 运行环境。Swift 走向 Web，正在从概念验证变成越来越具体的工程选择。
AdaEngine：Swift-first 开源游戏引擎
AdaEngine 是 Vladislav Prusakov 推出的开源 Swift-first 游戏引擎与应用框架，近期发布了第一个公开里程碑 0.1.0。项目面向跨平台而设计，目前 Apple 平台最成熟，并正在推进 Windows、Linux、Android 与 WebAssembly/WebGPU 等平台支持。
它以 data-driven ECS 为核心，结合 Swift 宏、插件化架构、类 SwiftUI 的 AdaUI、资产热重载、场景系统、2D 物理、音频、输入，以及 Metal / WebGPU 渲染后端等能力，试图让 Swift 不只服务于 Apple 平台应用，也能进入游戏、互动工具与创意软件开发场景。
Vladislav 在 Introducing AdaEngine 0.1.0 一文中对项目做了更完整的介绍。