Homebrew 5.0：并行加速、MCP 加持，与 Intel 的最后倒计时 | 肘子的 Swift 周报 #0111

在 weekly.fatbobman.com[1]订阅本周报的电子邮件版本。访问我的博客 肘子的 Swift 记事本[2]查看更多的文章。加入 Discord[3]社区，与 2000+ 中文开发者深入交流 Swift、SwiftUI 开发体验。

Homebrew 5.0：并行加速、MCP 加持，与 Intel 的最后倒计时

几天前，我像往常一样在输入 brew update后顺手执行了 brew upgrade。出乎意料的是，终端里突然出现了从未见过的画面——大量组件与工具并行下载、整齐排列、同时推进。短暂的惊讶之后，我才从新闻中得知：Homebrew 已经发布了 5.0 版本[4]。

此次更新内容相当丰富。除了默认启用并行下载外，还正式将 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 在性能、能效与系统集成上实现了跨越式提升，但在硬件外观与工业设计语言上，尚未出现能够留下强烈时代烙印的革新之作。

期待尽早看到可以计入史册的新设计，别让我们等太久。

前一期内容｜全部周报列表

欢迎 点赞 ♥️、 转发 👉

近期推荐

Grow on iOS 26：UIKit + SwiftUI 混合架构下的 Liquid Glass 适配实战[5]

Grow[6]是一款在 173 个国家和地区获得 App Store 编辑推荐、拥有超过 18 万五星评价的健康管理应用。在适配 iOS 26 的 Liquid Glass 设计语言时，团队遇到了不少挑战：如何在 UIKit + SwiftUI 混合架构下实现原生的 morph 效果？如何精确控制 Scroll Edge Effect？如何处理自定义导航栏元素的动态尺寸？Grow 的开发者之一 Shuhari[7]，分享了团队在这次适配过程中的实战经验。文章涵盖 Sheet、Navigation、Popover 等场景的改造方案，深入探讨 UIBarButtonItem尺寸计算、CABackdropLayer副作用处理等底层细节，还展示了如何利用 Core Text 创造“玻璃文字”效果。所有核心概念都配有完整的 Demo 工程[8]。

警惕参数化测试中的陷阱 (Pitfalls of Parameterized Tests)[9]

参数化测试 (Parameterized Tests)[10]是 Swift Testing 中颇具代表性的新特性，它让开发者能够在最小化重复代码的同时扩大测试覆盖范围，为同一逻辑轻松验证多组输入。然而 Alex Ozun[11]在大规模迁移实践中发现，这项功能虽然便捷，却也暗藏不少容易忽略的陷阱，甚至可能悄悄降低测试的有效性。文章结合多个示例展示了一些常见陷阱，并提出了如避免在 #expect两侧重复使用测试参数、明确区分示例测试与属性测试等多项实践建议。

为任务显式指定“身份” (Task Identity)[12]

在 SwiftUI 中，task / onAppear会在视图“出现”时执行一次，但它们并不会像视图那样自动跟踪依赖——如果任务闭包依赖了某个状态，该状态变化后任务本身不会自动重新触发。Chris Eidhof[13]以加载远程图片为例，展示了这一容易被忽略的问题，并建议为任务显式指定“身份”（identity），例如使用 .task(id: url)，让相关依赖（如 URL 或由多个值组合而成的复合标识）参与任务的重新执行条件，使 SwiftUI 能在依赖更新时取消旧任务并启动新任务。作者提醒，凡是在视图中使用 task / onAppear时，都应确保相关的依赖已经体现在任务的身份（identity）中。

Objective-C API 引发的 Unicode 错误 (One Swift mistake everyone should stop making today)[14]

Swift 已经诞生十年了，但在日常开发中开发者使用的很多 Swift API 仍只是对 Objective-C API 的简单包装，这可能会引发一些容易忽视的严重问题。Paul Hudson[15]在本文中就通过 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)[16]

