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

![ios-weekly](https://github.com/SwiftOldDriver/iOS-Weekly/blob/master/assets/weekly-header/352.jpg?raw=true)
老司机 iOS 周报，只为你呈现有价值的信息。

你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 [Issues](https://github.com/SwiftOldDriver/iOS-Weekly/issues) 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 [Issues](https://github.com/SwiftOldDriver/iOS-Weekly/issues) 提出。

## 新闻

### 🌟 🐕 [Swift 6.2 正式发布](https://www.swift.org/blog/swift-6.2-released/)

[@kemchenj](https://kemchenj.github.io/)：随着 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% 增量构建加速](https://mp.weixin.qq.com/s/wOnyjYcka99eFJz8BWlu4Q)

[@JonyFang](https://github.com/): 本文主要介绍了 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 的实践](https://mp.weixin.qq.com/s?__biz=Mzg3Njc0NTgwMg%3D%3D&mid=2247499203&idx=1&sn=67aea00aa5c15999f97791311938bc53&scene=21&poc_token=HLpTz2ijWQWLwFf6XFfk8Q_WpxxZDQY6efKAoW3r)
- [工程化视角的 Kotlin Multiplatform 核心解读及优化](https://mp.weixin.qq.com/s?__biz=Mzg3Njc0NTgwMg%3D%3D&mid=2247499744&idx=1&sn=f3c7bff956a066c30b70b5be1236a308&scene=21&poc_token=HNFTz2ij1E8hZViL6RNPunbfKHVS25LeC66WMyXt)
- [B 站在 KMP 跨平台的业务实践之路](https://mp.weixin.qq.com/s?__biz=Mzg3Njc0NTgwMg%3D%3D&mid=2247502999&idx=1&sn=9213bf3505748c329053a5b583450a18&scene=21&poc_token=HOdTz2ijemHOj_WW4N95gPA12ZTRq-q99qX9m5aI)


### 🐎 [Automating Github Action Workflows For Swift](https://elegantchaos.com/2025/08/28/action-builder.html)

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

### 🐕 [认知负荷才是关键](https://github.com/zakirullin/cognitive-load/blob/main/README.zh-cn.md)

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

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

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

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

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

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

### 🐢 [阿权的开发经验小集](https://juejin.cn/post/7550466215790886927)

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


### 🐕 [iOS26 Runtime Changes:Concurrent mutation of nonatomic properties](https://github.com/SwiftOldDriver/iOS-Weekly/issues/5148)

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

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

当然这也会带来一定的副作用，由于实现方式是通过 objc_storeStrong 方法中插入汇编，实现在调用 objc_retain 前，将 0x400000000000bad0 写入 x0 指向的地址 ，再正常调用 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](https://www.swiftwithvincent.com/blog/how-to-disable-liquid-glass)

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

## 设计

### 🐕 [marioaguzman Design Guidelines layout](https://marioaguzman.github.io/design/layoutguidelines/) [marioaguzman Design Guidelines toolbar ](https://marioaguzman.github.io/design/toolbarguidelines/)

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


## 内推

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

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

## 关注我们

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

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

![](https://github.com/SwiftOldDriver/iOS-Weekly/blob/master/assets/qrcode_for_wechat.jpg?raw=true)

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

## 说明

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

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