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

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

文章

🐕 精通 UITableViewDiffableDataSource ——从入门到重构的现代 iOS 列表开发指南

@阿权：本文围绕 iOS 现代列表 UITableViewDiffableDataSource 展开，核心是替代传统数据源代理模式，解决列表开发中的崩溃、状态不一致等痛点，并在最后提供一个轻量工具集 DiffableDataSourceKit 来简化系统 API 的调用。文章核心内容如下：

1. 使用 UITableViewDiffableDataSource API，通过声明式的“快照”来管理数据状态，系统自动计算并执行 UI 更新动画，从而一劳永逸地解决了传统模式中数据与 U 状态不同步导致的崩溃问题。
2. 全文通过构建一个音乐播放列表 App 来贯穿始终，从移除 Storyboard、定义遵循 Hashable 协议的数据模型开始，一步步教你初始化数据源和填充数据。
3. 文章还详细讲解了：
   • 自定义多样化的单元格：包括使用传统的 Auto Layout 布局，以及利用 iOS 14+ 的 UIContentConfiguration 进行现代化配置。
   • 实现核心交互：具体涉及了拖拽重排、滑动删除，以及如何通过 Cell 的代理事件处理等交互。
   • 处理复杂逻辑：特别讲解了如何利用模型的 Hashable 来实现“原地刷新”而非替换的刷新机制。

除了文章提到的 UITableViewDiffableDataSource，用好这些技术，不妨可以再看看以下几个 WWDC：

1. WWDC19 - 215 - Advances in Collection View Layout
2. WWDC19 - 220 - Advances in UI Data Sources
3. WWDC20 - 10026 - Lists in UICollectionView
4. WWDC20 - 10027 - Modern cell configuration

另外，与其用 UITableView 承载数据，其实 Apple 更推荐使用 UICollectionView 来实现列表，甚至还提供了增强版的 Cell。

恰逢 App Store 要求用 Xcode 26 带来的强制升级，不少 App 也终于抛弃了 iOS 12、iOS 13，也是用新技术（也不新了）升级项目架构的最好时机。

除了 API 本身，我们也应关注到一些架构或设计模式上的变化与趋势：

1. 声明式。新的 API 更多使用构造时定义逻辑的声明式语法，在一开始就把相关的布局、样式等逻辑给定义好，后续不再通过各种存储属性配置逻辑。极大地减少了开发者对状态的维护。例如 UICollectionViewCompositionalLayout 通过 Item、可嵌套的 Group、Section 一层一层地在初始化配置布局。
2. 数据驱动。声明式常常是为了数据驱动，因为声明式定义的不是最终对象，而是一些前置的配置数据结构。例如 Cell 提供了 Configuration 结构体，通过配置和重新赋值结构体来实现 UI 更新，而不是直接操作 View。类似的，UIButton 也提供了类型的 Configuration 结构体用于配置 UI。更深一层的意义，驱动 UI 的配置数据、视图甚至可以复用的和无痛迁移的。例如 UITableViewCell 和 UICollectionViewCell 的配置类及其关联子视图是通用的，自定义 Cell 可以把重心放在自定义 Configuration 配置上，这样就可以把相同的视图样式套用在各种容器中。
3. 数据绑定。将索引替换为 id 甚至是具体业务类型。以往 UITableView、UICollectionView 的 API 都是围绕索引（IndexPath）展开的，所有的数据（DataSource）、布局（CollectionViewLayout）和视图（Presentation: Cell、ReuseableView）即使有分离，但都需要通过索引来交换。虽然这样简化了不同模块的耦合和通信逻辑，但因为大多数业务场景数据是动态的，这让索引只是个临时态，一不小心就会用错，轻则展示错误，重则引入崩溃。DiffableDataSource 最具里程碑的一点是剔除了索引，直接让具体业务模型跟 Cell 直接绑定，不经过索引。
4. 类型安全。不再是 Any/AnyObject，而是直接绑定一个具体的类型。常见做法是通过泛型机制将类型传入。
5. 用轮子，而不是造轮子。系统 API 足够自由，直接使用实例，而不是子类化自定义逻辑。以往的开发经验，都是一言不合就重写实现，重新造控件、布局，UIButton 和 UICollectionViewLayout 就是两个典型的 case。近年来系统 API 都在丰富使用的自由度和易用程度，例如 UIButton 提供了许多拿来就能用的灵活样式，开发者只需要微调个 Configuration 就是能实现业务效果。UICollectionViewCompositionalLayout 则是用 Item、Group、Section 构造足够复杂的布局场景。另外一点验证了这个趋势的是，iOS 26 中，只有官方提供的控件、导航框架才有完整的液态玻璃交互。

架构的演进一般是为了提高研效、减少出错。一个合理、高效的代码架构，在当业务需求变得复杂的时候，业务调用代码不会随业务的复杂而线性增长，而是逐渐减少。

🐎 Dart 官方再解释为什么放弃了宏编程，并转向优化 build_runner ? 和 Kotlin 的区别又是什么？

@Crazy：本文主要介绍了 Dart 官方放弃宏编程改为优化 build_runner 的原因，在读本文之前，要先明白什么是宏编程。文章中介绍了 Dart 在实现宏编程的过程中试用的方案与思考，放弃的原因总结起来有三个 :

1. 编译会卡在一个“先有鸡还是先有蛋”的死结
2. 工具链双前端导致宏支持会引发“工作量爆炸 + 性能灾难”
3. 即使做成了，也“高不成低不就”：替代不了 build_runner，不如直接扩展 build_runner 能力

