Fatbobman's Swift Weekly #146
It’s Not That the Models Are Slower—The Tasks Have Become BiggerLately, even tasks that I consider relatively simple often take AI several minutes—or sometimes even tens of minutes—to complete. It gave me the impression that as models become more capable, they somehow have to become slower. In reality, the main reason lies with me. Although today’s AI agents let us choose different models and reasoning levels, it’s much easier—and often more reliable—to simply hand even straightforward tasks to the most capable models. At the same time, modern agents no longer limit themselves to the small change you explicitly requested. They proactively expand their search, analyze whether the modification could affect other parts of the project, and try to identify potential issues before they happen. The models may be more powerful than ever, but they’re also taking on substantially more work for every task. There’s another factor as well. As my trust in these models has grown, so has the scope of the tasks I assign to them. What used to be “refactor a function” or “improve a screen” has gradually become “implement a feature,” “build a module,” or even “create an entire product.” Without realizing it, I’ve started treating AI agents as genuine collaborators. The pace at which model performance improves simply hasn’t kept up with the way we now use them. In other words, developers are no longer pursuing only “writing code faster.” Increasingly, we’re using AI to write better code, even if it takes longer. The shift from question-answering to task delivery has happened in just a single year. As we grow accustomed to waking up and reviewing completed work, the real bottleneck is quietly moving elsewhere. We used to ask whether a model was capable of completing a task. Today, the more important questions are how to define a clear, verifiable objective, and how to reduce the cost of achieving it. AI is becoming more like a teammate, and the ability to organize and decompose work effectively is becoming the next competitive advantage. 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 RecommendationsBluetooth without the delegate danceDelegates remain a challenge many developers continue to face years after the introduction of Swift Concurrency. Not only do they often lead to cumbersome code organization, but under Swift 6’s strict concurrency checking they also become increasingly difficult to integrate naturally with modern concurrent code. Kyle Browning leverages Swift 6.2’s Custom Executor to bind CoreBluetooth’s callback queue directly to an Actor’s execution context, allowing delegate callbacks to run naturally within Actor isolation without additional locks, thread hopping, or synchronization logic.
Working with Xcode on CIAs more developers adopt self-hosted macOS runners or cloud-based CI, reliably managing Xcode, Simulator Runtimes, and code-signing environments has become an essential part of engineering infrastructure. Dmitry Rodionov shares a collection of practical techniques for using the Xcode CLI in CI, including managing multiple Xcode installations with Squeeze every last bit of value out of GitHub ActionsOptimizing GitHub Actions doesn’t necessarily mean more aggressive caching, more complex workflows, or additional conditional logic. Instead, this article advocates a more valuable principle: every CI run should match the actual risk introduced by a change. Starting from the investigation of an apparently ordinary flaky test, Snow discusses how deterministic tests eliminate unnecessary reruns, how portable checks can be moved to Linux while leaving Xcode-dependent validation to macOS, and how Build, Test, or Build for Testing can be selected dynamically based on change risk to avoid wasting expensive runner time.
Building adaptive non-modal panels in SwiftUIStarting with WWDC26, iPhone-only apps running through iPhone Mirroring on a Mac or on an iPad enter a resizable environment. This means relying solely on
SwiftUI @ContentBuilder - Faster Type Checking in Xcode 27Xcode 27 introduces the new
Tooltswift: A Lightweight Swift Runtime Built with RustWithout relying on the Swift toolchain, LLVM, code generation, or any C dependencies, tswift can parse, semantically analyze, and execute Swift source code. Developed by Francis Chong, tswift implements the Swift frontend entirely in Rust, handling lexical, syntactic, and semantic analysis before interpreting Swift language semantics and standard library behavior through a tree-walking runtime. Beyond the language runtime itself, the project is also exploring framework support. SwiftUI already has a basic rendering pipeline, while Charts currently implements 58 of 60 range-related members, can render Web SVG output, and can bridge to Apple’s native Charts framework on iOS.
Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it. 不是模型变慢了，是任务变大了最近，即便是一些我认为并不算复杂的工作，AI 交付结果也常常需要几分钟，甚至几十分钟。这让我产生了一种错觉：难道随着模型能力不断增强，速度只能越来越慢？ 其实，真正的原因更多来自于我自己。虽然 Agent 提供了模型和思考强度的调整选项，但为了省事，也为了追求更高的成功率，我越来越习惯把一些原本并不复杂的任务直接交给高级模型。与此同时，如今的 Agent 也不会像过去那样只关注你要求修改的那一小块代码，而是会主动扩大搜索范围，分析改动是否会影响整个项目，并尝试提前发现潜在问题。模型虽然更强了，但完成一次任务所承担的工作也明显更多了。 除此之外，随着我对模型能力的信任不断提高，交给它的任务粒度也发生了变化。从最初修改一个函数、优化一个页面，到实现一个功能、完成一个模块，甚至直接开发一个产品，我已经不知不觉把 Agent 当成了一位真正的协作者。模型速度的提升，已经跟不上使用方式变化的速度。 换句话说，开发者追求的已经不再只是“更快地写代码”，而是借助 AI“更慢地写出更好的代码”。 从问答式，到交付式，只用了短短一年时间。当我们开始习惯一觉醒来接收成果时，真正的瓶颈也悄然发生了变化。过去，我们关心的是模型能不能完成任务；现在，更重要的问题变成了如何定义一个清晰、可验证的目标，以及如何降低实现目标的成本。模型越来越像团队成员，而高质量地组织和拆解工作，也正在成为新的效率竞争力。 如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 Buy Me a Coffee 支持我的创作。 近期推荐用现代并发技术开发蓝牙应用 (Bluetooth without the delegate dance)Delegate 仍是很多开发者在 Swift Concurrency 已经推出数年后不得不面对的问题：不仅代码组织繁琐，在 Swift 6 的严格并发检查下，也越来越难与现代并发代码自然协作。Kyle Browning 利用 Swift 6.2 的 Custom Executor，将 CoreBluetooth 的回调队列与 Actor 的执行上下文绑定，使 Delegate 回调天然运行在 Actor 隔离环境中，无需额外的锁、线程切换或同步逻辑。
CI 环境下的 Xcode 管理实践 (Working with Xcode on CI)随着越来越多开发者采用自建 macOS Runner 或云端 CI，稳定地管理 Xcode、Simulator Runtime 与签名环境，已成为工程维护的重要组成部分。Dmitry Rodionov 围绕 Xcode CLI 在 CI 中的使用，总结了不少个人心得，例如使用 榨干 GitHub Actions 的最后一点价值GitHub Actions 的优化，未必意味着更激进的缓存、更复杂的 Workflow，或更多的条件判断。这篇文章提出了一个值得借鉴的思路：让每一次 CI 执行都与实际风险相匹配。Snow 从一次看似普通的 Flaky Test 排查开始，逐步讨论了如何用确定性测试消除无意义的重跑、将可移植的检查迁移到 Linux、仅把真正依赖 Xcode 的验证留给 macOS，以及根据变更风险动态选择 Build、Test 或 Build for Testing，避免昂贵的 Runner 执行不必要的工作。
在 SwiftUI 中构建自适应非模态面板 (Building adaptive non-modal panels in SwiftUI)从 WWDC 26 开始，iPhone-only 应用在通过 iPhone Mirroring 显示到 Mac，或在 iPad 上运行时，将进入可变尺寸环境。这意味着仅依赖
SwiftUI @ContentBuilder：大幅提升 Xcode 27 编译效率 (SwiftUI @ContentBuilder - Faster Type Checking in Xcode 27)Xcode 27 引入了新的
工具tswift: 用 Rust 构建轻量 Swift 运行时无需 Swift 工具链、LLVM、代码生成或 C 依赖，即可解析、语义分析并执行 Swift 源码。Francis Chong 开发的 tswift 以纯 Rust 实现了 Swift 前端，完成词法、语法与语义分析，再通过树遍历运行时实现 Swift 的语言语义与标准库行为。 除语言运行时外，项目也在探索框架层面的支持：SwiftUI 已具备基础渲染能力，Charts 支持覆盖 58/60 个范围成员，可输出 Web SVG，并可下沉到 iOS 原生 Charts。
Welcome to my blog Fatbobman's Swift Blog( 肘子的Swift记事本 )
|