Swift 的并发演进并非一帆风顺，引入 Approachable Concurrency概念后，不同编译选项组合甚至可能得到完全不同的编译结果，理解成本也随之水涨船高。Christian Tietze[17]原本只打算做一个简短演示：展示如何使用卡片盒笔记法[18]（Zettelkasten）来消化 Matt Massicotte 关于 Swift 并发的博客文章，结果在实作过程中不断撞见更深层的复杂性——例如：actor 无法直接满足带有 nonisolated要求的 Sendable 协议，除非显式将成员标记为 nonisolated或 nonisolated(unsafe)。等他回过神来，视频已经录到了 80 分钟。

视频很好地呈现了“深入学技术”的真实面貌：不是线性的知识堆叠，而是充满困惑、假设以及有待日后用代码与文档验证的开放问题。同时也侧面证明，卡片盒笔记法非常适合应对 Swift 并发这类复杂且持续演进的主题，通过构建可搜索、可链接的笔记网络，承载理解在时间维度上的逐步收敛。

Claude Code Skills 功能介绍以及使用经验[19]

Ein Verne[20]在本文中介绍了 Claude 新推出的 Skills 机制 —— 一种用于扩展 Claude 能力的模块化体系。相比 MCP、Slash Commands 和传统插件，Skills 更强调可组合性、可移植性以及对上下文窗口的友好使用方式。每个 Skill 都以独立文件夹的形式存在，包含名称、描述、操作指令（SKILL.md）、可执行脚本、参考文档与资源文件等。Claude 会在执行任务时自动扫描并匹配合适的技能，并通过“渐进式披露（Progressive Disclosure）”按需加载细节，从而显著降低上下文消耗。作者认为，Skills 本质上将“提示词工程”演进为“工作流工程”，让 Claude 从通用智能助手进一步迈向可维护的智能基础设施形态。

在 iOS 中集成 Rust：基于 UniFFI 的多平台工作流 (Multiplatform with Rust on iOS)[21]

就像许多 Swift 开发者希望把代码带出苹果生态一样，iOS 本身也对其他开发语言保持着相当开放的态度。Tjeerd in 't Veen[22]在这篇文章中分享了一份详实的 Rust + iOS 集成指南，展示如何通过 Mozilla 的 UniFFI[23]将 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 的重生[24]

Davide Ficano[25]将其经营多年的 macOS 文件对比工具 VisualDiffer[26]完全开源，并从 Objective-C 彻底重写为 Swift。这不是简单的语言迁移或 AI 辅助转换，而是一次从零开始的手工重构。

核心功能保持不变：

• 🟩 直观对比- 并排展示目录差异，用颜色标识新增、修改或缺失的文件
• 🧩 深入分析- 支持文件级别的逐行对比（基于 UNIX diff）
• 🧹 智能过滤- 自动排除版本控制文件（.git、.svn）和系统文件（.DS_Store）
• ⚡ 性能优化- 支持多种对比策略，从快速的日期/大小对比到精确的逐字节对比

在 Reddit[27]上，作者坦言自己依旧非常欣赏 Objective-C，但 Swift 的潜力让他愿意承受迁移的巨大成本。UI 层（特别是 NSTableView 与 delegate 模式）的重写过程尤为艰难，早期充满了并发属性标注，但随着理解加深，Swift 的优势逐渐显现。

FSWatcher：高性能的 Swift 原生文件系统监控库[28]

十里[29]在开发图片压缩工具 Zipic[30]时，需要实时感知图片文件变化以便进行及时处理，为此开发了 FSWatcher。这是一个基于 macOS/iOS 底层 kqueue 机制的文件系统监控库，采用事件驱动而非轮询方式，资源消耗极低。

核心特性：

• 🎯 智能过滤：支持按文件类型、大小、修改时间等多维度过滤，并可链式组合
• 🔍 预测性忽略：自动识别并跳过自身生成的输出文件（如 *_compressed.jpg），避免循环触发
• 📁 递归监控：可监控整棵目录树，支持深度限制与排除规则
• ⚡ 现代 API：完整支持 Combine、async/await 以及传统闭包回调模式

该库非常适合作为图片处理流程的监听器、开发工具的热重载组件，或构建轻量化自动备份系统等需要实时文件变动感知的场景。

SFSymbolKit：零维护的类型安全 SF Symbols 库[31]

市面上已有不少用于改进 SF Symbols 使用体验的库，但 LiYanan[32]的 SFSymbolKit 仍然颇具特色：所有符号与可用性信息都由工具直接从系统框架自动生成，一键即可完成更新，真正做到无需人工维护。