文章最后还对比了 Kotlin 的 Compiler Plugins、KSP 与 Swift 的 Swift Macros 的差距，总的来说 build_runner 还有很长的一段路要走。

🐕 @_exported import VS public import

@AidenRao：Swift 6 带来了全新的 import 访问级别控制：@_exported import。它和我们熟悉的 public import 有什么不同？简单来说，public import 只是将一个模块声明为公开 API 的一部分，但使用者仍需手动导入它；而 @_exported import 则是将依赖的符号完全“吸收”，调用方无需关心底层依赖。文章深入对比了两者的意图和应用场景，并给出了明确建议：日常开发中应优先选择官方支持的 public import，仅在封装 SDK 或构建聚合模块（Umbrella Module）这类希望为用户简化导入操作的场景下，才考虑使用 @_exported。

🐕 MVVM + Reducer Pattern

@含笑饮砒霜：这篇文章主要讲述如何将 MVVM 架构与 Reducer 模式结合来提升 iOS 应用中状态管理的可控性和可维护性。作者指出：传统的 MVVM 模式在复杂状态下易出现分散的状态变更和难以追踪的问题，这会导致难调试、隐式状态转换、竞态条件等不良后果；而 Reducer 模式（受 Redux/TCA 启发）通过 “单一状态源 + 明确 action + 纯函数 reduce ” 的方式，使状态变更更可预测、更易测试。文章建议在 ViewModel 内部局部引入 reducer，把所有状态通过单一 reduce(state, action) 处理，并把副作用（如异步任务）当作 effects 处理，从而达到更明确、可追踪且易单元测试的效果，同时保留 MVVM 和领域层的清晰分层，不强依赖某个框架。

🐢 用第一性原理拆解 Agentic Coding：从理论到实操

@Cooper Chen：文章从第一性原理出发，系统拆解了 Agentic Coding 背后的底层逻辑与工程现实，澄清了一个常见误区：效率瓶颈不在于上下文窗口不够大，而在于我们如何与 AI 协作。作者以 LLM 的自回归生成与 Attention 机制为起点，深入分析了 Coding Agent 在长任务中常见的“走偏”“失忆”“局部最优”等问题，并指出这些并非工具缺陷，而是模型工作方式的必然结果。

文章最有价值之处，在于将理论约束转化为可执行的工程实践：通过“短对话、单任务”的工作方式控制上下文质量；用结构化配置文件和工具设计引导 Agent 行为；通过 Prompt Caching、Agent Loop、上下文压缩等机制提升系统稳定性。更进一步，作者提出“复利工程（Compounding Engineering）”这一关键理念——不把 AI 当一次性工具，而是通过文档、规范、测试和审查，将每一次经验沉淀为系统的长期记忆。

最终，文章给出的启示非常清晰：AI 编程不是魔法，而是一门需要刻意练习的协作技能。当你真正理解模型的边界，并用工程化方法加以约束和放大，AI 才能从“能写代码”进化为“可靠的编程合作者”。

🐎 Universal Links At Scale: The Challenges Nobody Talks About

@Damien：文章揭示了 Universal Links 在大规模应用中的隐藏复杂性：AASA 文件缺乏 JSON 模式验证导致静默失效，Apple CDN 缓存延迟使问题修复滞后，苹果特有通配符语法和 substitutionVariables 变量无现成工具支持。作者提出通过 CI 集成模式验证、CDN 同步检查、自定义正则解析和 staging 环境测试的完整方案，并开源了 Swift CLI 工具实现全链路自动化验证。

🐕 How I use Codex GPT 5.2 with Xcode (My Complete Workflow)

@JonyFang: 本视频深入介绍了如何让 AI 代理（如 Codex GPT 5.2）真正提升 iOS/macOS 开发效率的三个核心策略：

1. 构建脚本自动化（Build Scripts）：通过标准化的构建流程，让 AI 能够理解和复现你的构建环境
2. 让构建失败显而易见（Make Build Failures Obvious）：优化错误信息的呈现方式，使 AI 能够快速定位问题根源
3. 给你的代理装上"眼睛"（Give Your Agent Eyes）：这是最核心的部分 - 让 AI 能够"看到"应用运行时的状态，而不仅仅是读取代码

最有价值之处：作者强调了一个常被忽视的问题 - AI 代码助手不仅需要理解代码逻辑，更需要理解应用的运行时状态。通过工具如 Peekaboo 等，让 AI 能够获取视觉反馈（截图、UI 层级等），从而提供更精准的问题诊断和代码建议。这种"可观测性优先"的思路，与传统的代码审查工作流形成了有趣的对比，值得所有尝试将 AI 工具深度集成到开发流程中的团队参考。

视频时长约 49 分钟，适合希望系统性提升 AI 辅助开发效率的 iOS/macOS 开发者观看。

工具

🐎 Skip Is Now Free and Open Source

@Crazy：Skip 框架正式免费并且开源，该库从 2023 年开始开发，已有三年的开发历程。该库的目的是让开发者能够仅用一套 Swift 与 SwiftUI 代码库，同时打造 iOS 与 Android 上的高品质移动应用——而且不必接受那些自“跨平台工具诞生以来就一直存在”的妥协。因为 Skip 是采用编译为 Kotlin 与 Compose 的方式，所以相应的执行效率是非常高的。相较于其他的跨平台开发，效率高，并且使用的是 Swift 语言。既然已经免费并开源，移动端开发的时候又多了一个可供选择的跨端技术。

内推

重新开始更新「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）