老司机 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 APIC++ 互操作：可以通过 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 ChangedClose #5143 by @JonyFang in #5155fix #5136 by @BarneyZhaoooo in #5156Full Changelog: #351...#352