几天前，我像往常一样在输入 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 在性能、能效与系统集成上实现了跨越式提升，但在硬件外观与工业设计语言上，尚未出现能够留下强烈时代烙印的革新之作。
期待尽早看到可以计入史册的新设计，别让我们等太久。
近期推荐
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属性，编译时检查符号兼容性 - ✅ 用户自助：任何人都可以在本地更新，不依赖作者发版