老司机 iOS 周报 #352 | 2025-09-22

[ChengzhiHuang]

老司机 iOS 周报，只为你呈现有价值的信息。

你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。

新闻

🌟 🐕 Swift 6.2 正式发布

@kemchenj：随着 Swift 语言本身走向成熟，每年的更新慢慢的已经不是集中在语言功能上，投入了更多的精力到工具链和生态建设上。

更加平易近人的 Concurrency

• 默认使用 @MainActor，减少显式的 isolation 标记
• 更加直观的 async 函数，默认在 caller 的上下文里执行，让 class 类型里可以用更简洁直观的方式去实现没有数据竞争的逻辑
• 新增 @concurrent 函数注解，把任务派发到全局任务池

前两个功能都是可以手动开启和关闭的，由于前面两个功能开启后，非 actor 环境下的 async 函数全部都会派发到 @MainActor 执行，导致主线程负载变大，所以新增 @concurrent 可以制定任务派发到全局线程。这几套组合拳下来大大加强了 Concurrency 的易用性。

安全的系统级编程功能

• InlineArray：固定大小的内联数组
• Span：可以理解为类型安全的 Buffer 类型
• 嵌入式 Swift：新增全套 String / InlineArray / Span API
• C++ 互操作：可以通过 header 标注混合使用两个语言里的 Span 的类型

工具链

• VSCode 插件更新
• 更加细化的编译警告控制
• 更快的 Macro 编译速度（通过下载预编译的 swift-syntax 包）
• 优化 async 调试功能的体验和稳定性

核心库更新

• Subprocess：一套全新的 Swift 原生进程接口
• Foundation：NotificationCenter 新增一套类型安全，拥抱 Concurrency 的接口
• Observation：提供更加易用的 async sequence 接口
• swift-testing：新增 API 提高测试代码的表达能力

更多详细信息请查看原文。

文章

🌟 🐢 KMP on iOS 深度工程化：模块化、并发编译与 98% 增量构建加速

@JonyFang: 本文主要介绍了 Bilibili KMP 在 iOS 工程化的一些深度改造，达成模块化、并发编译与 98% 增量构建加速的目标。主要通过对 Kotlin/Native 编译管线的深度拆解与重构，系统性地解决了其在模块化、编译并发和增量构建方面的核心瓶颈。

在构建系统与编译速度上 ：实现了 Parallel Compilation，将每个 Kotlin 模块独立编译为 .a 文件，在一些日常的底层修改的场景下最终产物编译耗时降低 98% 。这充分释放了 Bazel 的高并发优势，结合可靠的 remote cache 机制达到 Never clean build 的预期。

在编码与跨语言交互上：摆脱了 KMP 默认的“大一统”框架模式。通过为每个 Kotlin 模块生成独立的 Clang module ，并以 @ObjCExport 注解精确控制导出，实现了真正的模块化。

在调试与工程化上：通过修复 source-map 路径和实现可靠的 implementation_deps ，保证了跨语言调试的稳定性和构建的确定性，解决了社区方案中的常见痛点。

也推荐几篇前几期的相关阅读：

• 探讨跨平台技术与跨平台 UI 框架及 Kotlin Multiplatform 在 bilibili 的实践
• 工程化视角的 Kotlin Multiplatform 核心解读及优化
• B 站在 KMP 跨平台的业务实践之路

🐎 Automating Github Action Workflows For Swift

@Damien：作者重启搁置的 ActionBuilder 项目，通过扫描 Package.swift 实现零配置生成 GitHub Actions tests.yml，借 Swiftly 自动识别 Swift 版本并调度 Linux/macOS runner，对 iOS 等 Apple 平台则调用 Xcode 构建且已适配 Swift 6.0-6.2，未来将以轻量 CLI 取代插件，可直接嵌入 Xcode build phase 随编译自动更新工作流。

🐕 认知负荷才是关键

@zhangferry：编程领域有很多指导性的理论知识，但这些业界的实践，为什么并非总是有效呢？基于这个问题本文引出认知负荷这个概念：认知负荷是指开发者为了完成一项任务需要动多少脑子。从人的视角出发，以是否便于理解来衡量代码好坏，并给出了以下 4 个降低认知负荷的原则：

• 模块设计：不应一味的强调小方法，小模块，这会导致过多的接口和代码关联，增加认知负荷。深方法，深模块，一定程度把复杂度限定在特定范围，整体维护成本更低。

• 架构选择：不应为体现技术水平采用过于复杂的架构，易懂、易理解的架构才更合适。文中还建议在架构评审时可以让初级开发者参与，以识别过于复杂的设计。

• 抽象和代码组织：不应过于追求 DRY（不要重复自己），而大量使用设计模式，微服务等，少量的重复比不必要的依赖更好。

• 心智模型：传统推崇的心智模型（领域驱动设计 DDD）有其优势，但副作用是会引入很多主观理解，这个基础之上开发的代码往往会有更高的认知负荷。好的代码应该便于理解，而不是追求优雅和复杂。

延伸的几种观念，可能只看名称你就能知道个大概了：「可能是时候停止推荐《代码整洁之道》」、「小型函数的弊端」、「为什么我讨厌“框架”」、「设计牺牲」

🐢 阿权的开发经验小集

