Fatbobman's Swift Weekly #136
The Vanishing WWDC Wishlists
The Vanishing WWDC Wishlists
WWDC 2026 is just 20 days away. Every year around this time, I usually see many developers sharing their WWDC wishlists, jotting down their predictions and expectations. But this year, at least by the time I was putting together this issue, there seemed to be noticeably fewer such posts than around the same time last year. Has developers' anticipation for WWDC waned, or are more of us simply adopting the mindset of "keeping expectations low to be pleasantly surprised"?
Perhaps the issue isn’t a lack of anticipation, but rather that the traditional format of a wishlist is no longer quite sufficient. In the past, we looked forward to a specific API, framework, or feature. Now, however, as software development rapidly pivots toward the AI Agent era, our expectations themselves have become much harder to clearly articulate.
A year ago, few developers could have predicted that software development would enter the AI Agent era so swiftly. Even if we hoped for better AI support in Xcode, prior to the release of Xcode 26.3, we probably wouldn’t have imagined that Apple would provide such seamless Agent integration right within the IDE. Applications and APIs are no longer just interfaces for consumers or developers; they can now become objects for AI Agents to understand, invoke, and orchestrate. AI is no longer merely a development tool; it acts as a new participant, deeply involved in the very construction and utilization of software services.
I believe this perfectly captures why many developers feel a mix of anticipation and uncertainty heading into WWDC 2026. We hope to see updated features, more stable frameworks, and a clearer platform direction. Yet, at the same time, we are pondering how to maintain our uniqueness and indispensability as developers in this new paradigm, and how to build better services alongside AI.
Let’s wait and see just how many changes WWDC 2026 will bring.
BTW: Last week, I had the incredible honor of being featured in the recently announced Apple Developer Community Spotlight. As a content creator, receiving this recognition is both an encouragement and a driving force for me: a reminder to keep writing earnestly and continue delivering valuable content to all of you. A heartfelt thank you to everyone who has read, shared feedback, and supported me along the way.
Previous Issue｜Newsletter Archive
📢 Sponsor Fatbobman’s Swift Weekly
Promote your product to Swift & iOS developers across:
- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate
Perfect for developer tools, courses, and services.
Enjoyed this issue? Buy me a coffee ☕️
Recent Recommendations
URLSession to Electrons: How Networking works on iOS
Most iOS developers know that a URLSessionDataTask does not actually begin until you call resume(). But what really happens after that? In this long-form article, Jacob Bartlett follows an ordinary network request all the way down the stack — from URLSession, CFNetwork, TCP/IP, and Wi-Fi to radio signals, antennas, and electromagnetic waves. Along the way, he connects concepts developers often use but rarely fully understand, including HTTP, DNS, TCP, QUIC, and IPv6, while also exploring Network.framework, the XNU TCP stack, Wi-Fi frame structures, and cellular scheduling mechanisms inside iOS.
A simple
resume()call may sit atop decades of protocol and infrastructure evolution. Modern software exists on layers upon layers of abstraction, and most of the time, we are simply fortunate enough to live in an era where those abstractions remain stable.
When AI and Xcode Fight: I Built a Tool to Keep the Peace
Xcode’s build system was never truly designed for parallel development. When multiple tasks build simultaneously, DerivedData, ModuleCache, SwiftPM caches, and even Simulators can collide with one another — and this problem becomes dramatically worse in multi-agent AI workflows. In this article, Maples7 introduces his solution: VibeChard. Built on Git Worktree, it creates isolated build sandboxes for each AI agent while separating DerivedData, ModuleCache, SwiftPM caches, and Simulator environments. Most interestingly, it does not require developers to modify build commands directly. Instead, it transparently intercepts xcodebuild via a PATH shim, allowing the entire toolchain — including Tuist and Fastlane — to operate inside isolated environments automatically.
More than just a utility, this project highlights a deeper issue emerging in the age of AI coding: as code generation speeds accelerate dramatically, traditional development toolchains must also evolve their isolation and infrastructure capabilities.
Has Swift Really Become a Mess? Some Honest Thoughts After Years of Using It
Swift becoming increasingly complex is an undeniable reality. But does that mean Swift has become a bad language? In this article, 迷途酱 revisits Swift’s “expansion” through the lens of real-world language evolution constraints. The author argues that much of the complexity people complain about comes from Swift simultaneously serving multiple roles: an application language, a systems language, a DSL host, and even a server-side language. Concurrency safety and ownership models themselves also belong to the category of “hard complexity” inherent to computer science.
The article discusses rapidly growing concepts such as Sendable, actor isolation, borrowing, and ~Copyable, while also candidly criticizing Swift’s concurrency keywords, increasingly dense generics syntax, and the “magic” behind SwiftUI. One particularly thought-provoking point is the idea that Swift is effectively “multiple layers of a language.” Most developers building everyday apps do not actually need to carry the full weight of the language’s complexity, yet WWDC sessions and official documentation often present all of these features side by side.
Writing shell scripts for Xcode Cloud
Xcode Cloud is easy to get started with, but in real-world projects many automation workflows still rely on shell scripts. Using “automatically creating a GitHub Release after archiving” as an example, Amy Delves demonstrates how to leverage Xcode Cloud environment variables to determine whether a build originated from the main branch, extract version and build numbers from an archive, and create releases via the GitHub API.
The example itself is fairly straightforward, but it nicely illustrates that Xcode Cloud is more than just a “click a few buttons to run tests” service. With environment variables, script hooks, and external APIs, it can support much richer release automation workflows.
Why CloudKit is amazing and why we’re leaving it
This is a surprisingly candid and nuanced retrospective on migrating away from CloudKit. Rather than criticizing it outright, César Pinto Castillo first acknowledges that for small teams, CloudKit offers an almost unbelievable combination of features: free sync, automatic authentication, end-to-end encryption, serverless infrastructure, and built-in sharing across Apple platforms.
But as their product evolved, CloudKit’s limitations became increasingly apparent: limited server-side observability, manual schema deployment steps, long-standing synchronization edge cases across Apple platforms, heavy reliance on iCloud accounts, and most importantly, the inability to truly expand toward the Web and cross-platform ecosystems. Eventually, César’s team migrated to a Supabase/Postgres-based synchronization architecture.
CloudKit remains one of the strongest moats in Apple’s ecosystem. But as apps grow more complex, datasets larger, and user expectations around synchronization latency higher, its boundaries are becoming increasingly visible. In pursuing “invisible sync,” Apple may also need to seriously rethink this infrastructure layer that has seen relatively little evolution over the years.
Training an LLM in Swift, Part 1: Taking matrix multiplication from Gflop/s to Tflop/s
Training an LLM in Swift sounds somewhat absurd at first glance, but Matt Gallagher delivers an impressively deep performance exploration. Starting from handwritten matrix multiplication — without relying on existing ML frameworks — he gradually optimizes a basic Swift implementation from 2.8 Gflop/s to 1.1 Tflop/s. Through a complete optimization journey, the article reveals what high-performance Swift actually looks like in practice: Swift can absolutely be fast, but as you approach hardware limits, you inevitably enter a world of UnsafeBufferPointer, SIMD, concurrent slicing, memory layout tuning, and GPU tile optimization.
The article is not advocating for handwritten ML kernels in production. On the contrary, Matt repeatedly emphasizes that developers should prefer mature frameworks such as Accelerate, BNNS, Core ML, and MPSGraph whenever possible.
Once Swift is pushed close to C-level performance, can it still preserve the readability and elegance that originally made Swift appealing? This article offers a remarkably concrete — and honest — answer.
Swift Is Great for Apps, Not for Training ML Models
While the previous article demonstrated how handwritten Swift matrix multiplication could be optimized all the way to Tflop/s territory, this article pours some cold water on the idea from a different angle. Mohammad Azam argues that Swift and Core ML are excellent for deploying machine learning models, but poorly suited for modern machine learning training workflows. He points out that the majority of effort in ML development is rarely spent on training itself, but rather on data cleaning, feature engineering, normalization, pipeline composition, and iterative experimentation — areas where the Python ecosystem remains vastly more mature and ergonomic.
Swift is not incapable of reaching into the lower layers of machine learning. But once the problem shifts from “performance” to “data science workflows,” the differences in language priorities and ecosystem maturity quickly become obvious. It also highlights one of Swift’s current dilemmas: while the language itself is capable of expanding into many domains, its surrounding ecosystem still struggles to provide equally smooth experiences outside of application development.
Tools
Swift MarkdownEngine
MarkdownEngine is a native editor engine extracted and open-sourced by the team behind Nodes, their macOS Markdown application. It is neither an HTML renderer nor a WebView wrapper. Instead, it is a source-style Markdown editor built on TextKit 2 and AppKit, then bridged into SwiftUI. The editor preserves plain Markdown text while providing live styling similar to Obsidian Live Preview or iA Writer. Features include wiki links, image embedding, syntax highlighting, LaTeX, task lists, Writing Tools support, and suppression of spell-checking for code, formulas, and links.
TextKit 2 documentation remains sparse and full of behavioral quirks. By open-sourcing an editor stack already used in Nodes.app, this project offers valuable reference material for developers building writing, note-taking, or knowledge-management apps on macOS.
Harness: Let AI Test Your App Like a Real User
Harness is a native macOS developer tool created by Alan Wizemann that can drive iOS Simulators, macOS apps, and Web apps. You describe a goal in natural language, choose a persona, and Harness allows an LLM agent to observe the UI through screenshots, perform clicks and text input, then generate replayable execution paths, success or failure reports, and categorized UX friction logs. Rather than simply letting AI “operate an app,” it feels more like a developer-focused user testing workstation that combines AI agents, screenshots, event logs, credential redaction, replay systems, and friction analysis.
The project is still in alpha. Web support currently depends on WebKit, and Set-of-Mark targeting for iOS/macOS is still planned for the future. As a result, it is better suited for exploring ambiguous UX issues and hidden usability dead-ends than replacing deterministic regression testing. Still, from its use of Swift 6, SwiftUI, SwiftData, actor-based execution flows, JSONL run logs, and cross-provider abstractions for Anthropic/OpenAI/Gemini models, it is already far beyond a simple demo — and a fascinating example of an AI-native developer tool.
Traditional UI testing excels at validating predefined flows created by developers. Harness is attempting to answer a different question: can a real user, with a specific goal and persona, actually complete a task successfully inside your interface?
Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.
消失的 WWDC 愿望单
距离 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。作为一名内容创作者，能够得到这样的认可，对我来说既是鼓励，也是鞭策：继续认真写下去，继续把有价值的内容带给大家。感谢每一位长期阅读、反馈和支持我的朋友。
如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 Buy Me a Coffee 支持我的创作。
近期推荐
从 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 试图回答另一个问题：一个带着具体目标和身份设定的真实用户，会不会在你的界面中顺利完成任务。