Fatbobman's Swift Weekly #111
Homebrew 5.0: Parallel Downloads, MCP Integration, and Intel's Final Countdown
Homebrew 5.0: Parallel Downloads, MCP Integration, and Intel’s Final Countdown
A few days ago, I routinely ran brew upgrade after typing brew update. To my surprise, the terminal displayed something I’d never seen before—numerous packages downloading in parallel, neatly arranged and progressing simultaneously. After a moment of astonishment, I learned from the news: Homebrew had released version 5.0.
This update brings substantial enhancements. Beyond enabling parallel downloads by default, it officially promotes ARM64/AArch64 devices—including Raspberry Pi, ARM mini PCs, and WSL2 on Windows ARM—to Tier 1 support, while adding various new commands and capabilities. Most notably, the official support for local MCP (Model Context Protocol) services stands out. Through brew mcp-server, developers can enable AI agents to operate Homebrew automatically, seamlessly integrating brew into the emerging AI workflow. This is truly a forward-thinking update.
However, not all of the news is equally encouraging. With macOS Tahoe 26 very likely to be the last version supporting Intel x86_64, Homebrew has adjusted its own support strategy accordingly: starting in September 2026, Intel Macs will be downgraded to Tier 3, and by September 2027 (or later), support for Intel may end entirely.
Undeniably, over the past decade, Intel architecture brought Apple a vast pool of “potential users”—its ability to run Windows natively attracted many users outside the Mac ecosystem to choose Apple devices for compatibility reasons, providing crucial support for Apple’s market share. Now, with Apple Silicon’s maturity, Intel Macs are destined to join the MOS 6502 and PowerPC as important chapters in Apple’s hardware history, gradually drawing to a close in the near future.
Looking back, every major CPU transition has sparked a wave of design innovation at Apple, giving rise to iconic products that defined their eras—from the Lisa pioneering graphical interfaces in the 68k era, to the translucent aesthetics and colorful clamshell iBooks of the PowerPC era, and later the white and black MacBooks and the game-changing MacBook Air of the Intel era.
In the age of the M-series chips, Apple has achieved remarkable leaps in performance, efficiency, and system integration, yet in terms of hardware appearance and industrial design language, we have not yet seen a breakthrough with a truly lasting, era-defining impact.
I hope the next design worthy of the history books arrives soon. Don’t keep us waiting too long.
Previous Issue｜Newsletter Archive
📢 Sponsor Fatbobman’s Swift Weekly
Promote your product to Swift & iOS developers across:
- Blog: 70,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
Grow on iOS 26: Liquid Glass Adaptation in UIKit + SwiftUI Hybrid Architecture
Grow is a health management app that has received App Store editorial features in 173 countries and regions, with over 180,000 five-star reviews. When adapting to iOS 26’s Liquid Glass design language, the team encountered numerous challenges: How to achieve native morph effects in a UIKit + SwiftUI hybrid architecture? How to precisely control Scroll Edge Effects? How to handle dynamic sizing of custom navigation bar elements? Shuhari, one of Grow’s developers, shares the team’s practical experience from this adaptation process. The article covers transformation solutions for Sheet, Navigation, Popover scenarios, diving deep into implementation details like UIBarButtonItem size calculations and CABackdropLayer side-effect handling, while also demonstrating how to create “glass text” effects using Core Text. All core concepts come with complete demo projects.
Pitfalls of Parameterized Tests
Parameterized Tests are a distinctive new feature in Swift Testing, enabling developers to expand test coverage while minimizing code duplication, easily verifying multiple input sets for the same logic. However, Alex Ozun discovered during large-scale migration that while convenient, this feature harbors easily overlooked pitfalls that can quietly reduce test effectiveness. The article demonstrates common traps through multiple examples and provides practical recommendations such as avoiding test parameter reuse on both sides of #expect expressions and clearly distinguishing between example-based and property-based tests.
Task Identity
In SwiftUI, task / onAppear execute once when a view “appears,” but unlike views, they don’t automatically track dependencies—if a task closure depends on some state, the task itself won’t automatically re-trigger when that state changes. Chris Eidhof demonstrates this easily overlooked issue using remote image loading as an example, recommending explicitly specifying task “identity,” such as using .task(id: url), allowing relevant dependencies (like URLs or composite identifiers formed from multiple values) to participate in task re-execution conditions, enabling SwiftUI to cancel old tasks and start new ones when dependencies update. The author reminds that whenever using task / onAppear in views, ensure relevant dependencies are reflected in the task’s identity.
One Swift mistake everyone should stop making today
Swift has been around for ten years, but many Swift APIs used in daily development are still just simple wrappers around Objective-C APIs, which can lead to easily overlooked serious issues. Paul Hudson demonstrates this with replacingOccurrences(of:with:): when handling characters composed of multiple Unicode scalars (like flag emojis), this method can incorrectly “split” characters and match non-existent sequences, producing completely wrong results. Paul’s advice is simple: prioritize using Swift’s native replacing(_:with:), which correctly handles Unicode by character semantics, avoiding these bizarre and hard-to-debug string errors.
With Foundation’s reconstruction in the Swift community complete, on platforms like macOS, for APIs with similar functionality, prioritize the Swift native versions provided in the new Foundation. This not only avoids the above issues but also prepares for cross-platform compatibility.
Learning About Swift Concurrency (from Matt Massicotte’s Blog) with a Zettelkasten
Swift’s concurrency evolution hasn’t been smooth sailing. After introducing the Approachable Concurrency concept, different compilation option combinations can even produce completely different compilation results, with understanding costs rising accordingly. Christian Tietze initially planned a brief demonstration: showing how to use the Zettelkasten method to digest Matt Massicotte’s blog posts about Swift concurrency, but kept encountering deeper complexities during practice—for example, actors cannot directly satisfy Sendable protocols with nonisolated requirements unless members are explicitly marked as nonisolated or nonisolated(unsafe). By the time he came to his senses, the video had reached 80 minutes.
The video excellently presents the true nature of “deep technical learning”: not linear knowledge accumulation, but full of confusion, hypotheses, and open questions to be verified later with code and documentation. It also demonstrates that the Zettelkasten method is particularly suited for complex, continuously evolving topics like Swift concurrency, building searchable, linkable note networks that support understanding’s gradual convergence over time.
Claude Code Skills: Features and Usage Experience
Ein Verne introduces Claude’s newly launched Skills mechanism—a modular system for extending Claude’s capabilities. Compared to MCP, Slash Commands, and traditional plugins, Skills emphasize composability, portability, and context-window-friendly usage. Each Skill exists as an independent folder containing name, description, operation instructions (SKILL.md), executable scripts, reference documents, and resource files. Claude automatically scans and matches appropriate skills when executing tasks, loading details on-demand through “Progressive Disclosure,” significantly reducing context consumption. The author believes Skills essentially evolve “prompt engineering” into “workflow engineering,” moving Claude from a general intelligent assistant toward maintainable intelligent infrastructure.
Multiplatform with Rust on iOS
Just as many Swift developers hope to bring their code outside the Apple ecosystem, iOS itself maintains considerable openness to other programming languages. Tjeerd in ‘t Veen shares a detailed Rust + iOS integration guide in this article, demonstrating how to elegantly integrate Rust code into iOS projects through Mozilla’s UniFFI. UniFFI can automatically map Rust enums to Swift enums and convert function names from snake_case to camelCase, making Rust modules look like native APIs on the Swift side.
The article provides a complete, actionable workflow: from creating Rust libraries, building static libraries for multiple iOS architectures, packaging XCFrameworks, to finally wrapping them as Swift Packages, with detailed explanations and common pitfall warnings for each step. This solution not only allows iOS projects to consume Rust logic like regular Swift packages but also lays a solid foundation for reusing the same Rust code on Android and other platforms.
Tools
VisualDiffer 2: Rebirth from Objective-C to Swift
Davide Ficano has completely open-sourced his long-running macOS file comparison tool VisualDiffer and thoroughly rewritten it from Objective-C to Swift. This isn’t a simple language migration or AI-assisted conversion, but a from-scratch manual refactor.
Core features remain unchanged:
🟩 Intuitive Comparison - Side-by-side directory differences with color-coded new, modified, or missing files
🧩 Deep Analysis - File-level line-by-line comparison (based on UNIX diff)
🧹 Smart Filtering - Automatically exclude version control files (.git, .svn) and system files (.DS_Store)
⚡ Performance Optimization - Multiple comparison strategies from fast date/size comparison to precise byte-by-byte comparison
On Reddit, the author admits still greatly appreciating Objective-C, but Swift’s potential made him willing to bear the huge migration cost. Rewriting the UI layer (especially NSTableView and delegate patterns) was particularly challenging, initially filled with concurrency attribute annotations, but as understanding deepened, Swift’s advantages gradually became apparent.
FSWatcher: High-Performance Swift Native File System Monitoring Library
okooo5km developed FSWatcher while creating the image compression tool Zipic, needing real-time awareness of image file changes for timely processing. This is a file system monitoring library based on macOS/iOS’s underlying kqueue mechanism, using event-driven rather than polling approaches with minimal resource consumption.
Core features:
🎯 Smart Filtering: Supports multi-dimensional filtering by file type, size, modification time, with chainable combinations
🔍 Predictive Ignoring: Automatically identifies and skips self-generated output files (like *_compressed.jpg), avoiding circular triggers
📁 Recursive Monitoring: Can monitor entire directory trees with depth limits and exclusion rules
⚡ Modern API: Full support for Combine, async/await, and traditional closure callback patterns
The library is ideal as a listener for image processing pipelines, hot reload components for development tools, or building lightweight automatic backup systems and other scenarios requiring real-time file change awareness.
SFSymbolKit: Zero-Maintenance Type-Safe SF Symbols Library
While there are already several libraries for improving the SF Symbols experience, LiYanan‘s SFSymbolKit still stands out: all symbols and availability information are automatically generated directly from system frameworks with one command, truly requiring no manual maintenance.
Core advantages:
✅ Reliable Data Source: Directly reads
/System/Library/PrivateFrameworks/SFSymbols.framework/, 100% synchronized with the system✅ Fully Automated: Just run
./update_symbols.shto update, no manual symbol additions needed✅ Version Aware: Automatically generates
@availableattributes for compile-time symbol compatibility checking✅ User Self-Service: Anyone can update locally without depending on author releases
Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.
Homebrew 5.0：并行加速、MCP 加持，与 Intel 的最后倒计时
几天前，我像往常一样在输入 brew update 后顺手执行了 brew upgrade。出乎意料的是，终端里突然出现了从未见过的画面——大量组件与工具并行下载、整齐排列、同时推进。短暂的惊讶之后，我才从新闻中得知：Homebrew 已经发布了 5.0 版本。
此次更新内容相当丰富。除了默认启用并行下载外，还正式将 Raspberry Pi、ARM 迷你 PC、Windows ARM 上的 WSL2 等 ARM64/AArch64 设备纳入 Tier 1 支持，并新增多项指令与能力。其中，官方提供的本地 MCP 服务尤为引人注目。通过 brew mcp-server，开发者可以让 AI Agent 自动操作 Homebrew，意味着 brew 也顺利接入了正在兴起的 AI 工作流。这是一项颇具时代感的更新。
不过，并非所有消息都同样令人愉快。随着 macOS Tahoe 26 大概率成为最后一个支持 Intel x86_64 的版本，Homebrew 也相应调整了自身的支持策略：从 2026 年 9 月起，Intel Mac 将被降级为 Tier 3；到 2027 年 9 月（或更晚），对 Intel 的支持则可能完全终止。
不可否认，在过去十余年里，Intel 架构为苹果带来了庞大的“潜在用户”：它能原生运行 Windows，让许多本不属于 Mac 生态的用户因兼容性而选择苹果设备，为苹果的市场份额提供了关键支撑。如今，随着 Apple Silicon 的成熟，Intel Mac 注定会与 MOS 6502、PowerPC 等一同成为苹果硬件发展史上的重要篇章，在不久的将来缓缓落幕。
回顾历史，每次 CPU 架构转换都激发了苹果在产品设计上的创新灵感，催生出许多具有时代印记的经典产品——从 68k 时代的 Lisa 开创图形界面先河，到 PowerPC 时代的 iMac G3 半透明美学和彩色贝壳本，再到 Intel 时代的小白/小黑 MacBook 以及重新定义轻薄的 MacBook Air。在 M 系列芯片时代，Apple 在性能、能效与系统集成上实现了跨越式提升，但在硬件外观与工业设计语言上，尚未出现能够留下强烈时代烙印的革新之作。
期待尽早看到可以计入史册的新设计，别让我们等太久。
如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 爱发电，Buy Me a Coffee 支持我的创作。
近期推荐
Grow on iOS 26：UIKit + SwiftUI 混合架构下的 Liquid Glass 适配实战
Grow 是一款在 173 个国家和地区获得 App Store 编辑推荐、拥有超过 18 万五星评价的健康管理应用。在适配 iOS 26 的 Liquid Glass 设计语言时，团队遇到了不少挑战：如何在 UIKit + SwiftUI 混合架构下实现原生的 morph 效果？如何精确控制 Scroll Edge Effect？如何处理自定义导航栏元素的动态尺寸？Grow 的开发者之一 Shuhari，分享了团队在这次适配过程中的实战经验。文章涵盖 Sheet、Navigation、Popover 等场景的改造方案，深入探讨 UIBarButtonItem 尺寸计算、CABackdropLayer 副作用处理等底层细节，还展示了如何利用 Core Text 创造“玻璃文字”效果。所有核心概念都配有完整的 Demo 工程。
警惕参数化测试中的陷阱 (Pitfalls of Parameterized Tests)
参数化测试 (Parameterized Tests)是 Swift Testing 中颇具代表性的新特性，它让开发者能够在最小化重复代码的同时扩大测试覆盖范围，为同一逻辑轻松验证多组输入。然而 Alex Ozun 在大规模迁移实践中发现，这项功能虽然便捷，却也暗藏不少容易忽略的陷阱，甚至可能悄悄降低测试的有效性。文章结合多个示例展示了一些常见陷阱，并提出了如避免在 #expect 两侧重复使用测试参数、明确区分示例测试与属性测试等多项实践建议。
为任务显式指定“身份” (Task Identity)
在 SwiftUI 中，task / onAppear 会在视图“出现”时执行一次，但它们并不会像视图那样自动跟踪依赖——如果任务闭包依赖了某个状态，该状态变化后任务本身不会自动重新触发。Chris Eidhof 以加载远程图片为例，展示了这一容易被忽略的问题，并建议为任务显式指定“身份”（identity），例如使用 .task(id: url)，让相关依赖（如 URL 或由多个值组合而成的复合标识）参与任务的重新执行条件，使 SwiftUI 能在依赖更新时取消旧任务并启动新任务。作者提醒，凡是在视图中使用 task / onAppear 时，都应确保相关的依赖已经体现在任务的身份（identity）中。
Objective-C API 引发的 Unicode 错误 (One Swift mistake everyone should stop making today)
Swift 已经诞生十年了，但在日常开发中开发者使用的很多 Swift API 仍只是对 Objective-C API 的简单包装，这可能会引发一些容易忽视的严重问题。Paul Hudson 在本文中就通过 replacingOccurrences(of:with:) 展示了这种情况：在处理由多个 Unicode 标量组成的字符（如国旗表情）时，该方法可能会“误拆”字符、匹配不存在的序列，从而生成完全错误的结果。Paul 的建议非常简单：在 Swift 中应优先使用原生的 replacing(_:with:)，它能够正确地按字符语义处理 Unicode，避免这些诡异且难以排查的字符串错误。
随着 Foundation 在 Swift 社区重构完成，在 macOS 等平台上，对于具备类似功能的 API，通常应优先选择新 Foundation 中提供的 Swift 原生版本。这样不仅可以避免上述问题，而且也提前为跨平台做好准备。
和 Christian 一起学习 Swift 并发 (Learning About Swift Concurrency (from Matt Massicotte’s Blog) with a Zettelkasten)
Swift 的并发演进并非一帆风顺，引入 Approachable Concurrency 概念后，不同编译选项组合甚至可能得到完全不同的编译结果，理解成本也随之水涨船高。Christian Tietze 原本只打算做一个简短演示：展示如何使用卡片盒笔记法（Zettelkasten）来消化 Matt Massicotte 关于 Swift 并发的博客文章，结果在实作过程中不断撞见更深层的复杂性——例如：actor 无法直接满足带有 nonisolated 要求的 Sendable 协议，除非显式将成员标记为 nonisolated 或 nonisolated(unsafe)。等他回过神来，视频已经录到了 80 分钟。
视频很好地呈现了“深入学技术”的真实面貌：不是线性的知识堆叠，而是充满困惑、假设以及有待日后用代码与文档验证的开放问题。同时也侧面证明，卡片盒笔记法非常适合应对 Swift 并发这类复杂且持续演进的主题，通过构建可搜索、可链接的笔记网络，承载理解在时间维度上的逐步收敛。
Claude Code Skills 功能介绍以及使用经验
Ein Verne 在本文中介绍了 Claude 新推出的 Skills 机制 —— 一种用于扩展 Claude 能力的模块化体系。相比 MCP、Slash Commands 和传统插件，Skills 更强调可组合性、可移植性以及对上下文窗口的友好使用方式。每个 Skill 都以独立文件夹的形式存在，包含名称、描述、操作指令（SKILL.md）、可执行脚本、参考文档与资源文件等。Claude 会在执行任务时自动扫描并匹配合适的技能，并通过“渐进式披露（Progressive Disclosure）”按需加载细节，从而显著降低上下文消耗。作者认为，Skills 本质上将“提示词工程”演进为“工作流工程”，让 Claude 从通用智能助手进一步迈向可维护的智能基础设施形态。
在 iOS 中集成 Rust：基于 UniFFI 的多平台工作流 (Multiplatform with Rust on iOS)
就像许多 Swift 开发者希望把代码带出苹果生态一样，iOS 本身也对其他开发语言保持着相当开放的态度。Tjeerd in ‘t Veen 在这篇文章中分享了一份详实的 Rust + iOS 集成指南，展示如何通过 Mozilla 的 UniFFI 将 Rust 代码优雅地接入到 iOS 项目中。UniFFI 能将 Rust 的 enum 自动映射为 Swift enum，并把函数名从 snake_case 转为 camelCase，让 Rust 模块在 Swift 侧看起来就像原生 API。
文章给出了一整套可落地的工作流：从创建 Rust 库、为多种 iOS 架构构建静态库、打包 XCFramework，到最终封装成 Swift Package，每一步都有详细说明与常见陷阱提示。这套方案不仅让 iOS 工程可以像使用普通 Swift 包一样消费 Rust 逻辑，也为后续在 Android 等平台复用同一份 Rust 代码打下了良好基础。
工具
VisualDiffer 2：从 Objective-C 到 Swift 的重生
Davide Ficano 将其经营多年的 macOS 文件对比工具 VisualDiffer 完全开源，并从 Objective-C 彻底重写为 Swift。这不是简单的语言迁移或 AI 辅助转换，而是一次从零开始的手工重构。
核心功能保持不变：
🟩 直观对比 - 并排展示目录差异，用颜色标识新增、修改或缺失的文件
🧩 深入分析 - 支持文件级别的逐行对比（基于 UNIX diff）
🧹 智能过滤 - 自动排除版本控制文件（.git、.svn）和系统文件（.DS_Store）
⚡ 性能优化 - 支持多种对比策略，从快速的日期/大小对比到精确的逐字节对比
在 Reddit 上，作者坦言自己依旧非常欣赏 Objective-C，但 Swift 的潜力让他愿意承受迁移的巨大成本。UI 层（特别是 NSTableView 与 delegate 模式）的重写过程尤为艰难，早期充满了并发属性标注，但随着理解加深，Swift 的优势逐渐显现。
FSWatcher：高性能的 Swift 原生文件系统监控库
十里 在开发图片压缩工具 Zipic 时，需要实时感知图片文件变化以便进行及时处理，为此开发了 FSWatcher。这是一个基于 macOS/iOS 底层 kqueue 机制的文件系统监控库，采用事件驱动而非轮询方式，资源消耗极低。
核心特性：
🎯 智能过滤：支持按文件类型、大小、修改时间等多维度过滤，并可链式组合
🔍 预测性忽略：自动识别并跳过自身生成的输出文件（如 *_compressed.jpg），避免循环触发
📁 递归监控：可监控整棵目录树，支持深度限制与排除规则
⚡ 现代 API：完整支持 Combine、async/await 以及传统闭包回调模式
该库非常适合作为图片处理流程的监听器、开发工具的热重载组件，或构建轻量化自动备份系统等需要实时文件变动感知的场景。
SFSymbolKit：零维护的类型安全 SF Symbols 库
市面上已有不少用于改进 SF Symbols 使用体验的库，但 LiYanan 的 SFSymbolKit 仍然颇具特色：所有符号与可用性信息都由工具直接从系统框架自动生成，一键即可完成更新，真正做到无需人工维护。
核心优势：
✅ 数据源可靠：直接读取
/System/Library/PrivateFrameworks/SFSymbols.framework/，与系统 100% 同步✅ 完全自动化：运行
./update_symbols.sh即可更新，无需手动添加新符号✅ 版本感知：自动生成
@available属性，编译时检查符号兼容性✅ 用户自助：任何人都可以在本地更新，不依赖作者发版