@阿权：阿权的日常开发小集，记录了日常开发中踩过的大小坑，内容主要涵盖 Git、iOS、Swift、Xcode 等方面问题的总结。按需搜索，说不定有意外的惊喜。

🐕 iOS26 Runtime Changes:Concurrent mutation of nonatomic properties

@ChengzhiHuang：对于 NSObject 的 property 是 nonatomic 的对象类型时，多线程的 set/get 会存在线程安全问题(非对象一样存在问题，只是不会崩溃)，一个简单的修改方案是改为 atomic，注意这个只对一般对象有效。如果是 NSMutableDictionary 等容器对象，还需要考虑对其容器内内容的修改也要注意线程安全，一般得加锁解决；更极端需要多个属性同时保持同步则也得加锁。问题不仅在 property 中存在，全局变量也一样存在问题。具体可以参考我们推荐过的 头条稳定性治理：ARC 环境中对 Objective-C 对象赋值的 Crash 隐患 。

在 iOS 26 以前，一般概率发生的崩溃崩溃的栈顶也在 objc_retain/objc_release 中；在 iOS 26 及之后，则如果发生这种线程安全问题，栈顶函数不变的情况下，会有明确的 EXC_BAD_ACCESS(KERN_INVALID_ADDRESS) 地址为 0x400000000000bad0 让这种情况更容易被辨识。

当然这也会带来一定的副作用，由于实现方式是通过 objc_storeStrong 方法中插入汇编，实现在调用 objc_retain 前，将 0x400000000000bad0 写入 x1 ，再正常调用 objc_retain 方法（正常 objc_retain 只接收一个参数，因此只需要 x0 即可）。因此原本偶现的问题，概率是会被放大的（以前即使有问题，但也有概率不崩溃），因此 iOS 26 的崩溃率对大部分应用来说会上升。稳定性同学要面临年末指标上涨的压力了，毕竟 iOS 26 的覆盖率会快速提升。

但从更长的视角来看，在 iOS 26 暴露了更多问题后，开发者修复后，后续的新版本对低 OS 的用户也带来体验的提升，所以总体我还是偏正常得看待这个 feature 的，等于苹果开启了对一类问题的线上 TSan ，并且对性能的影响微乎其微。短期的阵痛后带来的是更长期的体验提升。美中不足的就是如果这项 feature 能像 malloc 的一些开关(malloc stack logging 等)，能让开发者自主控制按一定比例开启就更好了，能有更多时间修复以及控制对升级到 iOS 26 用户的影响。

更具体的一些细节可以看链接。

🐕 How to disable Liquid Glass

@Cooper Chen：在 iOS 26 中，苹果推出了全新的 Liquid Glass 设计系统，为界面带来了更透明、流动的视觉体验。但如果你的 App 还没做好适配，用户可能会遇到界面错乱的问题。作者在文章中给出了一个简洁的解决方案：通过在 Info.plist 中新增键值 UIDesignRequiresCompatibility = YES，就能让应用暂时保持旧版设计，避免因 Liquid Glass 引发的兼容性 bug。不过要注意，这只是临时方案，苹果计划在 iOS 27 移除该选项。也就是说，开发者需要尽快着手适配 Liquid Glass，以确保用户体验的连贯性和未来的稳定性。对于想稳妥过渡到新系统的团队来说，这是一个既务实又必须关注的技巧。

设计

🐕 marioaguzman Design Guidelines layout marioaguzman Design Guidelines toolbar

@含笑饮砒霜：这两篇文章系统阐述了 macOS 应用在窗口布局和工具栏设计上的核心规范与实践原则：在窗口布局上，需要遵循中心均衡、对齐、留白和视觉平衡的原则，合理安排常规、小型和迷你控件的位置与间距，并通过空白、分隔线或分组框组织控件，确保界面简洁一致；在工具栏设计上，应基于用户的心智模型挑选并排序常用功能，合理区分全局与界面项，正确处理侧边栏和检查器的切换，注意标题、副标题、溢出优先级与居中项的使用，同时结合不同样式（统一、紧凑、扩展、偏好）以及底部栏、附加栏和系统内置特殊控件，实现美观、直观且高效的用户体验。

内推

重新开始更新「iOS 靠谱内推专题」，整理了最近明确在招人的岗位，供大家参考

具体信息请移步：https://www.yuque.com/iosalliance/article/bhutav 进行查看（如有招聘需求请联系 iTDriverr）

关注我们

我们是「老司机技术周报」，一个持续追求精品 iOS 内容的技术公众号，欢迎关注。

关注有礼，关注【老司机技术周报】，回复「2024」，领取 2024 及往年内参

同时也支持了 RSS 订阅：https://github.com/SwiftOldDriver/iOS-Weekly/releases.atom 。

说明

🚧 表示需某工具，🌟 表示编辑推荐

预计阅读时间：🐎 很快就能读完（1 - 10 mins）；🐕 中等 （10 - 20 mins）；🐢 慢（20+ mins）

What's Changed

• Close KMP on iOS 深度工程化：模块化、并发编译与 98% 增量构建加速 #5143 by @JonyFang in Close #5143 #5155
• fix Xcode Migrations: From Stone Age to AI Mastery #5136 by @BarneyZhaoooo in fix #5136 #5156

Full Changelog: #351...#352

---

This discussion was created from the release 老司机 iOS 周报 #352 | 2025-09-22.