上周我去影院看了苹果出品的电影《F1》，体验真的超乎预期。虽然剧情略显简单，但影片营造出的赛车沉浸感和观赛体验已经远超票价。当布拉德·皮特驾驶着 APXGP 赛车在银石赛道上疾驰时，那引擎的咆哮通过 IMAX 音响系统传来的震撼感，让我仿佛回到了 20 多年前，在电视机前为舒马赫和阿隆索激烈对决而热血沸腾的日子。
三亿美元的制作成本听起来不少，但看完后你很难不惊叹：这真的是三亿能拍出来的吗？真车、真人（众多顶级车手客串）、真场地（银石赛道、迈凯伦车队总部、梅赛德斯风洞实验室）——这些资源若没有汉密尔顿担任制片人时的人脉、苹果的企业背书，以及 F1 官方的全力配合，恐怕花再多钱都未必能实现。
有趣的是，苹果目前也在竞争 2026 年 F1 在美国的转播权。这是受电影成功鼓舞的顺势而为，还是从拍摄之初就已纳入战略布局？无论如何，这部电影或许不会在电影史上留下浓重的印记，但作为一部顶级商业运动的“宣传片”，其效果无疑是拉满的。或许我们很快就会看到更多与高商业价值运动组织深度合作的体育题材电影。
二十多年前我热衷 F1 的时候，FIA 对各车队的限制相对宽松，轮胎供应商之间有米其林和普利司通的激烈竞争，车队可以在空气动力学、引擎开发、燃油策略等多个方面大胆创新。即便是小车队，也有机会通过独特的战术选择在某场比赛中跑进积分区，给车迷带来意想不到的惊喜。
但随着 FIA 逐步收紧规则，比赛变得越来越程式化。统一轮胎供应商、混合动力时代复杂的引擎规则，每一次改革似乎都在削弱那种“anything goes”的爽快感和刺激感。
FIA 的初衷是好的——通过增加限制来缩小车队间差距，让比赛更加激烈、不可预测。理论上，当大家都被施加相同限制时，实力差距应该会缩小。但现实却并非如此。大车队依旧凭借几十年的技术积累、顶级设施和成熟管理体系维持统治，而小车队则丧失了“剑走偏锋”的机会。爆冷和奇迹变得越来越稀少，比赛也失去了许多曾经令人热血沸腾的变化和不确定性。
这并非 F1 独有的现象。放眼整个体育产业，几乎所有高商业价值的运动组织都在采取类似的“平衡策略”：NBA 的工资帽和奢侈税、NFL 的选秀制度、英超的财政公平法案……这些规则的初衷都是限制强队、增加竞争性，从而提升联赛整体商业价值。但实际效果往往有限。长期积累的资源优势不会因为规则限制而消失，只是换了种表现形式。而在追求“平衡”的过程中，这些运动可能也在悄悄失去一些独特的魅力。
我并不反对商业与竞技结合——体育需要商业支撑才能可持续发展。但当商业考量开始主导竞技规则的制定时，就需要警惕了。变化和不可预测性，始终是竞技运动的核心吸引力。如果为了追求表面的“平衡”而扼杀了创新和变化，我们最终可能会看到这样一个局面：赛事越来越赚钱，但运动本身的魅力却在逐渐消退。
近期推荐
如何在 mac Finder Action 扩展中使用新并发 (Writing a macOS Finder “action” Extension with Swift 6 Concurrency)
对于开发者来说，一段标注了详细注释的代码，或许胜过千言万语。在这篇文章中（90% 是代码），Chris Jones 向我们展示了如何在系统回调场景中（同步调用，线程不确定），巧妙地与 Swift 现代并发模型协作。
为了方便快速抓住重点，我整理了以下几个关键技术点：
- 通过
DispatchGroup协调多个异步操作，确保所有准备工作完成后再返回结果 - 使用
Mutex保护共享状态，避免多线程环境下的数据竞争 - 通过
Task.detached创建独立执行上下文，解决异步/同步桥接问题(避免死锁)
在开发者的精心设计下，传统 Cocoa API 与现代 Swift 并发或许可以“愉快”地共存。
Icon Composer 见招拆招
随着 Liquid Glass 风格的推出，苹果同步发布了 Icon Composer，帮助开发者制作符合新标准的应用图标。虽然官方介绍中“拖放分层图片即可”的流程看似简单，但实际使用过程中仍有不少细节需要留意。本文中，Megabits 分享了他在使用 Icon Composer 制作 Liquid Glass 图标时的实战经验，包括如何处理 SVG 导出、单色模式适配、层数限制 以及 Xcode 的导入路径等问题，让你在设计新图标时少走弯路。
SwiftUI 2025：修了哪些坑，哪些还在 (SwiftUI 2025: What’s Fixed, What’s Not, and How I Build Apps Now)
相较于初期版本，SwiftUI 已经取得了显著进步，但它真的足以支撑复杂 App 的开发吗？哪些坑已经被填平，哪些问题依然存在？Weichao Deng 分享了他在一个 SwiftUI-first 项目 中遇到的主要挑战，以及如何通过混合 UIKit 提升性能和解决兼容性问题。他认为，尽管 SwiftUI 获得了大量改进，但出于兼容性和性能考量，仍建议用 UIKit/AppKit 管理生命周期（如 UIScene、UIWindow），将 SwiftUI 作为主要视图库；而对于个人小工具或 demo，纯 SwiftUI 已经足够。
用 TestHelpers 打造高效测试目标 (Hitting The Target with TestHelpers)
随着项目规模增长，模块化已成为管理复杂度的有效手段。但在许多项目中，模块化的收益往往集中在生产代码，而测试目标（test target）却被忽视。William Boles 提出了一种简单而实用的做法：为每个模块引入 TestHelper target，消除重复的测试桩代码，提升团队开发效率。
在我自己构建的项目中，也采用了与 William 建议非常接近的方案。实践下来，我最大的感受是：初期投入时间去打造高质量的 Mock 和测试工具确实不轻松，但这些投入会在后续开发中带来“复利效应”——让测试编写更快、维护成本更低、代码质量更高。
Mutex 与同步框架 (Modern Swift Lock: Mutex & the Synchronization Framework)
Swift 6.2 新增的 Synchronization 框架 引入了 Mutex 锁（SE-433），提供了一种更简洁、线程安全的方式来管理可变状态。Antoine van der Lee 在文章中不仅介绍了其用法，还对比了传统 Lock 的差异。Mutex（互斥锁）只能由获取它的线程/任务释放，更严格，适合避免解锁错误；同时，withLock 方法让我们能够以同步且线程安全的方式访问数据。
Mutex 给我的最大感受是优雅：它让我可以放心、自然地实现 Sendable 类型，而不必向编译器提供人格担保（
@unchecked Sendable）。唯一的遗憾是，该功能仅支持 iOS 18 及以上系统。
在 SwiftUI 中检测交互式返回手势 (Detecting the Interactive Pop Gesture in SwiftUI)
虽然 NavigationStack 底层基于 UINavigationController，但 SwiftUI 仅暴露了有限的接口，导致我们在某些场景下难以精准判断用户意图。比如，感知返回手势，以便在用户滑动返回时暂停任务、取消网络请求或触发动画。Artem Mirzabekian 在本文分享了一种实用技巧：通过嵌入一个隐形 UIViewController，监听父级 UINavigationController（即 NavigationStack）的 interactivePopGestureRecognizer 状态。
iPadOS 窗口化：开发者的下一个挑战 (Windowing on iPadOS)
在 WWDC 2025，iPadOS 迎来了重大升级，带来了与 macOS 接近的窗口系统体验。这不仅丰富了用户体验，也为开发者带来了新的挑战：应用需要适配更多窗口尺寸状态，包括“微型窗口”（甚至小于 iPhone SE 的尺寸）。Danny Bolella 在本文分享了多种适配技巧与注意事项，并提出一个有趣的假设——或许可以借助 iPad 的窗口系统，提前模拟折叠屏 iPhone 的体验。
窗口化是 iPadOS 的下一步进化，拥抱它，也是在实践 Liquid Glass 设计理念。
SwiftData 性能提升实战 (High Performance SwiftData Apps)
你能接受在 SwiftData 中保存一张照片要等 20 秒吗？显然 Jacob Bartlett 不行——他觉得用户更不会买账。本文记录了他从“灾难性设计”到彻底重构优化的全过程：包括如何将数据读写移出主线程、重构数据模型以避免存储庞大的 PNG 数据、将图片迁移到文件系统并引用路径，以及借助第三方库（如 Nuke）实现高效加载。
随着采用 SwiftData 的开发者增多，性能问题开始困扰更多人。至少在目前阶段，SwiftData 的易用性优势正在被这些性能隐患逐渐削弱。
工具
XLKit - 不仅仅导出数据
一个迫切的需求，往往能催生出有特色的第三方库。The Acharya 团队在电影制作工作流程中，需要处理 Final Cut Pro 的 FCPXML 并导出 Excel 文件，尤为关键的是导出数据中的图片既要保持“完美长宽比”，又要支持单元格自动适配其尺寸。为此，Vigneswaran Rajkumar 开发了 XLKit——一个支持完整 .xlsx 文件输出的 Swift 库，内置 17 种专业视频/影院长宽比，并特别为 Final Cut Pro 工作流优化。
Apple Docs MCP
苹果开发者文档向来被诟病更新慢、检索难，在 AI 编程时代这一问题愈发凸显。为解决这一痛点，Sungwhee Kim 开发了 Apple Docs MCP：一个基于 Model Context Protocol 的苹果文档服务器，让 Claude、Cursor 等 AI 助手能够直接访问苹果官方文档、API 参考和 WWDC 视频资料。配置该 MCP 后，你可以直接向 AI 提问：“Show me withAnimation API with related APIs” 或 “Find UIViewController delegate methods”，让大模型真正成为苹果开发者的智能助手。