距离 WWDC 2026 只剩下 20 天了。每年到这个时候，我都会看到不少开发者分享自己的 WWDC 愿望单，写下预测与期许。但今年，至少到我汇总本期周报时，这类内容相较去年同期明显少了许多。究竟是开发者对 WWDC 的期待变淡了，还是更多人开始秉持“降低预期才能获得更多惊喜”的心理？
也许问题并不是开发者没有期待，而是旧有的愿望单形式已经不太够用了。过去，我们期待的是某个 API、某个框架、某项功能；而现在，当软件开发迅速向 AI Agent 时代靠拢时，很多期待本身也变得更难被清晰描述。
一年前，恐怕很少有开发者会预料到软件开发会如此迅速地进入 AI Agent 时代。即便我们期待 Xcode 提供更好的 AI 支持，在 Xcode 26.3 推出前，也未必会想到苹果会在 IDE 中提供与 Agent 如此紧密的集成。应用或 API 已不再只是面向消费者或开发者的接口，它们也可能成为 AI Agent 理解、调用和编排的对象。AI 不只是开发工具，也会作为新的参与者，深度进入软件服务的构建和使用过程。
我想，这也是不少开发者面对 WWDC 2026 时既期待又茫然的地方。我们希望看到更新的功能、更稳定的框架、更清晰的平台方向；同时也在思考，在这样的开发体系中，如何继续保持自己作为开发者的独特性与必要性，并与 AI 一起构建更好的服务。
WWDC 2026 究竟会带来多少变化，让我们拭目以待。
BTW：上周我非常有幸入选了苹果官方最新公布的 Apple Developer Community Spotlight。作为一名内容创作者，能够得到这样的认可，对我来说既是鼓励，也是鞭策：继续认真写下去，继续把有价值的内容带给大家。感谢每一位长期阅读、反馈和支持我的朋友。
近期推荐
从 URLSession 到电磁波：iOS 网络请求的底层原理 (URLSession to Electrons: How Networking works on iOS)
很多 iOS 开发者都知道：URLSessionDataTask 需要调用 resume() 才会真正开始请求。但在这之后究竟发生了什么？Jacob Bartlett 用一篇长文，带读者一路跟随一个普通的网络请求，从 URLSession、CFNetwork、TCP/IP、Wi-Fi，一直深入到无线电、天线与电磁波。Jacob 不仅串联起 HTTP、DNS、TCP、QUIC、IPv6 等开发者熟悉却未必真正理解的概念，也结合 iOS 内部实现介绍了 Network.framework、XNU 内核 TCP 栈、Wi-Fi 帧结构以及蜂窝网络的调度机制。
一个简单的
resume()，背后涉及的代码与协议演进跨度，可能超过十几甚至几十年。不得不感慨，现代软件世界建立在层层抽象之上，而绝大多数时候，我们其实只是幸运地生活在这些抽象足够稳定的年代。
当 AI 和 Xcode 打架时：我写了个工具来拉架
Xcode 的构建系统从未真正为“并行开发”设计过。多个任务同时构建时，DerivedData、ModuleCache、SwiftPM 缓存乃至 Simulator 都可能互相踩踏，而这一问题在 AI Agent 并行开发场景下被进一步放大。Maples7 在本文中介绍了他的解决方案：VibeChard。它基于 Git Worktree，为每个 AI Agent 创建独立的构建沙箱，并进一步隔离 DerivedData、ModuleCache、SwiftPM 缓存以及模拟器环境。最有意思的是，它并不要求开发者修改构建命令，而是通过 PATH shim 透明接管 xcodebuild，让包括 Tuist、Fastlane 在内的整条工具链都自动运行在隔离环境中。与其说这是一个单纯的辅助工具，不如说它揭示了 AI 编程时代一个更底层的问题：当代码生成速度大幅提升后，传统开发工具链的环境隔离能力也必须随之升级。
Swift 真的被搞得乱七八糟了吗？写了几年之后说点实话
Swift 变得越来越复杂，这是一个不争的事实。但这是否意味着 Swift 已经变成了一门糟糕的语言？迷途酱 从语言演进的现实约束出发，重新审视 Swift 这些年的“膨胀”。作者认为，许多被吐槽的复杂度，其实来自 Swift 同时承担应用层、系统级、DSL 宿主与服务端语言等多重目标，而并发安全与所有权模型本身，也属于计算机科学层面的“硬复杂度”。
文章既讨论了 Sendable、actor isolation、borrowing、~Copyable 等近年来快速增长的新概念，也坦率指出 Swift 在并发关键字、泛型语法以及 SwiftUI “魔法感”上的设计问题。尤其是“Swift 其实是一个语言的多个层级”这一观点，相当值得思考：绝大多数开发者日常写 App 时，其实并不需要承担全部复杂度，但 WWDC 与官方文档却经常把这些内容同时呈现在所有人面前。
Xcode Cloud 进阶：Shell 脚本自动化实战 (Writing shell scripts for Xcode Cloud)
Xcode Cloud 的上手体验已经足够简单，但在真实项目中，许多自动化需求仍然需要借助 shell scripts 完成。Amy Delves 以“在归档完成后自动创建 GitHub Release”为例，展示了如何结合 Xcode Cloud 提供的环境变量判断当前构建是否来自 main 分支的归档流程，如何读取 archive 中的版本号与构建号生成 tag，并通过 GitHub API 创建 release。虽然示例本身并不复杂，但它很好地说明了 Xcode Cloud 并不只是一个“点几下就能跑测试”的服务：借助环境变量、脚本钩子与外部 API，它同样可以承担更完整的发布自动化工作流。
我们为什么离开了很棒的 CloudKit (Why CloudKit is amazing and why we’re leaving it)
这是一篇相当少见、坦诚的 CloudKit 迁移复盘。César Pinto Castillo 并没有简单批评 CloudKit，恰恰相反，他首先承认：对于小团队来说，CloudKit 几乎提供了一套“不可思议”的能力组合——免费同步、自动身份认证、端到端加密、无服务器运维，以及跨 Apple 平台的共享能力。
但随着产品逐渐发展，CloudKit 的另一面也开始显现：缺乏服务端可观测性、Schema 发布依赖手动操作、不同 Apple 平台间长期存在的同步边缘问题、对 iCloud 账户的强依赖，以及最关键的——无法真正走向 Web 与跨平台生态。最终，César 所在的团队将数据迁移到了基于 Supabase/Postgres 的同步架构。
CloudKit 是苹果生态最重要的护城河之一。但在应用越来越复杂、数据规模越来越大、用户对同步实时性的要求越来越高的今天，它的能力边界也开始显现。在追求“无感同步”的同时，我想苹果也确实需要重新认真审视这个多年未发生明显演进的基础设施了。
用 Swift 手写 LLM 训练内核 (Training an LLM in Swift, Part 1: Taking matrix multiplication from Gflop/s to Tflop/s)
在 Swift 中训练 LLM 听起来多少有些“匪夷所思”，但 Matt Gallagher 做了一次非常硬核的性能探索：不依赖现成机器学习框架，而是从手写矩阵乘法开始，一步步将基础 Swift 实现从 2.8 Gflop/s 优化到 1.1 Tflop/s。文章通过一个完整的优化过程，展示了高性能 Swift 的现实面貌：Swift 并不是不能快，但当你逐渐逼近硬件能力时，也将不可避免地进入 UnsafeBufferPointer、SIMD、并发切片、内存布局与 GPU tile 优化的世界。
这篇文章的价值并不在于鼓励开发者手写机器学习内核。恰恰相反，作者反复强调，生产环境应该优先使用 Accelerate、BNNS、Core ML、MPSGraph 等成熟框架。
当 Swift 被优化到接近 C 的程度时，它还能否保持原本的可读性与优雅？这篇文章给出了一个非常具体，也很诚实的答案。
Swift 适合写 App，但不适合训练 ML 模型 (Swift Is Great for Apps, Not for Training ML Models)
上一篇文章还在展示如何将 Swift 手写矩阵乘法一路优化到 Tflop/s，这篇文章则从另一个角度泼了盆冷水：Mohammad Azam 认为，Swift 与 Core ML 非常适合“部署”机器学习模型，但并不适合承担现代机器学习训练流程本身。Mohammad 指出，真正耗费时间的往往不是模型训练，而是数据清洗、特征工程、归一化、Pipeline 组合与实验迭代，而这些恰恰是 Python 生态最成熟、最顺手的领域。
Swift 并非不能触碰机器学习底层，但当问题从“性能”转向“数据科学工作流”后，语言与生态的重心差异便会迅速显现。这也凸显了 Swift 当前的一个困境：它具备进入多个领域的语言能力，但在应用开发之外，配套生态仍不足以支撑同等顺畅的开发体验。
工具
Swift MarkdownEngine
MarkdownEngine 是 Nodes 团队从自家 macOS Markdown 应用中抽离并开源的原生编辑器引擎。它不是 HTML 渲染器，也不是 WebView 包装，而是基于 TextKit 2 与 AppKit 构建，并桥接到 SwiftUI 的 source-style Markdown 编辑器：文本仍保持纯 Markdown，但在编辑时提供类似 Obsidian Live Preview / iA Writer 的实时样式。项目支持 wiki link、图片嵌入、代码块高亮、LaTeX、任务列表、Writing Tools，以及针对代码、公式和链接的拼写检查抑制。
TextKit 2 文档稀薄、行为细节多，而这个项目把一套已在 Nodes.app 中使用的编辑器能力开源出来，对正在开发写作、笔记或知识管理类 macOS 应用的开发者很有参考价值。
Harness：让 AI 像真实用户一样测试你的 App
Harness 是由 Alan Wizemann 开发的一款原生 macOS 开发者工具，可以驱动 iOS Simulator、macOS App 和 Web App。你用自然语言写下目标，选择一个 persona，Harness 会让 LLM agent 基于截图观察界面、执行点击和输入，并生成可回放的运行路径、成功或失败结论，以及按类型记录的 UX friction。相比单纯让 AI “操作应用”，它更像是把 AI agent、截图、事件日志、凭证脱敏、运行回放和摩擦分类整合成了一套面向开发阶段的用户测试工作台。
目前项目仍处于 alpha 阶段，Web 端依赖 WebKit，iOS/macOS 的 Set-of-Mark 定位能力还在规划中，因此更适合用于探索产品体验中的模糊点和死角，而不是替代确定性的回归测试。不过从 Swift 6、SwiftUI、SwiftData、actor 化的执行流程、JSONL run log，以及跨 Anthropic/OpenAI/Gemini 的模型抽象来看，它已经不是一个简单 demo，而是一个很值得观察的 AI-native developer tool 样本。
传统 UI 测试更擅长验证开发者预设好的路径，而 Harness 试图回答另一个问题：一个带着具体目标和身份设定的真实用户，会不会在你的界面中顺利完成任务。