核心优势：

• ✅ 数据源可靠：直接读取 /System/Library/PrivateFrameworks/SFSymbols.framework/，与系统 100% 同步
• ✅ 完全自动化：运行 ./update_symbols.sh即可更新，无需手动添加新符号
• ✅ 版本感知：自动生成 @available属性，编译时检查符号兼容性
• ✅ 用户自助：任何人都可以在本地更新，不依赖作者发版

往期内容

#110 Skip Fuse 现在对独立开发者免费！

#109 惊险但幸运，两次！

#108 Swift 官方发布 Android SDK

THANK YOU

如果你觉得这份周报或者我的文章对你有所帮助，欢迎 点赞、赞赏，并将其 转发给更多的朋友。

参考资料

[1]

weekly.fatbobman.com: https://weekly.fatbobman.com

[2]

肘子的 Swift 记事本: https://fatbobman.com

[3]

Discord: https://t.ly/gzxeh

[4]

Homebrew 已经发布了 5.0 版本: https://brew.sh/2025/11/12/homebrew-5.0.0/?utm_source=fatbobman%20weekly%20issue%20111&utm_medium=web

[5]

Grow on iOS 26：UIKit + SwiftUI 混合架构下的 Liquid Glass 适配实战: https://fatbobman.com/zh/posts/grow-on-ios26/?utm_source=fatbobman%20weekly%20issue%20111&utm_medium=web

[6]

Grow: https://apps.apple.com/cn/app/growpal-health-fitness/id1560604814

[7]

Shuhari: https://x.com/NSShuhari

[8]

Demo 工程: https://github.com/zhangqifan/Insights?utm_source=fatbobman%20weekly%20issue%20111&utm_medium=web

[9]

警惕参数化测试中的陷阱 (Pitfalls of Parameterized Tests): https://l.fatbobman.com/w0111-01

[10]

参数化测试 (Parameterized Tests): https://fatbobman.com/zh/posts/mastering-the-swift-testing-framework/#参数化测试-parameterized-testing

[11]

Alex Ozun: https://twitter.com/AlexOzun

[12]

为任务显式指定“身份” (Task Identity): https://l.fatbobman.com/w0111-02

[13]

Chris Eidhof: https://m.objc.io/@chris

[14]

Objective-C API 引发的 Unicode 错误 (One Swift mistake everyone should stop making today): https://l.fatbobman.com/w0111-03

[15]

Paul Hudson: https://x.com/twostraws

[16]

和 Christian 一起学习 Swift 并发 (Learning About Swift Concurrency (from Matt Massicotte’s Blog) with a Zettelkasten): https://l.fatbobman.com/w0111-04

[17]

Christian Tietze: https://mastodon.social/@ctietze

[18]

卡片盒笔记法: https://en.wikipedia.org/wiki/Zettelkasten

[19]

Claude Code Skills 功能介绍以及使用经验: https://l.fatbobman.com/w0111-05

[20]

Ein Verne: https://x.com/einverne

[21]

在 iOS 中集成 Rust：基于 UniFFI 的多平台工作流 (Multiplatform with Rust on iOS): https://l.fatbobman.com/w0111-06

[22]

Tjeerd in 't Veen: https://x.com/tjeerdintveen

[23]

UniFFI: https://mozilla.github.io/uniffi-rs/latest/

[24]

VisualDiffer 2：从 Objective-C 到 Swift 的重生: https://l.fatbobman.com/w0111-07

[25]

Davide Ficano: https://x.com/dafi

[26]

VisualDiffer: https://visualdiffer.com

[27]

Reddit: https://www.reddit.com/r/swift/comments/1on3ry9/visualdiffer_rewritten_in_swift_62/

[28]

FSWatcher：高性能的 Swift 原生文件系统监控库: https://l.fatbobman.com/w0111-08

[29]

十里: https://x.com/okooo5km

[30]

Zipic: https://zipic.app?utm_source=fatbobman%20weekly%20issue%20111&utm_medium=web

[31]

SFSymbolKit：零维护的类型安全 SF Symbols 库: https://l.fatbobman.com/w0111-09

[32]

LiYanan: https://x.com/LiYanan2004