两周前，借着参加 iOS Conf SG 2026 的契机，我造访了新加坡国立美术馆，并有幸参观了《走进现代：波士顿美术博物馆印象派大师展》。尽管此前也看过不少优秀的展览，但这次经历仍带来了某种不同寻常的触动。
新加坡国立美术馆由两座极具历史分量的国家古迹——前最高法院与前市政厅——合并而成。设计师以极简的金属与玻璃屋顶将两座古典建筑连接在一起，在建筑层面便营造出一种强烈的临场感：历史与现代在同一物理空间中彼此交织。而正在展出的特展《Into the Modern》，汇集了莫奈、雷诺阿、马奈、塞尚、德加等 25 位大师的一百余幅原作，则将这种跨越时间的对话进一步推向了艺术层面。
展览并未简单依循时间线展开，而是以“现代性”为核心叙事线索，通过“城市与变革”“光影与瞬间”“阶级与休闲”等主题层层铺陈。尽管这里的“现代”指向的是 19 世纪末，但画作中所呈现的巴黎城市改造、光影技法的演变，以及新兴休闲与娱乐方式的兴起，无不从多个维度展现了那个时代社会前行的节奏。在这样一个时空交错的场域中，展览早已超越了单纯“观看艺术品”的层次。对于每天都被社交媒体时间线中海量“新技术”信息裹挟的我而言，这无疑是一段难得的平静与反思时刻。
回到现实，仅仅在过去的几天里，大热 AI 项目的名字就从 Clawdbot 变成 Moltbot，又迅速演化为 OpenClaw。从微观视角看，我们仿佛正身处一个以分秒计量的变革时代；但若在若干年后，从更长的时间尺度重新审视当下的 AI 热潮，或许会发现，世界并未如洪流之中的我们所感知的那样，发生着本质上的突变。
身处其中，我们难免会因层出不穷的新技术、新工具而兴奋，甚至焦虑。或许，在这种情绪之外，更需要一种更深层的定力。历史反复提醒我们，任何“高技术”都具有其时间局限性。正如莫奈在不同时间、不同光线下反复描绘同一座干草堆：绘画技法在变化，但核心对象始终未变；真正发生变化的，往往是观看方式、理解层次与创作者自身的心境。
在面对“现在与未来”时，也许我们可以少一些追逐变革的慌张，多一些凝视瞬间的从容。
本期赞助
调试 iOS 网络请求总是被证书配置难住？
Proxyman 是一款为 iOS 开发者打造的现代 HTTP 抓包工具。支持 SSL 代理、GraphQL、WebSocket 及强大的脚本注入功能。告别笨重的传统工具，体验专为 macOS 优化的极致调试效率。
近期推荐
SwiftUI 调试背后的多重类型擦除机制 (DebugReplaceableView and Swift 6.2’s Multiple Type Erasers)
或许你可能对 Xcode 的 Preview 仍不甚满意，但其实在过去几年间，苹果一直在这方面积极地进行着优化工作，并且取得了不少的进展。比如，从 Xcode 16 开始，便在预览和调试模式下，通过 @_typeEraser 自动将视图转换为 AnyView 以增加更多的调试信息。而从 Xcode 26 开始，通过增强 @_typeEraser 使其支持多重类型擦除器，在 macOS/iOS 26+ 平台上将视图转换成 DebugReplaceableView，实现视图的热替换而无需重建整个视图层级，进一步改善预览性能。在本文中，Kyle Ye 从编译器源码层面深入剖析了这一机制的实现原理，解释了编译器如何根据平台可用性自动选择合适的类型擦除器。
Swift 中的分层缓存设计 (Tiered Caching in Swift)
在需要同时兼顾性能、内存占用与数据一致性的场景中，单一缓存策略往往很快就会捉襟见肘。这篇文章中，Kyle Browning 以实践视角系统介绍了分层缓存（Tiered Caching）在 Swift 中的实现思路：通过将内存缓存与磁盘缓存组织成清晰的层级结构，配合灵活的缓存策略（如 cacheThenFetch、cacheElseFetch 等），让数据在不同访问成本之间有序流动。
基于 Cloudflare 的 SwiftUI 实时协作编辑实践 (SwiftUI: Realtime, Multi-User Content Collaboration With CloudFlare +YJS-Swift)
尽管市面上已经存在不少现成的服务与框架，实时协作编辑在工程层面依然是一道不低的门槛。本文中，Itsuki 系统性地展示了如何在 SwiftUI 中，借助 Cloudflare Durable Objects + WebSocket Hibernation API + YJS-Swift，构建一个低成本、可扩展、支持多用户实时协作的内容编辑系统。
尤其值得一提的是，作者详细分享了在 SwiftUI 接收远程内容更新时，如何正确维护文本光标与选区位置的处理技巧——这一部分非常贴近真实产品开发，明显属于“踩过坑之后才会写出来”的经验。
Swift Actor 的 6 个常见陷阱 (Swift Actors: 6 pitfalls that will catch even experienced developers)
Actor 是 Swift 并发模型中最重要、也最容易被“想当然”使用的语言特性之一，然而现实远比这复杂。Rafał Dubiel 在本文中总结了 6 个即使是资深开发者也常踩的 Actor 陷阱：可重入性导致的状态不一致、Actor Hopping 的性能代价、@MainActor 与 Objective-C 回调交互时的线程安全漏洞、@unchecked Sendable 的滥用风险、nonisolated 的误解，以及 Actor 并不保证执行顺序这一反直觉的事实。
Rafał 并未停留在概念层面的提醒，而是结合具体场景解释这些问题为何真实存在、又为何容易被忽视。
SwiftUI 全局主题系统的可扩展设计 (Designing a Scalable App-Wide Theming System in SwiftUI)
在 SwiftUI 中实现全局主题（Theming），看似是个“样式管理”问题，实则很容易牵扯到状态传播、依赖注入以及视图刷新边界等更深层的设计选择。Sagar Unagar 从一个现实需求出发，系统展示了一套基于 SwiftUI Environment 的全局主题系统设计：通过 EnvironmentKey 让主题像内置环境值一样访问，以语义化的 Design Tokens 取代散落各处的硬编码值。
Sagar 关注的并不仅是“如何做”，而是“哪种方式在长期更可控”——这套方案不依赖特定库，核心思想是“语义化 + 响应式”，可以轻松扩展到字体、间距、圆角等设计要素。
在 Swift 中实现“只执行一次”的优雅方式 (Call Once)
“确保闭包只执行一次”听起来像是一个再基础不过的需求，但在真实系统里，这往往并不只是加一个布尔值那么简单。Paul Samuels 在本文中展示了如何用 @propertyWrapper 封装这一行为，并逐步演进：从只支持 () -> Void 的基础版本，到引入泛型支持返回值，最终借助 Swift 的 Parameter Packs（each Argument）实现对任意函数签名的支持。
这是一篇偏思考型的文章，其价值不仅在于最终的 CallOnce 实现，更在于展示了如何将多个 Swift 语言特性逐步组合起来，解决一个看似简单却颇具代表性的工程问题。
工具
SwiftUI-Agent-Skill：让 AI 写出更“靠谱”的 SwiftUI 代码
如果你正在使用 AI 编程助手（如 Claude Code、Cursor、Codex），很可能遇到过类似的问题：AI 生成的 SwiftUI 代码使用了过时的 API，或在状态管理、视图组织上偏离最佳实践——即便你已经在基础规则中反复强调过这些要求。
Antoine van der Lee 发布的 SwiftUI-Agent-Skill，正是为了解决这一“最后一公里”的落差。它为 AI 工具提供了一套专家级的 SwiftUI 指导规范，涵盖状态管理取舍、现代 API 替换、性能与可维护性检查，以及 iOS 26+ 的 Liquid Glass 使用边界等内容，把“SwiftUI 最容易写歪的地方”整理成可复用、可执行的审查流程。
除了这套 skill 外，Antoine 还提供了面向 Swift Concurrency 和 Core Data 的 skill。
我建议开发者不要只是把它们简单配置进 AI 环境中就结束了——这些 skill 文档本身就是对某一领域实践经验的结构化总结。认真读一遍，受益的不只是 AI，你自己也会随之进阶。
PierreDiffsSwift：在 macOS 应用中渲染精美的代码 Diff 视图
James Rochabrun 开发的 PierreDiffsSwift，帮助开发者在 macOS 应用中渲染漂亮的、带语法高亮的代码 Diff 视图。
该库提供了一个开箱即用的解决方案：基于 @pierre/diffs JavaScript 库，通过 WKWebView 封装成 SwiftUI 原生视图，支持 40+ 种语言的语法高亮、Split/Unified 两种视图模式、行内单词级变更高亮，以及深色/浅色主题自动切换。