Releases: SwiftOldDriver/iOS-Weekly
Release list
老司机 iOS 周报 #379 | 2026-09-14
老司机 iOS 周报，只为你呈现有价值的信息。
你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。
新闻
Xcode27 adpot AVCaptureDevice.RotationCoordinator
从 iPhone 17 Pro 开始 前置摄像头 sensor 有一定的改变，之前苹果有使用一些兜底方案来保证画面的角度是正确的，一旦 app 用 iOS 27 或者更新的 SDK 来 build ，这个兜底方案就不会生效了。
需要适配可以参考 AVCaptureDevice.RotationCoordinator documentation ，以及 Sample code building a camera app 。
The app should adopt AVCaptureDevice.RotationCoordinator rather than deriving preview rotation itself. Apply its videoRotationAngleForHorizonLevelPreview to thevideoRotationAngle on the AVCaptureConnection feeding the preview layer, and its videoRotationAngleForHorizonLevelCapture to the connection feeding the capture output.
文章
🐎 Why Swift is introducing a warning for weak captures within nested closures
@Smallfly：文章介绍 Swift 6.4 针对嵌套闭包中 weak self 捕获新增的编译器警告：内层弱引用可能导致外层闭包隐式强持有 self，进而形成循环引用。作者通过 Timer 与异步回调示例解释问题成因，并给出将 weak self 移到外层、内外层分别弱捕获，或显式强捕获以消除误报等处理方式。
代码
simslim
@Cooper Chen：给 iOS 模拟器“瘦身”，让一台 Mac 跑更多实例
- 是什么：macOS 命令行工具（含 SwiftUI 应用），关闭 iOS 模拟器中不必要的后台服务，降低内存占用。
- 效果：默认约 180 个后台服务；实测 M1 Pro / 16GB 上，内存从 4.0GB 降到 0.9GB，进程从 258 降到 70。
- 原理：通过 xcrun simctl 向模拟器自身的 launchd 写入持久禁用条目，重启后仍生效；只影响指定模拟器，不碰宿主机。
- 功能：可按类别关闭或保留服务，支持 profile、JSON 和 CI；也能克隆、重命名、清理磁盘，并用 doctor、verify 检查状态。
- 适合谁：iOS 开发、测试、CI，尤其是需要并行运行大量模拟器的 AI Agent 工作流。MIT 开源，可用 Homebrew 或 Go 安装。
音视频
🐢 Design for iPhone Duo 等 6 个官方适配视频
@Barney：Apple 用 6 场 Tech Talks 系统讲解首款折叠 iPhone 的设计与开发适配，覆盖 Size Class、非对称 Safe Area、纵向工具栏、折痕避让、ArrangementView、铰链交互、多窗口、双屏 scene accessory 与内外相机切换。系列分为设计原则、应用准备、栏位适配、自适应布局、多屏与场景和相机体验，适合 SwiftUI、UIKit 或 AVFoundation 开发者作为完整适配清单。
内推
重新开始更新「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）
老司机 iOS 周报 #378 | 2026-08-31
老司机 iOS 周报，只为你呈现有价值的信息。
你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。
新闻
ITMS-90068: MinimumOSVersion too low
MinimumOSVersion too low - This app has a MinimumOSVersion of 13.0. Starting 2027, all iOS apps must have a MinimumOSVersion of 15.0 or later in order to be uploaded to App Connect or submitted for distribution.
最近提审的时候收到苹果的邮件提醒，本次苹果将强制要求最低支持 OS 升级到 iOS 15。还坚持在 iOS 12/13 的 App 维护者可以借机一把梭到 iOS 15 享受到 Page-in linking 和 chained fixups 了。预期能收获 AA 可观察的冷启动性能优化，尤其在中低端机上。
文章
🌟 🐕 Flutter iOS 的深度优化 PR，搞笑的是贡献者被 Gemini 评审折磨
@JonyFang：这篇文章以 Flutter iOS 的 PR #191368为例，复盘了一次由历史兼容逻辑引发的性能优化。SmoothPointerDataDispatcher 原本是为 iPhone X/XS 时代不稳定的触摸事件投递设计的，但在现代 iOS 上触摸投递已经明显稳定，该机制却仍让约 99% 的事件等待下一次 VSync，额外增加一帧触摸到画面的延迟。单纯删除平滑器后，又暴露出 VSync waiter 和 CADisplayLink 唤醒流程的问题，部分设备甚至会从 60/120 fps 降到 30/60 fps。
因此，PR 并不是简单删代码，而是同时调整事件分发、RunNowOrPostTask、AwaitVSync 以及 CADisplayLink 生命周期，把触摸处理到 VSync 请求压回同一个 run-loop turn，减少无意义的调度等待。
文章后半部分还记录了 Gemini Code Assist 因误解 Flutter 的 merged UI/platform thread，而反复提出 data race、deadlock 和加锁建议的过程，说明 AI Review 不能替代工程师对线程模型和运行时证据的判断。这与本期 PerfAgent 强调的“测量—修改—验证”闭环，以及 Using AI while exercising your critical thinking 对批判性校验的提醒形成呼应；也与历史上“旧调度优化随系统演进反而变成负担”的案例相似（见 #373）。对关注 Flutter Engine、iOS VSync、性能调度和 AI 代码审查的开发者有参考价值。
PerfAgent: Profiler-Guided Iterative Refinement for Repository-Level Code Optimization
@ChengzhiHuang: 这篇论文研究的不是让 Agent 把代码修改正确，而是让它在真实仓库中做出更接近性能专家的性能优化。作者发现普通 Coding Agent 有三个通病：不做深入的性能分析，容易错过藏在 C/C++ 等原生扩展里的真正瓶颈；找到一个稍有提速的方案后便过早停止；为了追求性能做出复杂修改，却没有充分验证正确性。
PerfAgent 没有训练新模型，而是在现有 Agent 外增加一套闭环：先用 py-spy 找出热点并整理成简洁报告；Agent 提交补丁后，重新构建并只运行受改动影响的测试；测试通过后再次测量、分析新的瓶颈，继续下一轮；最后保留所有轮次中最快且正确的补丁。
核心结论是：对于性能优化 Agent，关键不只是多尝试几次，而是每一轮都提供准确的瓶颈、性能和正确性反馈。
类似的方法论同样可以使用在任意的性能优化中。以我当前的经验观察，即使只是从 Instruments 中通过 xctrace 导出 TimeProfile 火焰图，并使用 Perfetto 或者别的消费工具进行自动化消费已经是明确可以跑通的路径。
🐎 Using AI while exercising your critical thinking
@阿权：工程师的核心价值不是会调 AI 提示词，而是对 AI 输出进行批判性思考与校验。新技术无法解决 LLM 的固有缺陷，唯有主动运用批判性思维，才能在工作中保持主导权。这是整篇文章的核心观点，作者并给出三条实操指南：
- 把 AI 当作辅助工具，不是全权执行者；复杂任务不能放任 AI 自由跑，需要持续监督干预，幻觉、遗忘指令是 LLM 固有缺陷，新版本不能彻底消除。
- 质疑 AI 每一个观点，要求提供证据，并且亲自核验证据，不能直接相信 AI 给出的引用，系统提示词不足以约束大模型。
- AI 生成的代码哪怕能运行，也要逐行审阅：校验逻辑、边界条件，同时保证自己读懂代码，避免编程能力退化。
🐕 Apple Foundation Models: Hybrid AI with Dynamic Profiles
@Cooper Chen：这篇文章深入探讨了苹果在 WWDC 26 上对 Foundation Models 框架的重要升级——通过引入 Dynamic Profiles（动态配置文件）特性，让开发者能够以极其优雅的方式实现混合 AI 架构。
文章指出，苹果的端侧模型虽然具备免费、私密、无需联网等优势，但受限于移动设备的内存、算力和散热条件，其上下文窗口（仅 8K tokens）和推理速度都无法满足复杂任务的需求。作者通过对比测试发现，即使是 Gemini 3.5 Flash Lite 这样的轻量级云端模型，在处理各类文本时的速度也普遍优于苹果端侧模型。
文章的核心亮点在于，苹果通过 LanguageModel 协议将 Foundation Models 框架向第三方开放，Anthropic 和 Google 均在 WWDC 26 首日就提供了 Claude 和 Gemini 的实现。而 Dynamic Profiles 则更进一步——开发者可以在一个 Profile 中封装路由逻辑、token 预算检查和模型专属提示词，让系统根据输入长度自动在端侧模型和 Gemini 之间切换。调用端代码因此变得极其简洁，真正实现了“分离关注点”和“声明式组合”。
这篇文章为 Swift 开发者提供了一条清晰的道路：如何在保持端侧 AI 优势的同时，无缝接入云端最强模型的能力，真正实现“鱼与熊掌兼得”。
🐕 The AI-Native SDLC playbook
@zhangferry：Anthropic 的 Applied AI 团队 8 月 21 日发布了一份 AI-native SDLC（软件开发生命周期） playbook，主要应对的问题是 agent 让写代码从数周缩减到数小时，但 plan、review、deploy 还按人的节奏走，整体效率提升仍然有限，解法是把六个阶段全部重造。
- Plan 阶段想法直接跟 Claude 聊成 intent.md，产品负责人审而不写。
- Design 阶段，需求和 spec 压进一个 session，政策在 spec 写下时就被 skills 应用。
- Build 先在 plan mode 里迭代出 plan.md，代码排在计划后面。
- Test 让 session 自己跑测试自查。bug 要先写成失败的测试再修，hook 禁止 agent 动测试文件。
- Deploy 的 review 两头都要有 Claude。人守在 production gate 上。
- Maintain 用确定性监控加分层响应，事故写成新的 intent.md 重新进流程。循环在这里闭合。
这套路程运行的背后还有一套设计支撑：每个阶段以提交一个产物结束，下一个阶段读取它开始，这条链同时是审计链，中间产物都进 git 历史；控制分三层，skill 整理违规问题，hook 让违规接近不可能，最终判断留给人；CLAUDE.md、skills、hooks 也按代码对待，进 CI 跑回归，线上事故沉淀成用例供后续持续使用。
🐢 Detecting (Evil) Dylibs
@Smallfly：这篇文章从 macOS 安全视角系统梳理了 dylib 被攻击者利用的方式，包括持久化、供应链投毒和 SIP 绕过等案例，并进一步介绍如何在静态文件、运行中进程以及加载时枚举动态库。文章重点展示了借助 proc_pidinfo 与 Endpoint Security 的 AUTH_MMAP 事件，安全工具可以在 dylib 完全加载前完成检测甚至阻断。适合关注 macOS 安全、客户端运行时机制和防护工具实现的同学阅读。
工具
🐎 Veilpath： 更完善的 iOS 的沙盒浏览器
@Damien：这篇文章介绍了作者基于 bad_query 开发的 iOS/iPadOS 沙盒浏览器 Veilpath，它能发现并解析各类 App 容器，把 UUID 转换成可识别的 Bundle ID，并支持浏览、搜索、预览和导出文件。 应用还提供 plist、JSON、SQLite、Mach-O、ZIP/IPA 等格式的检查能力，并通过备份、哈希校验、临时草稿和回滚机制降低修改或删除文件的风险。 Veilpath 主要面向安全研究人员，需要自行编译，目前谨慎宣称支持 iOS/iPadOS 26 至 27 beta 4。 作者强调，它的目标不是单纯绕过沙盒，而是把底层安全研究变成一个可读、可控、可恢复的专业工具。
内推
重新开始更新「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）
老司机 iOS 周报 #377 | 2026-08-17
老司机 iOS 周报，只为你呈现有价值的信息。
你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。
新闻
🐎 VersionedDocC: Versioned Swift-DocC websites, API diffs, and reusable release caches
@Kyle-Ye: VersionedDocC 是一个基于现有 Swift 工具链和 DocC 的版本化文档发布与维护工具。它支持为开发分支和多个发布版本生成具有稳定路径的文档站点，在 DocC 页头直接切换版本，并基于公开的 Symbol Graph 生成 API 差异页面；同时还提供多平台文档合并、旧链接重定向和自动选择各发布系列最新补丁版本等能力。通过不可变的按版本缓存（支持 GHCR 等 OCI Registry），新增版本时只需构建新版本和开发分支，无需重复生成全部历史文档，并可直接集成 SwiftPM、GitHub Actions 与 GitHub Pages。适合需要长期维护多版本 Swift API 文档的库作者关注。
文章
🐕 「iOS」解构与重组：AI 时代下的 WICompress 2.0
@EyreFree：本文介绍 iOS 图片压缩库 WICompress 从简易工具迭代至 2.0 版本的完整重构历程，并探讨 AI 辅助开发下开发者的定位。项目最初仅 204 行代码，借助 AI 拓展能力后代码膨胀、职责混乱，两套压缩逻辑混杂，模块臃肿。作者推翻冗余设计，拆分出 Process 固定参数处理、Target 字节上限约束两条独立流程，分层隔离 ImageIO 解码编码与 CoreGraphics 渲染逻辑，以 ImagePipeline 作为统一调度核心。重构精简大量冗余代码，同时依托 AI 完成调研、编码与校验。作者认为 AI 可高效实现各类技术方案，但开发者需要把控架构边界、取舍需求，最终 WICompress 2.0 基于 Swift6.2 发布，分层清晰、API 简洁，附带完善配套文档。感兴趣的朋友可以看看。
🐢 WWDC26：SQLiteData 系列
Sectioning｜Codability｜Advanced Domain Modeling
@AidenRao：Point-Free 团队通过三期内容，以 WWDC26 的 SampleTrips 为例，系统展示 SQLiteData 在查询与领域建模方面的能力。第一篇从 SwiftData 新增的 sectionBy 出发，使用 @fetchall 和类型安全的查询构建器实现动态筛选、排序与分组；分组依据不局限于模型上的字符串字段，还可以来自计算结果、关联数据，甚至被组织为层级结构。第二篇讨论 Codable 数据的存储与查询：SQLiteData 可以把复杂值保存为 JSON，同时借助 jsonExtract、Swift KeyPath 和 #sql 保留类型与 Schema 安全，直接对 JSON 内部字段进行过滤、排序和分组，文中还演示了根据经纬度计算距离并划分行程区间。第三篇进一步引入更高效的 JSONB、用于遍历数组的 json_each，以及将多列映射为领域值类型的 grouped columns，说明并非所有成组数据都必须序列化为 JSON。整个系列既展示了 SQLite 底层能力，也对比了 SwiftData 在动态查询、复杂字段和运行时安全方面的限制，适合希望深入理解 SQLiteData、数据库查询以及 Swift 领域建模的开发者阅读。
🐎 Using SwiftUI ContentBuilder with non ‑ View types
@DylanYang：本文作者讲解了如何把 SwiftUI 的 @ContentBuilder 用于非 View 类型场景。ContentBuilder 和大家熟悉的 ViewBuilder 机制类似，允许我们使用 DSL 风格的闭包语法去构建自定义数据模型，而不局限于构建视图。文中演示了自定义标记 ContentBuilder 的用法，处理条件分支、循环遍历等 DSL 常见场景，同时也说明了一些限制点，比如对 if ‑ let、switch 的支持情况。借助这套能力，开发者可以给自己的数据结构实现声明式的构建语法，提升代码可读性。感兴趣的读者可以阅读原文进一步了解。
工具
🐎 The Swift Programming Language：可切换历史版本的官方 Swift 书
@JonyFang：官方 TSPL 一直是查语法、补语言特性和带新人入门的标准参考，但 docs.swift.org 通常只提供当前版本。这个站点用 VersionedDocC 按 Swift 发行标签重新构建了同一本书，页头可以直接在 main（6.4 beta）、6.3、6.2.x、6.1、6、5.10 一直到 5.7 共 12 个版本之间切换，每个版本都有稳定 URL。
更有用的是相邻版本的 Changes 页：6.3 到 main 能看到 Concurrency、Protocols、Opaque Types 等 9 处修订，5.8 到 5.9 则能直接定位到新增的 Macros 章。维护旧工程、或想对照语言书在版本间怎么改的时候，比只看最新版方便很多。正文源码仍指向 swiftlang/swift-book。
内推
重新开始更新「iOS 靠谱内推专题」，整理了最近明确在招人的岗位，供大家参考
- [深圳 / 上海 / 北京] 抖音研发 - 客户端渲染引擎研发工程师（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）
Contributors
Assets 2
老司机 iOS 周报 #376 | 2026-08-03
老司机 iOS 周报，只为你呈现有价值的信息。
你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。
文章
🐕 Splitting Large SwiftUI Views in the Apple's way
@AidenRao：在 SwiftUI 中，将冗长的 body 拆成计算属性或 @ViewBuilder 虽然能改善代码可读性，却不会形成新的更新边界；父视图的状态发生变化时，这些内容依然会跟随 body 一起重新求值。作者结合 Walk Mate 的实际重构与 Apple 最新的视图结构建议，指出更有效的做法是把职责明确、依赖相对独立的区域提取为单独的 View 结构体，并只传入其真正需要的数据。这样 SwiftUI 就能比较子视图的输入，在数据没有变化时跳过不必要的 body 计算。
🐕 The Anatomy of a Reusable SwiftUI View
@阿权：文章讨论了如何设计 API 接近 Apple 原生视图的自定义可复用 SwiftUI 组件。设计思路主要分为：
- 组件分类：语义组件（Semantic）、规定性组件（Prescriptive）。
- 设计原则：先建模语义，遵循数据流，保留原生行为，保持可预测。
- 具体的 API 设计，扩展 API 设计。
- 最后作者给出了一份最佳实践清单：
- 判断组件是语义型还是规定型
- 先建模有效状态和有意限制，再考虑外观
- 从灵活的基础初始化器开始，添加聚焦的便捷初始化器
- 匹配系统视图的命名和参数类型
- 遵循 SwiftUI 数据流和交互约定
- 优先使用宽泛的系统抽象（
View、ShapeStyle、LocalizedStringResource） - 语义组件用自定义视图样式，规定性组件用环境值
- 将无障碍和相关环境值视为组件的一部分
- 保持优先级和扩展点可预测
- 在有意义的状态下预览和测试组件
🐕 Previews and MCP
@Cooper Chen：作者分享了在 Xcode 27 beta 中利用 MCP 调用 RenderPreview 工具的探索，详细梳理了从建立连接、发送 JSON-RPC 请求到接收预览截图的技术链路。文章并未回避现实障碍——沙盒限制让直接调用 xcrun mcpbridge 无法上架 Mac App Store，而借助 XPC 服务、外部托管助手应用等变通方案则伴随着复杂的管理成本。尽管如此，作者仍满怀热情地预告了即将推出的 PreviewSmith，为开发者提供直观的预览浏览体验。全文既有底层接口的深入剖析，也有对工程化挑战的坦诚记录，技术干货与个人色彩兼备，值得关注 SwiftUI 预览生态的开发者一读。
工具
xntfs 和 xlinuxfs：让 macOS 更自然地读写跨平台磁盘
@EyreFree：两款 macOS 工具 xntfs 与 xlinuxfs，依托系统原生 FSKit 框架实现跨平台磁盘读写，无需依赖 macFUSE 与内核扩展。xntfs 结合 ntfs-3g，让系统自动挂载并正常读写 NTFS 格式磁盘，补齐 macOS 原生短板。xlinuxfs 基于 LKL 方案，直接调用 Linux 原生驱动，支持 ext4、XFS、Btrfs 等主流 Linux 文件系统。两款工具定位轻量化，仅负责磁盘挂载与读写，附带状态诊断、权限设置等基础功能。接入后外部磁盘可被系统原生识别，在 Finder 中正常使用，有效消除跨系统存储设备的使用割裂感，适配开发、运维等多类使用场景。
应用商店链接：
xntfs：https://apps.apple.com/cn/app/xntfs/id6782636021
xlinuxfs：https://apps.apple.com/cn/app/xlinuxfs/id6785355678
内推
重新开始更新「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）
Contributors
Assets 2
老司机 iOS 周报 #375 | 2026-07-20
老司机 iOS 周报，只为你呈现有价值的信息。
你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。
文章
🐎 iOS 27 Adds Mac-Like Recovery Mode for iPhone and iPad
@EyreFree：本文介绍 iOS 27 为 iPhone、iPad 新增类似苹果硅 Mac 的本机轻量化恢复模式。关机后长按电源键开机并持续按住，即可进入独立恢复界面，无需完整加载系统。界面内置恢复助手、在线更新、设备诊断、抹除数据、传统恢复五大功能，可自动连接已存 Wi-Fi、显示电量，支持一键正常重启。以往系统更新失败、设备无限重启等故障，必须借助电脑 DFU 刷机，如今可本机重装稳定系统、自动修复故障，大幅降低设备维修门槛。该功能当前处于开发者测试阶段，公测版下月推出，秋季正式上线。
🐎 Using Cursor in Xcode 27
@Cooper Chen：这篇文章聚焦 Xcode 27 的 Agentic Development 新能力，手把手演示如何将 Cursor 作为 ACP 兼容代理接入 Xcode。内容从安装 Cursor agent CLI、配置可执行文件与参数，到在新会话中选择代理，流程清晰实用。适合希望保留 Xcode 原生体验，同时借助 Cursor 提升开发效率的 iOS/macOS 开发者阅读。
🐢 sim-use - 给 agent 装上眼睛和手，让 mobile 开发跟上 AI 时代
@JonyFang：随着 Agent 写代码越来越快，移动端开发的瓶颈也逐渐转向了如何验证结果。本文介绍 onevcat 开源的跨平台工具 sim-use，它能让 Agent 看懂并操作 iOS、Android 界面，自主完成交互和验证。文章还分享了 Outline DSL、UI 元素探测、常驻 Daemon 等关键设计，是一篇很有参考价值的 Mobile Agent 工程实践。
🐎 The hidden cost of unstable SwiftUI environment defaults
@Barney：这篇文章讨论了 Xcode 27 对 SwiftUI @Entry 环境值新增的一个警告：如果默认值直接创建 class 实例，每次 fallback 读取都会得到新的引用，SwiftUI 可能把它视为环境变化，连带触发依赖视图的额外 body 计算。作者用 logger 示例说明，即使真正变化的是无关的 environment value，读取默认 logger 的子视图也会被重新求值。解决方式是把默认对象放到稳定存储中再引用，或把环境值设计成可选并在 App 层显式注入；类似 Date()、UUID() 这类每次求值不同的默认表达式也应避免。适合排查 SwiftUI 视图更新噪音和性能问题时参考。
🐎 Previews and MCP
@zhangferry：作者想做一款应用：开发者不必逐个打开源码或在 Xcode 里来回切换，就能看到所有界面预览。但要实现它，第一个难点在于如何让独立运行的应用拿到 Xcode 生成的 Preview 图片。解决思路是利用 Xcode 27 beta 3 提供的 MCP 能力。应用先通过 xcrun mcpbridge 与 Xcode 建立连接，再用 MCP 的 RenderPreview 工具指定项目文件和 Preview 序号，让 Xcode 完成渲染。双方按照 JSON-RPC 格式交换消息，应用负责启动进程、通过标准输入输出发送请求，并异步读取返回结果。成功后，Xcode 会提供预览快照、实际运行环境，以及可用的本地化和变体信息。
但这条路很快碰到了 macOS 沙盒限制：mcpbridge 需要访问 Xcode，生成的图片又可能位于主 App 无法读取的临时目录。因此作者提出把连接 Xcode、执行渲染和读取图片的工作交给一个独立的未沙盒化辅助程序，再通过 XPC 将图片数据传回沙盒内的主 App。
🐕 Introducing the Safari MCP server for web developers
@Smallfly：WebKit 介绍了 Safari MCP server，它把 Safari 浏览器窗口接入支持 MCP 的 AI 编程工具，让 Agent 可以直接读取 DOM、网络请求、控制台日志、截图和页面状态。这篇文章的价值在于展示了「浏览器可观测能力 + Agent」如何改变调试流程：少一些截图描述和窗口切换，多一些真实页面验证。适合关注 AI 开发工具、Safari 兼容性、性能分析和可访问性检查的开发者阅读。
🐎 由于 iOS 26 的键盘变化，Flutter 又要重构键盘区域逻辑
@david-clang：iOS 26 的 Liquid Glass 让系统键盘变成了半透明、圆角形态，打破 Flutter 过去的隐含假设：键盘区域是不可见的、不透明矩形，现在键盘会“透出”背后的颜色，BottomSheet、Modal、Overlay 等场景就可能出现明显的背景断裂。
Flutter 官方的解决思路是：内容照样被键盘顶上去，但背景要补到键盘后面。这样输入框、列表等可交互内容不会被键盘挡住，同时 BottomSheet、Modal、Overlay 的背景色也能延伸到半透明键盘背后，避免露出不一致的底色。但目前相关实现还在 draft 阶段。
🐎 The SwiftUI Performance Skill
@DylanYang：本文介绍了一款面向 AI Agent 的 SwiftUI 性能专项 review 技能，以「变更局部性」为核心思路，设定了视图身份、渲染开销、依赖范围等优先审查顺序与证据分级规则，拆分 8 个细分性能模块，可针对滚动卡顿、多余视图重绘等场景，输出贴合 SwiftUI 更新机制的精准优化方案。
内推
重新开始更新「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）
老司机 iOS 周报 #374 | 2026-07-06
老司机 iOS 周报，只为你呈现有价值的信息。
你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。
文章
🐎 【 Taro 5.0 技术与实践】 - 高性能 iOS 渲染层与 TaroUI 跨端框架介绍
@david-clang：文章介绍了 Taro 5.0 的高性能 iOS 渲染层和 TaroUI 跨端 UI 框架：
- 高性能 iOS 渲染层：主要介绍其架构设计与优化策略，包括双线程渲染管线、原生 View 与图层混合渲染、视图拍平、组件复用池、富文本引擎、图片渲染优化等能力。
- TaroUI 跨端 UI 框架：TaroUI 是一个以 C++ 为核心开发的命令式跨端 UI 框架，重点解决多端组件一致性、原生渲染能力复用、事件系统、渲染管线调度以及高性能列表等问题。
对于关注 Taro 生态、移动端跨端架构和原生渲染优化的读者，这篇文章有一定参考价值，让我们期待 Taro 5.0 的开源吧。
🐕 SwiftUI animation timing
@EyreFree：本文详解 SwiftUI 动画时序控制方案，适配 iOS17 新特性。文章先讲解基于三次贝塞尔曲线的四大内置缓动动画 linear、easeIn、easeOut、easeInOut，还支持自定义贝塞尔与圆形时序曲线；随后介绍弹簧动画 smooth、snappy、bouncy 三类预设，提供时长、弹性等参数自定义方式。iOS17 新增 CustomAnimation 协议可完全自研动画曲线，并演示弹弓动画示例。文末介绍 delay、speed、循环重复等通用动画修饰器，搭配完整代码示例。文章覆盖 UI 动效各类场景，清晰区分不同曲线视觉差异，帮助开发者快速选用适配的动画时序，打造流畅自然的界面动效。感兴趣的同学不要错过。
🐎 SwiftUI SensoryFeedback Cache Key 经验教训：不要存储连续值
@DylanYang：本文介绍了 iOS 17 ~ iOS 26 中 SwiftUI SensoryFeedback 的底层缓存设计缺陷：连续变化的 intensity 浮点参数会被纳入反馈生成器的缓存 Key，导致滑动调节强度时生成大量冗余实例，引发内存持续上涨。文章也解读了 iOS 27 的官方修复思路 —— 将 SensoryFeedback 拆分为稳定的 type 与动态的 payload 两部分，仅以类型作为缓存标识，在不改动公共 API 的前提下从架构层面解决了问题。
🐢 SwiftUI Is One Graph, Over 40+ Years of Engineering
@阿权：文章从工程和专利两个独立维度剖析了 SwiftUI 的本质：
- SwiftUI 的本质：不是一棵视图树，而是单一的需求驱动属性图。每个视图编译为属性节点，依赖关系通过求值时实际读取来动态发现，而非声明。变更时只标记脏节点，沿依赖边向前传播，然后按需拉取并缓存，从而实现极小的更新成本（与变更相关，而非 UI 规模）。
- 核心机制：
View是值（struct），@State按标识持久存储，标识为结构位置（类型+树位置），显式.id与之配对。- 布局是父提议、子自选、父放置的协商，父不强制尺寸。
- SwiftUI 合并图层，而不是每
View一层，大幅减少图层数，但合并内容变化需重绘。 - 动画时模型直接跳到终值，框架复制目标并注入插值呈现。
- 专利印证：苹果专利 US 11,042,388 B2 完整描述了属性图、脏位、自底向上更新、动画记录和模型/呈现副本分离，与行为观察完全一致。
SwiftUI 只是底层技术栈（Core Animation、Core Graphics、Core Text、Core Image）之上的一层薄图，其优雅但“无趣”。真正震撼的是 Core Animation 等底层引擎。SwiftUI 最初为简化 watchOS 开发而生，后被推广至全平台；虽能让开发者快速交付功能，但仅掌握 SwiftUI 等同于只懂 “门面”，未真正理解苹果平台的底层技术，而底层的合成、绘图、排版引擎才是解决复杂问题的关键，SwiftUI 只是切入这些核心技术的 “便捷入口”。
🐕 系统化的iOS面试知识库
@含笑饮砒霜：这个仓库是一个系统化的 iOS 面试知识库，可以帮助 iOS 开发者从基础到进阶梳理面试所需知识。它以 README 和文章目录为入口，内容覆盖 Objective-C/Swift 基础、Runtime、RunLoop、内存管理、多线程、网络、性能优化、架构设计、组件化、底层原理等常见面试主题，适合用来做面试前的知识复盘和查漏补缺。
🐕Siri 提示词解析
@zhangferry：这套 Siri 提示词由 iOS 27 Developer Beta 1 的 Siri Diagnostics 诊断文件意外暴露。在这套设计中，Siri 以 Entity 为中心：联系人、邮件、地点等信息都被封装为带有唯一 ID 的 Entity。同一个 Entity 既能提供事实依据，也能用于工具调用、结果引用和原生 UI 展示。提示词还明确了几项限制：缺失信息不能自行推断，目标不唯一时需要先确认，工具没有返回成功就不能宣称任务已经完成。它的核心并不是陪用户聊天，而是可靠地理解现实对象，并执行搜索、通信、导航等操作。
最近流传的另一份材料是 Claude Fable 5 — System Prompt。这份提示词的真实性和完整性尚无法验证，但其中部分内容与 Anthropic 官方公开的片段吻合。Fable 5 采用的是“工作流驱动”设计：先识别任务类型，再将任务路由到搜索、文件制作、MCP 或专业 Skill。
虽然现在需要我们直接调试和优化底层 Prompt 的场景越来越少，但研究这些优秀 Prompt 的设计方式，仍然可以帮助我们理解产品背后的处理策略。理解这些策略，不仅能让我们更有效地使用对应产品，也能为设计自己的自动化流程和 Agent 提供参考。
🐎 iOS 27 SDK: 3 Major Requirements That Might Break Your App
@JonyFang：这篇文章整理了 iOS 27 SDK（Xcode 27）开始强制执行、且可能影响现有 App 的三项要求：
- UIScene 生命周期：使用新 SDK 构建的 App 需迁移到 Scene-based lifecycle，补齐
UIApplicationSceneManifest和SceneDelegate，否则可能启动即崩。 - Launch Screen 配置：App Store Connect 会检查
Info.plist中是否声明启动屏配置，老项目或迁移项目需要提前确认，避免触发 ITMS-90870 被拒。 - Liquid Glass 适配：
UIDesignRequiresCompatibility兼容开关在 iOS 27 中不再生效，导航栏、Tab Bar、滚动视图和自定义 UIKit 样式都需要重新验证展示效果。
这篇文章适合在维护 UIKit 项目、或准备升级 Xcode 27 构建链的开发快速自查。三项改动本身不复杂，但都属于会影响启动、提审或 UI 表现的 SDK 级要求，建议尽早在 iOS 27 模拟器上完成验证。
🐎 All new frameworks presented at WWDC26
@ChengzhiHuang：本文列举了 WWDC26 新发布的 framework ，绝大部分都有 beta 版本的文档了，网站还提供了分 OS 的情况。除了 CoreAI 、FoundationModels 、MediaIntelligence 等大模型相关能力，引起我们注意的还有 CrashReportExtension ，方便我们在另一个进程中消费 Crash Log 并通过网络上报。可以把 app 极端场景（例如连续启动崩溃）下本进程自监控 APM 无法覆盖到的场景支持上，算是一个社区呼吁了很久的能力。
代码
🐎 HarmonyOS NEXT 开发者专家技能包
@Crazy：在使用 AI 来开发 HarmonyOS NEXT 应用的时候经常会出现 AI 判定写完，但是一运行就是一大堆的报错，不仅是包引错，更会使用各种 HarmonyOS 完全没有的 api。这个时候就需要一个本地知识库来优化控制，这个项目把鸿蒙官方 API 文档 + DevEco 私有自动化能力，打包成一个离线的 AI skill，并支持了 Claude/Gemini/Codex 三个主流平台，引入方式与提供的功能在它的 README 里面也写的非常清楚，是一个值得使用的项目。
内推
重新开始更新「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）
老司机 iOS 周报 #372 | 2026-06-08
老司机 iOS 周报，只为你呈现有价值的信息。
你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。
文章
🐢 从 0 开发大模型的 17 种 Agent 架构演进详细拆解
@david-clang：作者用 agno 框架把 all-agentic-architectures 里用 LangChain + LangGraph 实现的 17 种 Agent Architecture 从头写了一遍，证明了 Agent Architecture 的本质不是 Prompt Engineering，也不是某个框架的 DSL，而是控制流设计，它应该能在任何体面的 Agent 框架里复现。作者对每一种架构都用同一套问题去拆解，并且全部用 agno 框架做抽象表达，这种拆解 Agent 架构的方法很值得借鉴。
🐢 抖音动态体验优化实践与思考
@ChengzhiHuang: 抖音 Android 基于业务的实际诉求，建立了新的动态性能框架，站在更高与更全局的视角，获取更完整的输入信号，结合千人千面（端智能），进行更具体的策略调用。Android 在系统能力上能做的比 iOS 会多很多，但是建设的思路都是相同的，建立硬件的 QoS 指标，再结合业务的具体场景，再作出变更，在资源受限下给用户带来更好的体验。
🐎 DebugSnapshots Public Beta
@Smallfly：这篇是 PointFree 团队推出的全新调试工具 DebugSnapshots 的公开测试介绍，该工具可以序列化存储应用运行时的全链路状态快照，包含视图层级、网络请求、用户交互轨迹、状态变更记录等信息，帮助开发者快速复现线上、测试环境的偶现疑难问题。工具支持与 SwiftUI、UIKit 项目无缝集成，无需大量侵入式代码修改，还可配合 PointFree 生态的状态管理、并发工具使用，有效降低复杂客户端应用的问题排查成本，适合苹果生态开发者了解前沿调试方案，优化问题处理效率。
🐕 Harness 不是目的，知识才是护城河 —— 一个 AI 工程交付团队的知识沉淀实践
@DylanYang：本文作者基于 AI 工程团队的落地实践，提出了与当前 Harness Engineering 热潮不同的核心观点：工作流只是管道，团队私域知识的沉淀才是真正的技术护城河。文章系统阐述了 Harness Engineering 的三支柱理论，论证了知识沉淀的三大核心价值（可累积性、非一次性、复利效应），并详细介绍了团队设计的知识体系架构。同时分享了独立 Git 仓库作为知识单一事实来源的建设方案和消费模式。感兴趣的开发同学可以阅读下具体内容。
🐕 Task Names in Swift Concurrency
@AidenRao：在排查并发问题时，我们早已习惯了 GCD Queue Label 带来的便利：崩溃日志、Instruments 时间线、调试器输出中都能快速定位任务来源。然而 Swift Concurrency 自诞生以来，Task 一直缺少类似的可读标识。随着 Swift 6.2 中 SE-0469 的落地，开发者终于可以为 Task 指定名称（Task Name）了。本文详细介绍了 Task Name 的使用方式，以及它在 LLDB、Instruments 和 SwiftUI .task 中的实际表现效果。虽然只是一个看似不起眼的小特性，却能显著提升复杂并发场景下的问题定位效率。如果你的项目已经大量使用 async/await、TaskGroup 或 SwiftUI Concurrency，那么了解并合理使用 Task Name，将会是提升调试体验的一个低成本优化。
工具
🐕 harness-creator
@Barney：这是 Learn Harness Engineering 项目里提供的一个可复用 Skill，用来为 AI Coding Agent 快速搭建或审计项目级 Harness。它关注的不是模型选择或单次 Prompt，而是把 Agent 工作所依赖的环境补齐：根目录指令文件（AGENTS.md / CLAUDE.md）、任务状态、验证命令、作用域边界和会话交接。实际使用上，可以通过 create-harness.mjs 生成 feature_list.json、progress.md、init.sh 等基础文件，也可以用 validate-harness.mjs 按五个子系统给现有项目打分。比较有价值的一点是，它把“让 Agent 更可靠”从经验口号落到了可检查、可迭代的仓库结构上，适合正在把 AI 编程流程沉淀成团队规范的同学参考。
代码
🐕 让 SwiftUI View 在截图中隐藏
@阿权：作者实现一种方案，可以让特定 SwiftUI View 在截图中隐藏。Apple 公开和推荐的方案是在截图时将 view 替换而不是简单的隐藏，能有隐藏能力的只有 Secure Text Field，而它的本质调用是配置 CALayer 的私有属性 disableUpdateMask 为 0x12。作者通过实现 SwiftUI modifier 将这个调用带到了 SwfitUI，实现了为特定 SwiftUI View 实现截图隐藏的能力。
需注意的是，这个能力仍要按依赖 SPI 的能力来看待。这个方案比较有趣的是如何找到 Secure Text Field 实现截图隐藏的根本调用，以及如何将能力桥接到 SwiftUI 上。
内推
重新开始更新「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）
老司机 iOS 周报 #371 | 2026-05-25
老司机 iOS 周报，只为你呈现有价值的信息。
你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。
新闻
WWDC 内参网页版上线
历史的 WWDC 内参网页版上线啦，免费对所有人开放！我们对 21 年至 24 年的所有内容聚合整理，同时 Github 仓库源码也已开源，大家可以看到所有的创作者与审核老师的 commit 记录，共 3278 笔 commit 。对于我们来说，也算是了却了自从小专栏下线后的一桩心愿，凝聚着大家心血的内容终于以另一种方式留下了印记。
文章
🐢 论文解读 | 从 Prompt 到 Harness：AHE 如何让 Coding Agent 自我进化
@Cooper Chen：AI 编程智能体正陷入“提示词内卷”——调来调去，换来的不过是几个百分点的波动。复旦、北大与齐济智风团队提出的 Agentic Harness Engineering（AHE），给出了一个截然不同的答案：与其费力教模型思考，不如让它学会改造自己的“工程骨架”。
AHE 将优化焦点从模型内部的 System Prompt 转向外部的完整 Harness ——工具定义、技能库、记忆结构，这些都是模型可以自主编写、测试、迭代的“可进化组件”。实验结果很有说服力：GPT-5.4 在 Terminal-Bench 2 上的首次尝试成功率从 69.7% 跃升至 77.0%；更难得的是，进化出的 Harness 可以迁移到 SWE-bench-verified 等新任务，且保持高效低耗。
这项工作的可贵之处在于，它既给出了可落地的代码与论文，又提供了一条清晰的路径：让智能体从“被设计”走向“自设计”。无论你是 AI 研究者还是工程开发者，AHE 都值得你花时间拆解——它可能重新定义下一代 Agent 的优化范式。
🐕 Scheduling and handling background app refresh in SwiftUI
@Barney：这篇文章用一个 DogFacts 示例，把 SwiftUI App 生命周期下接入后台刷新任务的完整链路串了起来。核心步骤包括：在 Xcode 中开启 Background Modes 并选择 Background fetch，在 Info.plist 中注册 BGTaskSchedulerPermittedIdentifiers，用 BGAppRefreshTaskRequest 提交后台任务，再通过 SwiftUI 的 backgroundTask(_:action:) scene modifier 注册处理逻辑。文章也强调了几个容易踩的点：任务触发时间只代表系统允许的最早时间，不适合承载关键业务逻辑；后台 fetch 通常需要在约 30 秒内完成，否则应用可能被系统终止并影响后续调度；调试时可以通过 pendingTaskRequests() 确认任务已入队，再用 Xcode 控制台的 _simulateLaunchForTaskWithIdentifier 模拟后台唤醒。适合需要在 SwiftUI 应用里做轻量数据预取或定期维护任务的同学参考。
🐢 C++ Exceptions under the hood
@老驴：这篇 C++ Exceptions under the hood 从手写迷你 ABI 出发，把 C++ 异常背后的 throw/catch、栈展开、LSDA、landing pad 和 _Unwind 机制拆到寄存器层面。适合想深入理解语言运行时与底层实现的 C++ / 系统编程读者。
工具
🐕 ReadyCheck: the Human Perception Layer for AI agents working on running software
@阿权：ReadyCheck 是一款 Claude Code 插件，用于给 Agent 提供人类感知层。简单来说就是给 Agent 装上看懂用户操作流程的眼睛和理解人话的耳朵，把人们在发现问题、阐述问题所产生了现场截图、语音 / 语言描述，结合程序执行流程，转化为 Agent 理解的形式作为问题理解、排查和修复的上下文，让使用者对 Agent 的输入更自然和高效。
Demo 视频祥见 YouTube。
🐕 实用性 Max ，新 Flutter & Dart Agent Skills 深度解读
@JonyFang：文章围绕 Flutter 与 Dart 官方 Skills 的新变化展开，指出它们从“文档型提示”转向了更实用的“任务导向型工作流”。文中先介绍了官方通过 tool/generator 从文档自动生成、更新和校验 SKILL.md 的流水线，再重点解读了布局修复、Widget 测试、集成测试、响应式布局、国际化、JSON 序列化、Widget Previewer，以及 Dart 侧运行时错误修复、Pattern Matching、package:checks 迁移等 Skills。
这篇文章值得关注的点在于，它把 Skill 的价值从“告诉 AI API 怎么用”提升到了“告诉 AI 在什么场景下如何决策、如何修复、如何验证”。对于正在用 AI 做 Flutter/Dart 开发，或者希望把项目经验沉淀成 AI 可执行工程规范的同学，有参考价值。
代码
Yuedu-reader
@Smallfly：Yuedu Reader 是一款基于 CoreText 构建的 iOS 原生阅读器，专注于 CJK 竖排排版与高性能渲染。它避开了常见的 WebView 方案，提供了精准的分页控制与 WebDAV 同步功能，并兼容 Legado 书源规则，适合对排版细节和底层技术有特定需求的阅读爱好者。
内推
重新开始更新「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）
Contributors
Assets 2
老司机 iOS 周报 #370 | 2026-05-11
老司机 iOS 周报，只为你呈现有价值的信息。
你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。
新闻
🐕 DanceUI 开源
@Kyle-Ye: DanceUI 是 ByteDance 开源的类 SwiftUI 声明式 UI 框架，目标是在 SwiftUI 风格的 DSL 和更低系统版本兼容之间做一层工程化实现。项目提供了与 SwiftUI 对齐的基础能力，包括 State、Binding、Environment、PreferenceKey、NavigationView、ScrollView 等，同时通过 DanceUIRuntime、DanceUIGraph、OpenCombine 和 DanceUIObservation 相关模块支撑状态更新与渲染链路。整体预期是可以直接复用 SwiftUI 生态且最低支持 iOS 13。
文章
🐢 Trust, Then Verify
@Cooper Chen：以这篇文章《Trust, Then Verify》开头，你会很快意识到 : 真正拉开 AI 编程差距的，不是“写得快”，而是“能自证”。作者围绕 iOS 场景搭建了一套完整验证闭环 : 构建侧用 xcodebuild + xcbeautify 控噪并保留原始日志兜底，交互侧用 AXe 与 simctl 将启动、点击、读值、断言流程脚本化，让 Agent 从“像是对了”走向“可验证地对了”。更可贵的是文中沉淀出的工程方法论 : 入口宽松、断言严格；在最靠近原因的位置让失败可见；把经验性步骤持续机械化；通过使用驱动迁移而非一次性大审计。对 iOS 团队和所有实践 Agentic Coding 的开发者来说，这篇文章都值得细读。
🐕 Anthropic 产品团队为何快过所有人
@zhangferry：Anthropic 的成功不能简单归功于 Claude Code、Co-Work 这类明星级产品，而是应该着重关注这类产品迭代背后的方法论。这篇文章的访谈嘉宾 Cat Woo 是 Claude Code 和 Co-work 的产品负责人，她系统性地分享了 Claude Code 团队的实战经验。他们的产品是 AI，他们的工作方式也因为 AI 被全面重塑；访谈涵盖了一个核心命题：当模型能力每隔几个月就跃升一次，产品经理的角色该如何重新定义？
🐎 Why Your pbxproj Is Bloated (and How to Fix It)
@david-clang：为什么 .pbxproj 容易臃肿和冲突？因为它记录了所有文件的 UUID，而使用 Groups 会让 Xcode 追踪每一个文件变动。文章介绍的解决办法很简单，用 Folders 代替 Groups，Xcode 只引用目录，不追踪单文件。另外，使用 XcodeGen 也能解决，它将 .xcodeproj 移出 Git，全靠本地按需生成，实现零冲突。
🐕 Six Years Perfecting Maps on watchOS
@Barney：David Smith 在这篇文章里复盘了 Pedometer++ 为 watchOS 打磨地图体验的六年历程，内容很适合拿来理解小屏设备上的产品设计为什么往往是工程能力、交互约束和视觉语言一起决定的。作者最初用服务端生成地图验证方向，随后因为离线能力、性能和交互需求，转向自研基于 SwiftUI 的地图渲染引擎；在界面层面，则经历了大量失败方案，最终收敛到“地图作为顶部主页面，指标信息层叠覆盖”的结构，并通过点击进入浏览模式来解决地图交互与 watchOS 手势冲突。文章后半段也很有意思：为了适配 watchOS 26 的 Liquid Glass，他甚至定制了新的底图与深色模式样式，并解释了为什么最终没有直接采用 MapKit。整体来看，这是一篇把平台限制、设计迭代和技术取舍讲得非常完整的实战复盘。
🐕 Synchronization in Swift: Actors vs Queues vs Locks
@Smallfly：这篇是 Swift 并发同步机制的深度指南，系统对比四类核心同步工具的设计哲学、适用场景与权衡取舍，为开发者构建线程安全代码提供全面决策框架。文章从语言级到硬件级逐层拆解各工具特性：Actors 适合异步环境下的缓存、服务类等状态组件，DispatchQueue 适配依赖执行上下文协调的场景，Locks/Mutexes 性能开销低适合同步小操作，Atomics 则适配计数器、状态标志等单操作场景。文中还给出各工具典型误用的修复方案，打破性能优先的误区，综合安全性、API 设计清晰度、认知负荷等维度给出选择指导，通过场景化分析与可运行示例，帮助开发者理解 Swift 并发同步本质，在复杂系统中做出合理技术选择。
工具
🐎 Cupertino v1.0.0 "First Light"
@阿权：Cupertino MCP 发布 v1.0.0 "First Light" 版本。Cupertino 是一款本地 Apple 文档爬虫 MCP，使用 Swift 编写。用于解决 LLM 对 Apple API 回答幻觉问题，让模型推理时能获取精准、排名合理的 Apple 官方文档，本次版本实现了全流程（爬取、索引、排名、服务、分发）稳定，具体如下：
- 搜索准确度大幅提升。优化语料库和权重策略；apple-docs 内部使用 BM25F 算法结合 AST 符 号索引，叠加多个搜索规则以精准命中目标；提升 SQL 性能。
- 分发与部署简化。合并三个数据库为单包。
- 架构与兼容性提升。数据库升级、MCP 协议升级、爬虫强化。
内推
重新开始更新「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）
老司机 iOS 周报 #369 | 2026-04-27
老司机 iOS 周报，只为你呈现有价值的信息。
你也可以为这个项目出一份力，如果发现有价值的信息、文章、工具等可以到 Issues 里提给我们，我们会尽快处理。记得写上推荐的理由哦。有建议和意见也欢迎到 Issues 提出。
文章
🌟 🐢 Under the hood: Android 17’s lock-free MessageQueue
@Crazy：Android MessageQueue 是从 Android 的核心框架，从 API1 就已经存在了，这次 Android 针对它进行了重构，是非常大的优化。
原始 MessageQueue 存在的问题： Android 的 MessageQueue 在过去的二十多年里靠着一把 monitor 同步锁保护，虽然没有大的问题，但是在多核多优先级场景下，这把锁会引发多线程争用同一把锁，并且进一步引发高优先级 UI 线程被低优先级后台线程间接拖慢。
新 MessageQueue 设计核心 DeliQueue： 新的 DeliQueue 采用 lock-free 数据结构的设计方式来解决上面的问题，简单用一句话来描述就是 “可以无锁写入的多生产者线程与独占排序和结构整理能力的单消费者 Looper 线程。” 核心方式就是利用原子操作来替代锁，下面我们把 lock-free 拆解一下，不涉及很多的源码。
- 插入序号： 利用 mNextInsertSeqValue/mNextFrontInsertSeqValue 两个 volatile 变量来进行插入排序, 主要判断在 enqueueMessageUnchecked 方法的第一行，就是判断 when 是否为 0 来保证不管来自多少个生产者线程的任何两个消息都有一个全序：先比 when，再比 insertSeq。最小堆就靠这个 key 排序。
long seq = when != 0 ? ((long) sNextInsertSeq.getAndAdd(this, 1L) + 1L) : ((long) sNextFrontInsertSeq.getAndAdd(this, -1L) - 1L);- 唤醒判断： 利用 mWaitState 这个 volatile 变量实现 64 位状态机，然后加上 CAS 版本号操作实现整体唤醒判断.
if (WaitState.isCounter(waitState)) {
// 情况 A：looper 已醒
} else if (msg.when >= WaitState.getTSMillis(waitState)) {
// 情况 B：新消息不比当前 deadline 更早，我们不需要唤醒
} else if (msg.isAsynchronous()) {
// 情况 C：新消息更早，且是 async（绕过消息屏障），需要唤醒
} else {
// 情况 D：我们需要看消息屏障状态，决定是否需要唤醒
if (blockedByBarrier) {
newWaitState = WaitState.incrementDeadline(waitState);
checkBarrier = barrier;
needWake = false;
} else {
newWaitState = WaitState.initCounter();
checkBarrier = null;
needWake = true;
}
}- native 指针保护： 利用 mMptrRefCountValue 这个 volatile 变量实现对 native epoll 的句柄控制。native epoll 句柄，必须有人持有时不能 free，无人持有时要立即 free，Google 仅用一个 long 就这两件事。
private static final long MPTR_TEARDOWN_MASK = 1L << 63;
// 生产者增引用（incrementMptrRefs）
while (true) {
final long oldVal = mMptrRefCountValue;
if ((oldVal & MPTR_TEARDOWN_MASK) != 0) {
return false; // 已 teardown，拒绝新引用
}
if (sMptrRefCount.compareAndSet(this, oldVal, oldVal + 1L)) {
return true;
}
}
// 生产者减引用（decrementMptrRefs）
long oldVal = (long) sMptrRefCount.getAndAdd(this, -1L);
if (oldVal - 1 == MPTR_TEARDOWN_MASK) {
LockSupport.unpark(mLooperThread); // 我是最后一个活引用，且 looper 在等
}
// 与 wake 的协作
private void concurrentWake() {
if (incrementMptrRefs()) {
try { nativeWake(mPtr); }
finally { decrementMptrRefs(); }
}
}- 单消息存在性： Tombstone CAS(墓碑 CAS)，用一次 CAS 翻一个"已删除"标志位，而不是用锁去操作数据结构本身，保证消息的逻辑消失(真正能让消息消失的只有 looper 线程操作 min-heap)，同时保证不会触发多线程修改同一个列表的情况。
// 代码位置 MessageStack，所有线程都可以调用
public int moveMatchingToFreelist(Message.MessageCompare compare, Handler h, int what, Object object, Runnable r, long when) {
Message current = (Message) sTop.getAcquire(this);
Message prev = null;
Message firstRemoved = null;
int numRemoved = 0;
while (current != null) {
if (messageMatches(current, compare, h, what, object, r, when)
&& current.markRemoved()) {
if (firstRemoved == null) {
firstRemoved = current;
}
current.clearReferenceFields();
// nextFree links each to-be-removed message to the one processed before.
current.nextFree = prev;
prev = current;
numRemoved++;
}
current = current.next;
}
if (firstRemoved != null) {
Message freelist;
do {
freelist = mFreelistHeadValue;
firstRemoved.nextFree = freelist;
// prev points to the last to-be-removed message that was processed.
} while (!sFreelistHead.compareAndSet(this, freelist, prev));
}
return numRemoved;
}
// looper 准备派发的消息已被并发删除
if (found != null && !peek) {
if (!found.markRemoved()) {
continue; // 别人已经把它标记为删除，重新找下一条
}
mStack.remove(found);
}
// looper 线程
MessageStack.pop（looper 线程）：
if (!m.markRemoved()) {
return null; // 别人已经标记了，我让出
}- 生产者/消费者职责切分： 任何线程都可以进行 pushMessage、markRemoved、freelist 和 nativeWake 等操作，但是只有 looper 线程可以进行 min-heap、nativePollOnce 等操作，将整体职责全部分开，昂贵的结构维护工作集中到单线程中完成。
最后我们总结一下新的设计的整体流程: 拿插入序号(原子 getAndAdd，1 条 CPU 指令) -> 写消息字段(不用同步控制) -> mStack.pushMessage(Treiber stack CAS push。失败重试，平均 1–2 次 CAS) -> 唤醒决策循环(读 mWaitState，CAS 写新状态) -> 可能调 concurrentWake。完成整体 pushMessage 操作，全程没有 synchronized 关键字，最坏情况也只有几次 CAS retry，最快路径 0 次内核调用，大大减轻了系统负担。
整篇文章其实不止写了 lock-free 数据结构的设计，其余还有很多，比如 Treiber stack、比如如何利用双链表机制是让 Looper 在线程内高效地把某个节点从 stack 链中摘掉。还有 Google 如何利用 Perfetto 和 PerfettoSQL 进行大量的 trace 分析，确认问题以及修复问题后的验证。可以说这篇文章中的每一部分都可以拿出来单独写一篇比较好的操作指南针，也可以看出 Google 在针对 MessageQueue 的修改上是有多么的慎重，以及在这种多线程上的恐怖控制力，可以说这是一篇值得所有人反复阅读的文章。
🐕 SQLite: Vacuuming the WALs
@ChengzhiHuang: sqlite 是常见的端用存储，一般也都会辅以开启 Write-Ahead Logging(WAL) 模式提升性能。对于一些低存储用户，我们还会辅以开启 incremental_vacuum 定期整理 .-wal 文件进一步减少磁盘占用（注：直接使用 vacuum 是不被推荐的，但是如果数据库本身已经存在，则必须先执行一次完整的 vacuum 才能开启 incremental_vacuum，因此最好是新建的时候默认打开）。本文对 incremental_vacuum 进行了进一步的细分，研究了配置不同的阈值（每次清理的页数）下，整体数据库的表现。大家可以参考自己数据库的实际情况选择不同阈值分批 incremental_vacuum 。
同时提醒大家记得在 incremental_vacuum 完成后再手动进行 checkpoint 才能有效减少磁盘占用，不然只是缩小了 free pages 的数量。
🐕 A Small SwiftUI Warning and a Long Journey to Understand It
@阿权：本文作者在开启 Swift InferSendableFromCaptures（SE-0418）特性后，遇到 SwiftUI 导航修饰器传递视图构造器函数引用的 Actor 隔离警告的问题。根本原因是：警告只是 Swift 5 迁移模式下的一个产物，升级到 Swift 6 后并不是问题。怎么理解呢？
- Swift 5 迁移模式的限制：当我们启用一个“未来特性”标志（如
InferSendableFromCaptures）来提前测试 Swift 6 的行为时，它可能会暴露一些问题，但由于底层的检查模型仍是旧版的，所以会产生一些在最终模型中并不存在的“过渡性警告”。 - 理解编译模式的差异：在 Swift 6 模式下，编译器能全盘理解上下文并得出正确结论，所以代码直接通过。而在 Swift 5 模式下，它只看到了部分信息，从而发出了多余的警告。
如何去一步步找到问题的根因也是文章的重点，通过作者的探索也能给到我们一些开发实践的建议：
- 优先升级语言版本：如果项目条件允许，尽早将 Swift 语言版本升级到 Swift 6。这能让你获得最准确、最一致的并发检查体验。
- 深入理解并发模型：花时间去理解 Swift 并发模型的核心概念，如 Actor 隔离和上下文继承。这能让你在处理更复杂的并发问题时游刃有余。
- 审慎看待过渡期警告：当你使用
-enable-upcoming-feature等标志在旧语言模式下测试新特性时，要意识到看到的警告可能带有“过渡性”特征，需要结合最终的语言模型来理解其真正含义。 - 不满足于“能用”：在开发中，遇到一个修复方案时，多追问一句“为什么”，“为什么这样能解决问题”。这能帮助你真正理解问题本质，避免被表象解释所误导。
🐕 Lazy Properties in Swift - Why They Don't Always Work in SwiftUI
@Barney：这篇文章系统梳理了 Swift 里 lazy 属性的行为边界，重点不是语法本身，而是它在 SwiftUI 里的常见误用。作者先回顾了 lazy 适合解决的几类问题：延迟昂贵初始化、缓存只需计算一次的结果，以及依赖 self 的初始化；随后指出一个很容易踩的坑：SwiftUI 的 View 是值类型且会频繁重建，而 lazy 首次访问时需要发生写入，这使它既不适合作为稳定缓存，也无法直接放进 body 所依赖的视图属性里。文章给出的实践建议也很明确：在 SwiftUI 中优先用 @State、@StateObject 或对象持有者管理生命周期，把 lazy 留给 class、service、formatter 或计算代价较高的缓存对象。对经常在 SwiftUI 中做性能优化的同学很有参考价值。
🐎 A Reusable Spotlight Onboarding Component in SwiftUI
@DylanYang：作者基于 SwiftUI 的 PreferenceKey 与锚点系统，实现了一款可复用的引导组件，无需依赖 UIKit 即可完成视图高亮、圆角镂空遮罩、自适应提示卡片展示与多步骤平滑动画切换。该组件适配导航栈、滚动视图、安全区、弹窗等各类场景，通过 tutorialSpotlight modifier 和 tutorialSpotlightSource modifier 即可快速接入，还支持自定义高亮内边距、圆角、背景点击关闭等配置，能便捷搭建完整的界面引导流程。感兴趣的开发同学可以阅读下具体的实现过程。
🐎 SwiftPM: 2x faster resolves, 3x smaller disk footprint
@david-clang：SwiftPM 长期受限于 Git 全量克隆导致的解析缓慢与磁盘占用过大。受此影响的 Ordo One 公司提交了优化提案 (PR #9870)，通过引入源码归档下载路径实现大幅优化。该方案能保持 Public API 不变，且无需开发者修改 Package.swift 。其核心流程如下：
- 执行
git ls-remote --tags—— 发现可用版本（无新增 API，与现有机制一致）。 - 从 CDN 获取
Package.swift—— 检查工具版本（Tools Version）的兼容性。 - 从 GitHub CDN 直接下载 ZIP 压缩包 —— 提取源码，完全绕过 Git 克隆过程。
降级机制 ：
- 子模块 (Submodules)：降级为浅克隆。
- 流程异常 (如下载失败)：无缝回退至旧版全量克隆机制（
git clone --mirror）。
基准测试与性能收益：
- 测试方法：选取包含
swift-composable-architecture(TCA)、SwiftLint等不同规模（9 至 67 个依赖项）的知名开源项目。分别对比新旧方案在冷解析（清空.build与全局缓存，模拟 CI 环境）和热解析（保留全局共享缓存，模拟本地开发）下的耗时与磁盘增量。 - 解析提速：冷解析场景下速度最高提升约 2.1 倍；热解析场景下速度最高提升达 3.8 倍。
- 空间优化：因彻底免除本地 Git 历史数据的存储，
.build/目录的磁盘占用平均锐减 3 倍（例如，某重度依赖项目的体积由 1.8GB 缩减至约 600MB）。
内推
重新开始更新「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）