Fatbobman's Swift Weekly #136
The Vanishing WWDC WishlistsWWDC 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 WeeklyPromote your product to Swift & iOS developers across: - Blog: 50,000+ monthly visitors Perfect for developer tools, courses, and services. Enjoyed this issue? Buy me a coffee ☕️ Recent RecommendationsURLSession to Electrons: How Networking works on iOSMost iOS developers know that a
When AI and Xcode Fight: I Built a Tool to Keep the PeaceXcode’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 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 ItSwift 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 Writing shell scripts for Xcode CloudXcode 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 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 itThis 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.
Training an LLM in Swift, Part 1: Taking matrix multiplication from Gflop/s to Tflop/sTraining 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 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.
Swift Is Great for Apps, Not for Training ML ModelsWhile 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.
ToolsSwift MarkdownEngineMarkdownEngine 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.
Harness: Let AI Test Your App Like a Real UserHarness 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.
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 开发者都知道：
当 AI 和 Xcode 打架时：我写了个工具来拉架Xcode 的构建系统从未真正为“并行开发”设计过。多个任务同时构建时，DerivedData、ModuleCache、SwiftPM 缓存乃至 Simulator 都可能互相踩踏，而这一问题在 AI Agent 并行开发场景下被进一步放大。Maples7 在本文中介绍了他的解决方案：VibeChard。它基于 Git Worktree，为每个 AI Agent 创建独立的构建沙箱，并进一步隔离 DerivedData、ModuleCache、SwiftPM 缓存以及模拟器环境。最有意思的是，它并不要求开发者修改构建命令，而是通过 PATH shim 透明接管 Swift 真的被搞得乱七八糟了吗？写了几年之后说点实话Swift 变得越来越复杂，这是一个不争的事实。但这是否意味着 Swift 已经变成了一门糟糕的语言？迷途酱 从语言演进的现实约束出发，重新审视 Swift 这些年的“膨胀”。作者认为，许多被吐槽的复杂度，其实来自 Swift 同时承担应用层、系统级、DSL 宿主与服务端语言等多重目标，而并发安全与所有权模型本身，也属于计算机科学层面的“硬复杂度”。 文章既讨论了 Xcode Cloud 进阶：Shell 脚本自动化实战 (Writing shell scripts for Xcode Cloud)Xcode Cloud 的上手体验已经足够简单，但在真实项目中，许多自动化需求仍然需要借助 shell scripts 完成。Amy Delves 以“在归档完成后自动创建 GitHub Release”为例，展示了如何结合 Xcode Cloud 提供的环境变量判断当前构建是否来自 我们为什么离开了很棒的 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 的同步架构。
用 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 并不是不能快，但当你逐渐逼近硬件能力时，也将不可避免地进入 这篇文章的价值并不在于鼓励开发者手写机器学习内核。恰恰相反，作者反复强调，生产环境应该优先使用 Accelerate、BNNS、Core ML、MPSGraph 等成熟框架。
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 MarkdownEngineMarkdownEngine 是 Nodes 团队从自家 macOS Markdown 应用中抽离并开源的原生编辑器引擎。它不是 HTML 渲染器，也不是 WebView 包装，而是基于 TextKit 2 与 AppKit 构建，并桥接到 SwiftUI 的 source-style Markdown 编辑器：文本仍保持纯 Markdown，但在编辑时提供类似 Obsidian Live Preview / iA Writer 的实时样式。项目支持 wiki link、图片嵌入、代码块高亮、LaTeX、任务列表、Writing Tools，以及针对代码、公式和链接的拼写检查抑制。
Harness：让 AI 像真实用户一样测试你的 AppHarness 是由 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 样本。
Welcome to my blog Fatbobman's Swift Blog( 肘子的Swift记事本 )
|
