苹果的罕见妥协：当高危漏洞遇上“拒升”潮

对于 iOS 用户来说，最近或多或少都会看到与 Coruna、DarkSword 有关的高危漏洞消息。两个攻击链均采用水坑攻击的方式，攻击者无需受害者进行任何交互，仅需访问一个被植入恶意 iframe 的合法网站或加载恶意广告，即可触发完整的攻击链，在窃取资料后自动清理攻击痕迹。由于工具链利用的漏洞存在于 iOS 13 至 18.7 的绝大多数版本中，截至目前，已有上亿用户受到影响。

Coruna 主要针对 iOS 13 至 iOS 17 的设备，在过去几个月间，苹果已为这些系统推送了多次安全更新。DarkSword 则主要针对 iOS 18.4 至 18.7 的设备。尽管这部分设备均具备升级至 iOS 26 的硬件条件，但由于种种原因，仍有不少 iOS 18 用户选择按兵不动。

在很长一段时间里，苹果用户对于系统更新的态度都相当积极，这也是苹果生态的一大特色。但这一趋势在去年出现了变化——Liquid Glass 带来的巨大视觉冲击，让苹果用户中第一次出现了相当比例主动拒绝升级到 iOS 26 的现象。与此同时，为遵守英国《网络安全法》（Online Safety Act）的要求，苹果在 iOS 26.4 中为英国用户引入了强制年龄验证机制，由于验证条件严苛，不少成年用户甚至被系统强行锁入‘儿童模式’，进一步推动了英国用户停留在 iOS 18 或 iOS 26.3 的风潮。而拒绝安装新版本，意味着这部分用户同时放弃了后续所有安全补丁，让设备进一步暴露在潜在风险之下。

面对这一局面，苹果承受了明显的舆论压力与品牌风险。特别是在 3 月下旬，DarkSword 的完整攻击代码被泄露到了 GitHub 上，让这一国家级黑客工具瞬间平民化，直接迫使苹果必须采取紧急行动。最终，苹果罕见地为 iOS 18 单独推出了安全补丁 iOS 18.7.7，将原本仅用于 iOS 26 的防护机制回移植到旧系统。至此，苹果完成了针对本次高危漏洞的全部官方安全响应。

无论是苹果还是生态中的开发者，大多希望用户能积极跟进系统更新——既能减少多版本适配的维护负担，也能让用户尽快享受到新 API 带来的便利。但现实是，始终有一部分用户出于性能、续航、使用习惯乃至隐私等方面的考量，有意将设备锁定在某个版本。

本次事件或许会带来两个方向上的变化：苹果在压力下调整了长期坚守的更新策略，为刻意留守旧系统的用户做出了妥协；而事件本身的广泛传播，也可能促使更多用户从安全角度重新审视“能不更新就不更新”的惯性，回到积极更新的轨道。这种双向的改变，或许正是这场风波意料之外的收获。

本期内容 | 前一期内容 | 全部周报列表

近期推荐

通过 Animatable 深入 SwiftUI 动画 (Animatable in SwiftUI Explained - Complete Guide with Examples & Deep Dive)

网络上并不缺少探讨 SwiftUI 动画机制的文章，但 Sagar Unagar的这篇仍然提供了一个颇具启发性的切入点。他没有从隐式或显式动画入手，而是围绕 Animatable 协议做了一次系统梳理：从 animatableData 的作用，到 AnimatablePair 如何承载多个插值参数，再到通过自定义 VectorArithmetic 让更复杂的数据结构参与动画。文章最值得注意的一点在于其核心视角：SwiftUI 实际上是在“动画数据”，而非直接对视图进行动画处理。

---

在 Swift Package 中共享本地化资源 (Localization in Swift Packages)

Xcode 能为 .xcstrings 文件自动生成类型安全的 Swift 符号，但这些符号仅在资源所在的 module 内可见——一旦将本地化资源抽离为独立的 Localization 包，其他 feature 包便无法享受编译期检查的优势。Khan Winter 的解决方案相当直接：通过一个 bash 脚本解析 .xcstrings 的 JSON 结构，生成 public extension LocalizedStringResource 扩展，使所有模块都能以 .l10n.helloWorld 的形式访问翻译键。

其中一个颇具参考价值的细节是 Debug 模式下的 @dynamicMemberLookup 设计——访问不存在的键时仅记录日志而不崩溃，而在 Release 构建中仍保留完整的编译期校验。相比基于 Swift 可执行文件的方案，这种实现更加轻量，复制脚本即可使用。

---

Coordinator 全局导航模式 (SwiftUI Coordinator Pattern: Navigation Without NavigationLink)

尽管 SwiftUI 一直在丰富基于状态驱动的导航 API，但管理全局导航一直是 SwiftUI 中的一个“痛点”。Wesley Matlock 以一个五 Tab 的音乐收藏应用为例，展示了如何通过 Coordinator 模式将导航决策从 View 中抽离：用一个 Route 枚举统一描述所有目的地，由单一的 Coordinator 对象持有导航状态并执行跳转，View 只需声明“去哪”而无需关心“怎么去”。文章没有回避 NavigationPath 不透明、路由携带模型对象导致的 Hashable 困境等实际问题。对于大多数中等规模的 SwiftUI 应用来说，这是一个务实且易于落地的导航治理方案。

---

把 Hacking with Swift 的编程风格写进 AI (Teach your AI to write Swift the Hacking with Swift way)

Paul Hudson 和他的 Hacking with Swift 让很多开发者走上了 Swift 与 SwiftUI 的学习之路。在 AI 时代，Paul 不仅推出了面向苹果开发生态的各类专业 Skill，也开始尝试在与 AI 的协作中注入更具个人特质的编程风格。

在本文中，他分享了一份极具辨识度（且充满他标志性幽默）的 AGENTS.md 配置。这套规则不仅约束了 AI 的技术选型，还为 AI 注入了 Paul 的灵魂：强调先展示结果再解释原理、偏好清晰而非炫技、甚至包括在代码写得漂亮时适时地喊出一句 "Boom!"。与其说这是一份用于 AI 的“系统提示词”，不如说是在为 AI 定义一种编码哲学——某种程度上，这种方式正在将冷冰冰的“代码生成”推向带有人情味的“风格迁移”。

---

AI Agent 的道与术

在刚过去的 Let's Vision 2026 中，王巍（Onevcat） 发表了关于在大型开发团队中应用 AI Agent 的演讲。整场分享讨论的重点，并不是某个具体工具有多强，而是当代码实现成本被迅速压低后，团队该如何重新组织开发流程，以及工程师的价值该如何重新定位。

作为 LINE 应用开发团队的一员，Onevcat 在过去几个月中的工作重心也已明显发生变化。用他自己的话说，他正在逐步从传统意义上的 iOS 工程师，转向探索如何将 AI 应用于服务大型产品研发团队的实践者。这种角色上的变化，也让这场分享比一般的工具介绍更有说服力。

演讲围绕三个关键问题展开：如何控制上下文污染，如何把个人经验沉淀为团队可复用的 memory 与 skill，以及如何让协作模式从“人指挥多个 Agent”逐步走向更自动化的闭环。里面有不少相当接地气的实践建议，例如将 AGENTS.md 控制在精简范围内、为 Agent 提供模块定位与架构速查脚本、鼓励 Claude Code、Codex、OpenCode 等多种 harness 并存，以及通过 webhook、cron、pipeline 和自动验收机制让 Agent 真正进入团队流程。

演讲稿仓库 中不仅包含完整的 Slidev 源码，也保留了不少演讲配套材料，包括原始资料收集和与 AI 协作的完整 trace，值得一并阅读。

---

从零开始：用 AI 开发一个 iOS 原生 APP 完整指南

我经常会在社交媒体上看到一些零基础的“开发者”通过 AI 构建了自己的产品或服务。尽管我使用 AI 的时间也不短，但我仍然比较困惑：这条路径真的像大家描述的那样有效吗？Zachary Zhang 分享了他完全借助 AI 工具，从零构建并上架一款纯原生 iOS 应用（SwiftUI + Cloudflare 后端）的实战全过程。这篇文章最让我印象深刻的，是他严谨的“工程化管线”：在让 AI 写代码前，必须先生成结构化的 PRD 和 HTML 格式的视觉参考；而在工具选择上，他在项目“从 0 到 1”的冷启动阶段，极力推荐 Claude Code 等终端工具，以便更好地统览全局，一次性构建出合理的多文件项目架构。

或许你和我一样，对于 100% 基于 AI 的开发方式仍存疑惑。但在代码生成越来越廉价的今天，开发者的核心壁垒，正在加速向“需求精准拆解”、“系统架构把控”以及“面向报错的全局调度能力”转移。

工具

Slots：提高自定义 SwiftUI 组件设计效率的宏

将多个视图组合封装成可复用组件，是 SwiftUI 开发中的常见需求，对团队内部开发者或第三方库作者来说更是如此。但当组件包 title、icon、image、action 等多个泛型 View 插槽后，初始化器的组合数量往往会迅速膨胀。Kyle Bashour 创建的 Slots 宏，正是为了解决这类多 slot 组件的样板代码问题。

开发者只需声明组件的 slot 属性，宏便会按组合自动生成所需的初始化器，无需手写大量 init 重载。对于需要支持文本便捷写法的 slot，还可以通过 @Slot(.text) 自动获得 LocalizedStringKey 和 String 版本的初始化方式。 Slots 很适合用于构建设计系统中的 Card、Row、Banner、Toolbar 这类既要支持简单调用、又要保留高度定制能力的组件。

---

Explore SwiftUI：纯原生组件与修饰符的视觉速查图库

尽管 Apple 官方文档的质量在逐年改善，但对于以声明式和视觉驱动为主的 SwiftUI 来说，官方文档中依然缺乏足够直观的代码与 UI 效果对照，尤其是同一组件在 iOS、macOS 和 visionOS 等多平台上的表现差异。很多时候，开发者为了实现某个特定的 UI 细节，往往会去求助于复杂的第三方库或手写冗长的自定义视图，却忽略了 SwiftUI 本身可能已经提供了绝佳的原生解决方案。Florian 建立的 Explore SwiftUI 站点，正是一个为了解决这一痛点而生的“视觉速查字典”。它摒弃了任何第三方封装，纯粹以展示 Apple 官方内置组件的原生能力为核心。所有的代码示例都被剥离了无关的业务逻辑，保持极简，配以高质量的视觉预览，开发者只需“复制、粘贴、运行”即可直接验证效果。

书籍

SwiftUI Architecture: Patterns and Practices for Building Scalable Applications

这是一本 Mohammad Azam 在不久前出版的新书。它不是一本教你如何使用 VStack 或编写动画的入门书，而是一本纯粹探讨 SwiftUI 应用架构、数据流和现代工程化实践的进阶读物。

书中提供了大量直击生产环境痛点的解决方案，例如：如何构建全局的 Sheets 和 Toasts、如何利用 NavigationPath 设计解耦的多 Tab 编程式路由、以及如何使用 Property Wrapper 编写优雅的表单验证。尤为重要的是，作者并不是要向你灌输某种死板的架构模式，而是旨在帮助你建立真正的声明式心智模型。

或许有人觉得，在 AI 辅助编程盛行的时代，这类探讨架构的书籍还重要吗？借用 Mohammad Azam 在书中的观点：AI 让代码生成变得廉价，但也正因如此，系统架构的设计（边界的划分和状态所有权的明确）变得比以往任何时候都更加重要。

往期内容

• 一墙之隔，不同的时空 - #129
• 我的 App 审核被卡了？ - #128
• 50 岁的苹果和 51 岁的我- #127
• Macbook Neo：苹果重回校园的起点 - #126

💝 支持与反馈

如果本期周报对你有帮助，请：

• 👍 点赞 - 让更多开发者看到
• 💬 评论 - 分享你的看法或问题
• 🔄 转发 - 帮助同行共同成长

---

🚀 拓展 Swift 视野

• 📮 邮件订阅 | weekly.fatbobman.com 获取独家技术洞察
• 👥 开发者社区 | Discord 实时交流开发经验
• 📚 原创教程 | fatbobman.com 学习 Swift/SwiftUI 最佳实践

一墙之隔，不同的时空

一年一度的 Let's Vision 大会在上海如期举行，今年的主题是：“Born to Create, Powered by AI”。除了与 Swift、空间计算相关的常规 Session，大会还邀请了许多开发者分享他们在工作中对 AI 的应用与理解。通过这些讲师对 AI 工作流的介绍，我也受益匪浅。原本只能容纳 300 人的 AI 主题会场，里三层外三层站满了热情高涨的观众。

然而，在众多优秀的 Session 中，一场由 YuChe Cheng 准备的、名为《Let's Create 1-liner Code in Swift》的演讲却将我的注意力引向了另一个会场。这究竟是一个怎样的话题？带着疑问我走了进去。作为一个 LeetCode 积分 2200+ 的开发者，YuChe Cheng 在演讲中展示了如何通过 Foundation 以及 Swift Algorithms 提供的大量高阶函数，将原本平淡无奇的 For-loop 代码，转换成更加优雅、美观、极具 Swift 风格的 Function Chaining（1-liner code），并在易读性与性能之间取得了很好的平衡。

看着幻灯片上的 Function Chaining 被一次又一次地优雅迭代，我有种茅塞顿开的畅快。整整 30 分钟的演讲，让我始终处于一种纯粹的兴奋之中——这种感觉，通常只在我绞尽脑汁最终攻克了一个难题，或是深刻理解了一个新概念后才会涌现。

尽管与主会场只有一墙之隔，但由于 AI 话题的绝对热度，本场演讲的听众明显偏少。与其说我为许多人错失了一场精彩演讲而感到遗憾，我真正担心的其实是：随着 AI 的进一步渗透，许多开发者原本在追求功能之外所赋予代码的那份“气质”，会不会就此消亡？

开发者不应该只关心编译后冷冰冰的二进制功能，代码本身也是个人风格的载体。它就像文章一样，在输出逻辑与结果之外，还承载着美学表达，体现着编写者的个人品味与巧思。

在今年的 Let's Vision 上，我感觉我们正站在一个时间的十字路口：我们是该一味追求 AI 带来的极致高效，还是在拥抱变化的同时，依然让属于开发者的那份骄傲与手艺，在 AI 时代得以保留？

本期内容 | 前一期内容 | 全部周报列表

本期推荐

Swift 6.3 Released

从 Swift 6 开始，语言演进已经稳定在半年一个 minor 版本的节奏，上周 Swift 6.3 如期发布。与前几个版本相比，这一版本并未引入明显的重磅特性，更多是对既有体系的打磨：并发模型在诊断准确性方面有所改进，新增的 @c 特性（attribute）进一步强化了 C/C++ 互操作能力，同时编译优化的控制粒度也变得更加细致。

尽管如此，这一版本也释放出一个清晰的信号：Swift 正在从“以 Apple 平台为中心的应用开发语言”，逐步向“具备跨平台与系统级能力的通用语言”演进。Embedded Swift、Android 支持的持续推进，以及 SwiftPM 构建体系的统一，都在指向这一方向。对多数 iOS 开发者而言，短期体感或许有限，但从更长的时间维度来看，这更像是一次为未来铺路的基础性更新。

---

如何在 Swift 中承接尚未稳定的 JSON (Designing a type-driven JSON in Swift)

当 API 契约尚未稳定、前后端对字段的理解又经常漂移时，Swift 的强类型系统反而会放大数据与 JSON 之间转换时的边界问题。Roman Niekipielov 在本文中介绍了一个刻意做小的 JSONValue 类型，用来承接这类过渡阶段的 JSON 数据。相比 [String: Any]，它保留了更明确的类型结构；相比直接编写 Codable 模型，又更适合应对频繁变化的契约。这个实现并不试图替代正式模型，而是将不确定性暂时限制在边界层。

---

Swift 原生 AI Agent 开发实践系列

市面上有大量开发者使用 Python、TypeScript 开发 AI Agent，但 Chris Karani 认为，Swift 的并发模型天然更适合 Agent 的隔离与调度，强类型系统和宏功能也带来了额外的安全保证。他用 6 篇文章、从多个角度实践了这一观点——从统一多个 LLM Provider 的 SDK Conduit，到基于 Apple Foundation Models 的 Agent 运行时 Colony，再到用 Metal 加速的上下文记忆管理。如果你正在考虑在 Apple 平台上构建 AI 功能，这个系列是目前少见的完整原生方案。

---

Liquid Glass 设计工作坊 (Talking Liquid Glass with Apple)

Danny Bolella 在纽约参加了苹果举办的 Liquid Glass 设计工作坊，与设计团队和 SwiftUI 工程师进行了为期三天的深入交流。本次活动传递出非常明确的信号：Liquid Glass 并非过渡性尝试，而是苹果未来数年的设计方向，且将在后续工具链中成为默认前提。与此同时，苹果反复强调“层级（Hierarchy）”的重要性——界面应围绕内容构建，控件只是服务于内容的辅助元素，应尽量退居边缘，让信息本身成为视觉与交互的中心。除此之外，Danny 还在本文中记录了其他一些 SwiftUI 工程师给出的建议和技巧。本文记录的内容可以帮助你更早理解这场设计演进的节奏与方向。

---

App Store Connect 大更新 (Apple Dropped 100+ New Metrics. Your Competitors Are Already Using Them)

苹果对 App Store Connect 进行了近年来最大的一次更新，一口气引入了 100+ 官方指标、按来源划分的 cohort 分析、同行基准对比（转化率与单下载收益）以及可通过 API 导出的订阅数据。Jessica Chung 在本文中对这些关键变化进行了系统梳理。由于所有数据均来自苹果一手统计，这意味着开发者在 ASO 和增长决策中，将不再依赖第三方估算，而可以直接基于真实用户行为进行分析与优化。更重要的是，这次更新补齐了长期缺失的关键能力：你可以追踪不同关键词与渠道带来的用户质量，建立从曝光、下载到订阅与续费的完整转化链路，并通过同行基准明确自身所处位置。

本次更新对于开发者而言无疑是利好，但对于部分第三方 App Store 分析服务来说，也在一定程度上提高了竞争门槛，促使其提供更具附加值的能力。

---

Package Traits in Xcode

在创建 SPM 时，某些依赖可能只被特定 API 使用，但一旦用户引入该包，即便不使用这些 API，也需要一并引入相关依赖。Package Traits 正是为了解决这一问题而引入的，它为 SPM 提供了一种声明可选特性的方式，使使用者能够按需启用功能，从而避免引入不必要的依赖。遗憾的是，在该功能推出后，一直只能在社区版本的 Swift 工具链中使用。随着 Xcode 26.4 的发布，Package Traits 终于获得了苹果官方支持，有望迎来更广泛的应用。Matt Massicotte 在本文中对该特性进行了介绍，并展示了其基本用法。

---

优化感官性能，让用户感觉更快 (Why your SwiftUI app feels slow even though Instruments says it’s fine?)

用户投诉响应慢，一定是应用性能问题吗？Rafał Dubiel 将关注点从“实际性能”转向“感知性能（Perceived Performance)”，讨论如何通过界面反馈与交互节奏，让用户感觉应用“更快”。例如通过 skeleton view、延迟加载，以及合理的动画与状态过渡来掩盖等待时间。作者指出，在许多场景下，用户体验的关键并不在于减少毫秒级的计算时间，而在于是否及时提供反馈。相比单纯优化性能指标，这种从用户感知出发的思路，往往更直接地影响用户对应用流畅度的判断。

---

在 SwiftUI 中控制行高 (Adjusting line height in SwiftUI on iOS 26)

iOS 26 为 SwiftUI 新增了 lineHeight(_:) modifier，用于控制文本相邻两行基线之间的距离。Natalia Panferova 在本文中对各种配置方式进行了详细对比：内置预设（.loose、.tight）、基于字号倍数的 .multiple(factor:)、固定增量的 .leading(increase:)，以及绝对值控制的 .exact(points:)。此外，lineHeight(_:) 与已有的 lineSpacing(_:) 并不相同：前者控制基线间距，后者控制行底到下一行行顶的距离。

Natalia Panferova 曾是 Apple SwiftUI 核心团队成员，参与过多个关键 API 的设计与开发。本月她刚刚出版了新书 The SwiftUI Way，面向有一定 SwiftUI 经验的开发者，聚焦于生产环境中的模式选择、常见反模式识别，以及如何与框架“顺势而为”而非对抗。

工具

Cove：Swift 6 编写的 macOS 开源数据库客户端

Cove 是由 Emanuele Micheletti 开发的一款原生 macOS 数据库客户端，整个项目完全使用 Swift 6 构建，目前已经支持 PostgreSQL、MySQL、MariaDB、SQLite、MongoDB、Redis、ScyllaDB、Cassandra 和 Elasticsearch 等多种后端。它采用 SwiftUI 搭配 AppKit 原生控件实现，没有走 Electron 或 Web 技术栈，因此整体更轻量，也更符合 macOS 用户熟悉的交互体验。

相比“又一个数据库 GUI”，Cove 更值得关注的是它的实现思路。作者将所有数据库能力统一抽象为 DatabaseBackend 协议，UI 层不包含任何针对特定后端的分支逻辑。无论是 SQL 数据库、Redis 这类键值数据库，还是 MongoDB、Elasticsearch 这类非关系型后端，最终都会被整理为统一的表格模型交由界面渲染。项目目前仍处于 v0.1.0 的早期阶段，但已经具备查询、结构浏览、编辑、SSH 隧道和多标签等基础能力。即便你并不打算把它作为日常数据库工具，Cove 依然是一个很值得 Swift 开发者研究的桌面应用架构样本。

往期内容

• 我的 App 审核被卡了？ - #128
• 50 岁的苹果和 51 岁的我- #127
• Macbook Neo：苹果重回校园的起点 - #126
• OpenClaw 不错，但我好像没有那么需要 - #125

💝 支持与反馈

如果本期周报对你有帮助，请：

• 👍 点赞 - 让更多开发者看到
• 💬 评论 - 分享你的看法或问题
• 🔄 转发 - 帮助同行共同成长

---

🚀 拓展 Swift 视野

• 📮 邮件订阅 | weekly.fatbobman.com 获取独家技术洞察
• 👥 开发者社区 | Discord 实时交流开发经验
• 📚 原创教程 | fatbobman.com 学习 Swift/SwiftUI 最佳实践

我的 App 审核被卡了？

上周四，我 Discord 社区里的一位网友抱怨，说他的应用在 App Store Connect 上提交了四五天，却迟迟没有进入审核状态。就在我还津津有味地跟大伙儿分析原因时，突然心里一紧：我周一提交的应用，好像也一直没收到审核动态？

有网友建议我去申请一下“加急审核”。可当我点进页面时，系统却提示我“没有可加急的应用”。仔细一查才发现，原来是太久没更新 App，业务都生疏了——我的应用虽然完成了所有前置步骤，但我压根儿就没点那个“提交以供审核”的按钮。

补点按钮没过几个小时，应用就顺利上架了。

尽管我这纯属虚惊一场，但最近社区里关于“苹果审核变慢”的讨论确实多了起来。很多人猜测，这或许与近期 Vibe Coding 的盛行有关。虽然没有官方证实，但 Vibe Coding 确实在降低开发门槛的同时，也在短时间内放大了应用提交的数量与迭代频率，从而把压力传导到了审核环节。

事实上，苹果最近也确实对 Replit 这类允许普通用户进行 Vibe Coding 的应用在审核上进行了卡关。即便允许其上架，也要求在核心功能上做出妥协。在 Michael Tsai 关于此事的博客介绍中，我看到了一条非常敏锐的留言：

这些提供 Vibe Coding 功能的应用（本身也是 Vibe Code 的产物），正被用来批量制造纯靠 Vibe Code 生成的 App 并提交上架。

AI 不仅在重塑开发方式，也正在对应用审核与发行体系提出新的挑战。有人或许会问：如果用魔法打败魔法，让 AI 也全面接管审核流程，会不会更高效？

苹果的审核机制向来不够透明，有时候应用能否顺利过审，甚至取决于是否“碰巧”遇到一位气味相投的审核员。但换个角度看，至少“人”仍然是这道防线中最重要的一环。人的判断会出错，也会带有偏差，但在面对规则时仍保有一定的弹性。

我不希望，未来的软件生态，走向“AI 开发 -> AI 审核”的闭环。

本期内容 | 前一期内容 | 全部周报列表

原创

CDE：一次让 Core Data 更像现代 Swift 的尝试

在 上周的文章 中，我聊了聊 Core Data 在当下项目中的一些现实处境：它并没有消失，也仍然有其独特价值，但它和现代 Swift 项目之间的错位感却越来越明显。在本文中，我想继续顺着这个问题往下走，介绍我的一个实验性项目：Core Data Evolution（CDE）。

它不是一个取代 Core Data 的新框架，也不是要把开发者重新拉回旧技术。更准确地说，它是我面对这些错位时，给自己的一种回答：如果我仍然认可 Core Data 的对象图模型、迁移体系和成熟运行时能力，那么能不能让它在现代 Swift 项目中以一种更自然的方式继续存在下去？

近期推荐

实现平滑的 SwiftUI List 展开动画 (Expanding Animations in SwiftUI Lists)

开发者经常会遇到一个动画窘境：在动态调整 List 中某一行高度时，内容并不是平滑展开，而是伴随着明显的高度跳变。在本文中，Pavel Zak 通过几个实验，展示了为什么常见的 if 条件渲染、withAnimation 甚至 .transition 在 List 中都难以达到理想效果。尽管 DisclosureGroup 这种内建方案可以达到预期，但 Pavel 还是给出了一个更灵活的方案：基于 Animatable 与视图尺寸测量的实现方式，让 List 在动画过程中始终获得连续变化的高度，从而实现平滑的展开动画。

List（底层仍然是 UIKit/AppKit 的列表实现）有一个核心特点：它需要在布局阶段就拿到每一行的“确定高度”。因此，对开发者来说，不要让 List 面对结构变化，而是像 DisclosureGroup 那样，将“离散变化”转化为“连续变化”，持续提供可插值的高度值。这也是在处理动画异常时，开发者常常借助 Animatable 协议的原因。想进一步了解该协议的原理与适用场景，可以阅读我之前的一篇文章。

---

如何更好的适配 iPadOS 的布局 (SwiftUI iPad Adaptive Layout: Five Layers for Apps That Don’t Break in Split View)

尽管苹果强化 iPadOS 多窗口能力的初衷是好的，但这也显著提升了开发者在布局适配上的复杂度。应用可能以类 iPhone、传统 iPad 全屏、Stage Manager 窗口等多种模式呈现。Wesley Matlock 指出，仅依赖 horizontalSizeClass 进行布局判断在实际环境中往往是不够的。开发者需要结合容器尺寸与 size class 构建更细粒度的 LayoutEnvironment，并在根视图中统一完成布局分支决策；同时借助 ViewThatFits 等机制，让系统基于真实约束选择最合适的界面形式，而不是由开发者预先假设设备类型。

---

RGB HDR Gain Map + ImageIO 中的使用陷阱 (Pitfalls and workarounds when dealing with RGB HDR Gain Map using ImageIO)

iOS 18 中引入的基于 ISO 21496-1 标准的 RGB HDR Gain Map，让开发者在处理 HDR 图像时获得了更高的表现力，但在实际应用中也更容易踩坑：尽管相关接口能够返回辅助数据字典，但在 RGB Gain Map 场景下却缺失了实际的位图数据（kCGImageAuxiliaryDataInfoData），导致后续处理无法继续。换句话说，ImageIO 在这一场景下甚至无法完整读取自身生成的内容。Weichao Deng 提出了一种混合方案：使用 Core Image 读取 Gain Map 的 CIImage，手动渲染为 Bitmap Data，补齐缺失字段后，再通过 ImageIO 写回文件。对于正在开发相机或图像处理类应用、需要处理 HDR Gain Map 的开发者来说，这篇文章或许能帮你省下不少调试时间。

---

Swift 社区的网络愿景 (A Vision for Networking in Swift)

Swift Ecosystem Steering Group 上周发布了一份关于网络编程的愿景文档，讨论了 Swift 网络生态当前的困境以及未来可能的发展方向。

文档指出，Swift 在网络领域存在明显的分裂：URLSession、SwiftNIO 与 Network.framework 并存，功能重叠却互不兼容，开发者往往需要在项目早期就押注某一套技术栈，且切换成本极高。与此同时，现有的大多数网络 API 都诞生于 Swift Concurrency 之前，依赖 completion handler、delegate 或响应式模式，与现代 Swift 的语言特性存在明显脱节。

文档提出的方向是构建一套分层统一的网络架构：底层共享 I/O 原语与缓冲类型，中间层复用 TLS、HTTP/1.1/2/3、QUIC、WebSocket 等协议实现，顶层提供以 async/await 和结构化并发为基础的客户端与服务端 API。已有的 swift-http-types（定义了 HTTPRequest / HTTPResponse）可以视为这一思路的早期实践。文档同时强调，SwiftNIO 和 Network.framework 不会被废弃，而是将逐步向统一的底层原语收敛。

该愿景目前正在征集社区反馈，可以在此参与。

---

让你的 iOS 项目更适合 AI 协作 (Preparing Your iOS Codebase for AI Agents)

随着 AI agent（如 Codex、Claude Code 等）逐渐参与到实际开发流程中，问题开始从“如何使用 AI 写代码”转向“如何让代码库本身适合 AI 协作”。Hesham Salman 从工程实践的角度，系统性地探讨了这一转变。

Hesham 指出，相较于提示词，AI 更依赖显式契约。通过分层的 AGENTS.md 文档明确项目约定与行为规则，使用 Makefile 将构建、测试等操作统一为可执行入口，并通过“skills”将多步骤流程编码为可复用的执行方法，从而将原本隐性的工程知识结构化地嵌入到代码库中。

文章中有一个细节令人印象深刻：作者要求 agent 在发现未记录的约定时主动更新文档，同时加入了一条强约束——每次修改都必须让文档更短或更有用。这一自维护机制既防止文档腐化，也避免文档膨胀，是一个值得借鉴的平衡策略。

---

iOS Conf SG 2026 视频

2026 年 iOS Conf SG 于 1 月 21 日至 23 日在新加坡举行，来自全球的数十位开发者与内容创作者分享了各自在苹果生态开发中的经验与思考。上周，官方放出了本届的全部演讲视频。我也有幸参与了其中的一场分享，感兴趣的读者可以按需挑选观看。

工具

TaskGate：解决 Actor 重入的工具

尽管 actor 在很大程度上避免了数据竞争，但其可重入（reentrancy）特性也意味着，一些看似串行的逻辑在 await 之后可能失去原有的执行顺序，进而造成重复执行或状态不一致。

Matt Massicotte 编写的 TaskGate 正是为这类场景准备的。它提供了 AsyncGate 和 AsyncRecursiveGate 两种机制，用来为 actor 内部的异步代码定义“临界区”，确保同一时间只有一个任务能够进入相关逻辑。与传统锁不同的是，它允许在持有 gate 的同时安全地执行异步调用。

Matt 明确指出：该库并不是用来替代良好的 actor 设计，而更像是一种在其他手段不够合适时的补充工具。库中将 gate 刻意设计为 non-Sendable，以降低跨 actor 误用的风险。如果你正在处理 actor 重入导致的状态一致性问题，或希望更深入理解 Swift 并发中的这一薄弱环节，这个库以及 Matt 在 Reddit 中的 讨论 都值得一看。

---

pico-bare-swift

苹果当年创建 Swift 时，对它的期待显然不只是用于开发 App，而是希望它最终成长为一门适用于不同领域、不同层次的通用语言。不过，在相当长一段时间里，Swift 在那些传统上由 C/C++ 或 Rust 主导的领域中，始终没有展现出足够的存在感。kishikawa katsumi 通过这个示例项目展示了另一种可能：借助 Embedded Swift，Swift 已经开始具备进入嵌入式开发场景的能力。

这个项目最吸引我的地方，在于它将一件原本带有明显“底层/C 语言专属”色彩的事情，组织成了一条相当清晰的学习路径。它不仅是“用 Swift 点亮一个 LED”，而是将启动代码、向量表、内存初始化、寄存器访问，以及 UART、PWM、I2C、SSD1306 OLED 等外设驱动一并纳入 Swift 的实现范围之中。某种程度上，这类项目的意义不在于“是否实用”，而在于它重新划定了 Swift 的能力边界。

往期内容

• 50 岁的苹果和 51 岁的我- #127
• Macbook Neo：苹果重回校园的起点 - #126
• OpenClaw 不错，但我好像没有那么需要 - #125
• 春晚、机器人、AI 与 LLM - #124

💝 支持与反馈

如果本期周报对你有帮助，请：

• 👍 点赞 - 让更多开发者看到
• 💬 评论 - 分享你的看法或问题
• 🔄 转发 - 帮助同行共同成长

---

🚀 拓展 Swift 视野

• 📮 邮件订阅 | weekly.fatbobman.com 获取独家技术洞察
• 👥 开发者社区 | Discord 实时交流开发经验
• 📚 原创教程 | fatbobman.com 学习 Swift/SwiftUI 最佳实践

50 岁的苹果和 51 岁的我

再有不到半个月，Apple 将迎来 50 岁生日。Tim Cook 也发表了一篇短文，致敬过去半个世纪的历程。不过，由于苹果一直以来始终引领潮流的形象，很多人并没有意识到它已经是 IT 产业中名副其实的元老。与它年龄相当的 IT 巨头，如今仍留在一线牌桌上的寥寥无几。

作为一个只比苹果大一岁的科技爱好者，从 Apple II 到如今的 iPhone、MacBook，苹果的产品几乎伴随我走过了大半人生。严格来说，我并不算真正的果粉——不会因为没能第一时间买到新品而遗憾，也几乎不再熬夜看发布会，更说不出新产品的具体参数。但回顾过去，在每一个人生节点上，我都会很自然地选择苹果的产品，并在近几年成为了苹果开发生态中的一员。

其实我也没有完全想明白，苹果对我持久的吸引力究竟来自哪里。是因为很早就开始使用它的产品？是它的创新、体验和气质？还是 Jobs 的人格魅力？说实话，如今的选择已经完全出于习惯和本能，就像老友间的默契，早已不需要什么特别的理由。

当然，苹果的成长之路并非一帆风顺，其间也有过低谷。但有一点必须承认：它在过去 50 年间的企业定位几乎没变——为个人和社会创造强大的工具。即便在最新一轮 AI 浪潮中，苹果看似失去了先机，但作为连接人与数字世界的“最后一厘米”的核心参与者，它仍然具备在 AI 时代留在牌桌中央的资本。毕竟，我们生活在物质世界中，需要实打实的硬件设备和个人化服务来享受技术进步的成果。

50 岁的苹果或许能给更多企业带来启示：与其模仿它“炫酷”、“创新”的外表，不如学习它的专注与坚持。成为与用户长久互相陪伴的伙伴，或许才是它成功的真正密码。

大概率再过十年，当苹果 60 岁、我 61 岁的时候，我仍然用着一台苹果电脑。

生日快乐，苹果！

本期内容 | 前一期内容 | 全部周报列表

原创

2026 年，为什么我仍在思考 Core Data

到 2026 年，Core Data 已经问世 21 年，尽管仍有不少开发者在使用它，但在今天的 Swift 项目里，它越来越像个“时代遗留”。并发得靠 perform 一层层套，模型声明堆满样板代码，字符串谓词随时等你踩坑。这篇文章不是要为 Core Data 辩护，也不是要说服新的开发者回到 Core Data。它更像是一篇问题整理：在 2026 年，为什么仍有人坚持使用 Core Data；而如果要继续使用它，我们今天真正需要解决的问题又是什么。

近期推荐

原生 AI 聊天应用 — 极速、隐私优先、100+ 专业功能

一个原生应用，100+ AI 模型，支持 Mac、iOS 和 Android。极速响应、键盘驱动、非 Electron。使用码 FATBOBMAN25 立享 25% OFF。

---

苹果工程师谈应用安全与内存保护 (Fortify Your App: Essential Strategies to Strengthen Security Q&A)

在苹果开发者中心举办的一场安全专题活动中，多位苹果工程师围绕应用安全与内存安全进行了近六小时的分享与问答，内容涵盖现代应用面临的安全挑战，以及 Apple 平台提供的一系列防护技术。Anton Gubarenko 将这场活动中的大量开发者问答整理成文，讨论了第三方库安全评估、UserDefaults 与 plist 数据存储的风险、Keychain 与文件保护策略、Swift unsafe API 的使用边界，以及如何在 Xcode 中启用 Enhanced Security 等能力。对于希望了解 Apple 平台安全机制与实践建议的开发者来说，这是一份信息密度很高的问答整理，其中包含不少来自苹果工程师的一手信息。

---

用 CLI 与 MCP 自动化配置 iOS 订阅 (Faster iOS Subscriptions with ASC CLI and RevenueCat MCP)

为应用添加订阅功能本身并不复杂，但在 App Store Connect 与 RevenueCat 两个后台之间来回配置，过程往往相当繁琐。Rudrank Riyam 介绍了一种更高效的做法：使用 ASC CLI 在终端中一次性创建订阅产品，再让 AI 代理通过 RevenueCat 的 MCP Server 自动完成 entitlements、offerings 与 paywall 的配置，从而将原本依赖控制台点击的流程迁移到 CLI + AI Agent 的自动化工作流中。

---

JetBrains 面向 Swift 开发者的调查 (JetBrains Swift Developers Survey)

JetBrains 最近发布了一份面向 Swift 开发者的调研问卷，邀请开发者分享当前使用的开发工具、工作流程以及在 Swift 生态中的痛点。尽管官方并未说明调研的具体用途，但社区中已经出现不少猜测：这项调查可能与 JetBrains 重新评估 Swift 开发工具支持有关。

在 JetBrains 于 2022 年宣布停止维护 AppCode 之后，Swift 开发者基本回到了以 Xcode 为核心的工具链。此次调研也引发了一些讨论——有人期待 JetBrains 重新探索 Swift tooling 的可能性，也有人认为这更可能与 Kotlin Multiplatform 或 Swift 构建工具链相关。如果你对 Swift 开发工具生态的未来方向感兴趣，不妨参与这份调查。

---

不依赖编译器识别 Swift Protocol 的方法 (How Well Can You Detect a Swift Protocol Without the Compiler?)

在 Swift 项目中，Protocol 几乎无处不在，但如果不依赖编译器或完整构建环境，仅通过源码文本判断一个文件是否定义或使用了协议，结果会有多可靠？Xiangyu Sun 在这篇文章中系统评估了多种检测策略，例如使用 SourceKit/LSP、SwiftSyntax AST、关键字正则匹配，以及通过 extension Foo: Bar、any / some 等语法信号进行启发式判断，并对这些方法的准确率与适用场景进行了比较。

文章最有意思的部分在于作者发现：简单的命名约定可以显著提升静态分析效果。如果团队统一使用 *Protocol 后缀命名协议类型（如 PaymentServiceProtocol），很多原本存在歧义的检测方法都会变得更加可靠。作者还进一步讨论了这种约定在 AI 辅助开发中的价值：通过在文件级别预分类协议文件，可以在向 LLM 提供上下文时显著减少 token 消耗，并提高分析效率，这是一个颇具启发性的视角。

---

迁移到 Swift Concurrency 前需要注意的细节 (What you should know before Migrating from GCD to Swift Concurrency)

从 GCD 迁移到 Swift Concurrency 并非简单的语法替换。在这篇文章中，Soumya Ranjan Mahunt 指出：Swift Concurrency 在任务调度、执行顺序以及并发语义上与 GCD 存在一些关键差异，例如 Task 的调度并不保证与 GCD 相同的 FIFO 执行顺序，而 actor 也并不是 DispatchQueue 的直接替代，其执行行为可能受到任务优先级和调度策略的影响。此外，文中还讨论了一些在实际迁移过程中容易被忽视的问题，例如 DispatchGroup 在 Swift Concurrency 中并没有完全等价的 API，以及在旧系统版本中使用 assumeIsolated 可能遇到的兼容性问题。

---

选择 AI Agent Skill 的九步框架 (A 9-Step Framework for Choosing the Right Agent Skill)

随着 AI Agent 在开发工作流中的应用越来越广泛，如何为 Agent 设计合适的“技能”（Skill / Tool）也逐渐成为一个新的工程问题。Antoine van der Lee 提出了一个用于判断何时应该为 Agent 创建技能的九步框架，帮助开发者在自动化能力、可维护性以及系统复杂度之间取得平衡。Antoine 指出，并非所有任务都适合直接交给 LLM，也并非所有能力都需要实现为 Agent 工具。文章从任务确定性、执行成本、可复用性以及安全性等角度出发，提供了一套相对系统的评估思路。

工具

DataStoreKit

这是一个很有意思的开源项目，由 Anferne Pineda 开发。它基于 SwiftData 的自定义 store 能力，在保留 SwiftData 上层开发体验的同时，重新实现了一套面向 SQLite 的底层存储后端，包括从 SwiftData 模型、谓词到 SQLite schema、SQL、快照与持久化历史的映射和执行。

DataStoreKit 提供了一些值得关注的特性，例如支持对数组、字典等集合类型数据进行谓词查询，底层以 JSON 形式映射到 SQLite；同时也提供了 SQL 直通能力，让开发者在 #Predicate 之外，能够直接利用 SQLite 的能力完成查询或维护操作。

这是目前为数不多、且实现深度较高的 SwiftData DataStore 自定义实践，展示了 SwiftData 作为数据表现层而非完整持久化引擎的另一种可能性。项目目前仍处于较早期阶段，API 和能力边界可能还会继续调整，但已经非常值得持续关注。

---

Playwright for Swift

Miguel Piedrafita 开发的 swift-playwright，将 Playwright 这套成熟的浏览器自动化能力带入了 Swift 生态。开发者可以直接使用 Swift 代码驱动 Chromium、Firefox 和 WebKit，完成页面导航、点击、输入、截图、执行 JavaScript 等常见操作，整体 API 风格也尽量贴近官方 Playwright。

从实现方式上看，它并不是重新实现一套浏览器自动化框架，而是在 Swift 侧封装了 Playwright 协议，底层依然通过 Node.js 的 Playwright driver 与浏览器通信。对于希望使用 Swift 构建测试工具、CLI，甚至 AI Agent 的开发者来说，这个项目提供了一个颇具吸引力的切入点。

活动

LET'S VISION 2026 -- Born to Create · Powered by AI

• 👀 70+ 展商现场体验
• 🤖 AI 创新产品 / AI Agent
• 🥽 XR / 空间计算沉浸体验
• 🎤 创作者与开发者分享

如果你是开发者、设计师、产品经理、创作者，还是对 AI 和未来科技感兴趣的探索者，都很值得来逛逛。

• 📅 2026.3.28 – 3.29
• 📍 上海 · 漕河泾会议中心

15% OFF 门票 👇

往期内容

• Macbook Neo：苹果重回校园的起点 - #126
• OpenClaw 不错，但我好像没有那么需要 - #125
• 春晚、机器人、AI 与 LLM - #124
• 祝大家马年新春快乐！- #123

💝 支持与反馈

如果本期周报对你有帮助，请：

• 👍 点赞 - 让更多开发者看到
• 💬 评论 - 分享你的看法或问题
• 🔄 转发 - 帮助同行共同成长

---

🚀 拓展 Swift 视野

• 📮 邮件订阅 | weekly.fatbobman.com 获取独家技术洞察
• 👥 开发者社区 | Discord 实时交流开发经验
• 📚 原创教程 | fatbobman.com 学习 Swift/SwiftUI 最佳实践

Macbook Neo：苹果重回校园的起点

上周，苹果推出了若干新款硬件产品。与以往的发布会不同，这次发布显得异常低调。起初我只对其中新发布的显示器感兴趣，但在看到不少数码媒体对 Macbook Neo 配置的吐槽后，也不由得多留意了这款产品。相较于其“减配”的表象，我更从其精准的定价中看到了苹果重返教育市场的决心。

十几年前，苹果还曾是教育硬件市场的重要参与者。那些在校园中使用苹果设备成长起来的学生，也有相当一部分在进入社会后顺理成章地成为苹果软硬件的长期消费者。但随着谷歌持续加大在 Chromebook 上的投入，而苹果又缺乏更具价格竞争力的产品，这一以 K12 为核心的市场逐渐被对手占据（Chromebook 曾一度拿下美国基础教育市场近 60% 的份额）。这不仅让苹果损失了一部分收入，更重要的是削弱了其在青少年群体中、围绕台式机与笔记本这种计算形态所建立的品牌亲和力。相比平板设备，笔记本在教学体验、适用场景、耐用性以及 IT 集中管理等方面依然具有明显优势。

在服务优先的今天，硬件往往与生态深度绑定。Chromebook 早早培养出一大批习惯使用 Google Docs 的年轻用户。随着年龄增长与数据的积累，即便他们日后具备购买苹果设备的能力，也很难再与苹果的服务生态形成深度绑定，更难形成真正的品牌信仰。

Neo 精准的定价改变了这一局面。$599 的起售价、$599的起售价、499 的教育优惠，让更多孩子有机会在学校就开始使用苹果设备、拥有 Apple ID，从而顺着苹果“预设”的轨迹，逐步购买更多产品与服务。至于被广泛批评的"减配"——A18 Pro 芯片对 K12 日常使用场景而言完全足够，它缺的不是性能，而是定位本就如此。苹果用移动端芯片换来了激进的定价空间，这是一笔算得很清楚的账。

采用订阅制的 Apple Creator Studio，同样展现了苹果希望让更多人与其生态建立长期联系的野心。对于学校而言，廉价硬件+强大的创作软件套件，构成了闭环。Macbook Neo 的硬件性能或许不算强劲，但足以在每台设备约 4–5 年的生命周期中提供稳定、可用的体验，让使用者逐步融入苹果的服务体系。从这个角度来看，MacBook Neo 更像是苹果抛向 Z 世代与 Alpha 世代的一枚“生态锚点”。

太多消费者和数码博主过于聚焦于苹果产品是否炫酷、是否有创新，却忘记了苹果的来时路——教育硬件市场深植于它的基因之中，今天的成功源于数十年前的积累，而现在它需要补上最近十几年的空缺。对于本周报的读者来说，Neo 大概率不是你的菜。但这并不妨碍它成为一款极具针对性、也颇具野心的产品——不是用来赚快钱的，而是苹果为未来二十年的生态版图所做的一次长期押注。

本期内容 | 前一期内容 | 全部周报列表

原创

跨域传递 NSManagedObjectContext 为什么在 Swift 6.2 中不再报错？真正的变化不在编译器

当同一段与并发有关的代码在旧版 Xcode 中无法通过，却在新版 Xcode 26（Swift 6.2）中顺利编译时，你第一时间会想到什么？很多人最初的判断可能是 Swift 编译器的并发分析（如 Region-Based Isolation）又进化了，但现实并没有这么简单。本文记录了我最近遇到的一次非常有意思的排查过程：从测试失败出发，通过构建最小复现用例，一步步追溯到 Core Data 的 SDK interface，最终发现，问题的关键并不完全在 Swift 编译器本身，而是框架的导入语义发生了变化——在新的 SDK 中，NSManagedObjectContext 获得了 NS_SWIFT_SENDABLE 等宏标注，使其在 Swift 中拥有了 Sendable 语义。

尽管 SwiftData 是未来苹果生态最重要的持久化框架，但作为其基础的 Core Data 并没有被苹果冷落。在过去几年中，苹果一直在默默改善其在 Swift 6 中的兼容性和并发体验，这是一个很好的现象。

近期推荐

Notepad.exe — Swift 新特性的第一个实验场

Swift 6 出了新语法？Xcode 太重，Playground 又太慢。Notepad.exe 让你在 30 秒内写代码、跑结果，专注验证想法本身。支持多版本工具链切换，集成模拟器，随开随用。

---

Swift 语言 2 月新动态 (What's new in Swift: February 2026 Edition)

Karen Chu 和 Dave Lester 在官方博客上整理了 2026 年 2 月 Swift 社区的生态动态。内容不仅涵盖了 Swift 在 FOSDEM（全球最大开源会议）上的活跃表现，还推介了多项重磅的开源进展与 Swift Evolution 提案。其中的 SE-0506 尤为让我惊喜。该提案为 withObservationTracking 增加了 Options 参数，开发者现在可以精确控制是观察变化前（willSet）、变化后（didSet）还是对象的生命周期（如 deinit）。并且通过 withContinuousObservationTracking 无需再手动递归注册，即可实现稳定、自动循环的连续事件追踪。

SE-0506 提案的通过意义重大。它不仅完美补齐了状态追踪的时机控制和连续性能力，更标志着 Swift 原生的 Observation 已经彻底成熟——它不再仅仅是 SwiftUI 的“专属附庸”，而是真正蜕变为了 Swift 语言中足以应对各种工业级、高性能状态流调度的核心基础设施。

---

写在 2026 年的 macOS 输入法开发规范

vChewing 唯音输入法 的作者 ShikiSuen 基于多年深耕 macOS 输入法的开发经验，全面梳理了 InputMethodKit (IMK) 的历史包袱，以及它在 Swift 6 严格并发检查下暴露出的种种痛点。文章深入探讨了 NSConnection 的命名规范、启用沙盒的必要性、MainActor 隔离冲突，以及高频中英切换（CapsLock）导致的 ARC 拥堵、macOS 26 Liquid Glass 机制下 NSWindow 运存不释放等棘手问题。面对苹果“上古框架”与现代 Swift 并发模型的碰撞，作者没有停留在抱怨上，而是提出了一套像“风险控制模型”一样的工程规范——将控制器退化为纯转发层、把业务逻辑剥离到弱引用 Session、使用运存自查自尽、彻底避开 IMKCandidates 等。

可贵的是，ShikiSuen 基于上述思路开发并开源了 IMKSwift 库。它为 Swift 6+ 提供了 @MainActor 完整隔离的 IMKInputSessionController 基类，完美覆盖了原生 IMKInputController 的并发地雷区。如果你需要开发 macOS 桌面端应用或输入法，这个库能让你无需手动 Hack，就能写出类型安全、无 data-race 警告的现代代码，非常值得学习与使用。

---

SwiftUI 的洋葱式架构：Swift Effects 实践 (SwiftUI, Swift Effects: A Beautiful Onion Architecture)

在 SwiftUI 中处理数据加载状态几乎是每个应用都会面对的问题：loading、loaded、failed 三种状态往往伴随着网络请求、缓存、日志记录等副作用逻辑，很容易让视图代码逐渐变得臃肿。Salgara 在本文中提出了一种类似 Onion Architecture 的思路：通过 ViewState + Effect Handlers 将 Fetch、缓存、日志等副作用拆分为多个可组合层级，并利用 AsyncSequence 与可注入的 Effect Handler 驱动状态变化，使 UI 仅根据状态进行渲染。这样一来，视图保持纯粹，而数据获取与副作用则沿着一条清晰的“Effect 管道”逐层流动。同时，这种结构也天然具备良好的可测试性——测试代码可以直接拦截并模拟数据源返回值，从而验证完整的状态转换流程。

Salgara 坦言，这种架构目前仍然是实验性的：原型优先，并尝试将一切视为视图（Everything as a View）。随着越来越多开发者从不同角度思考并尝试构建更符合 SwiftUI 特性的架构，这类探索不仅可能让 SwiftUI 本身受益，也有机会反过来丰富整个声明式编程范式，而不再只是复制其他 UI 框架的既有实践。

---

Spec-Driven Development：当 AI 写代码之后

随着 Cursor、Claude Code 等 AI 编程智能体（Agent）的普及，开发者们正面临一个新的痛点：当 AI 能在几分钟内跨越几十个文件生成上千行代码时，人类该如何有效审查？又该如何应对 AI 在长流程中逐渐出现的“上下文遗忘（Context Decay）”与幻觉问题？为此，一种新的开发范式正在逐渐成形：Spec-Driven Development（SDD）。在这一模式下，开发者的主要任务不再是直接编写代码，而是定义清晰的规格（Spec），再由 AI 根据这些规格生成实现。

Snow 通过四篇文章系统梳理了这一思路：从 “Vibe Coding” 的局限出发，介绍以规格为核心的开发流程，并进一步探讨规格在未来软件工程中的角色——代码或许不再是项目的中心，而只是规格的衍生物。

在 AI 逐渐承担实现细节的时代，软件工程的重心或许正在从“写代码”转向“表达意图”。SDD 尝试在人类的模糊意图与 AI 的无差别生成之间，建立一层强有力的约束。

---

为 SwiftUI Preview 构建一个 Mini Linker (Building a Mini Linker for SwiftUI Previews)

在 Xcode 26.3 的 mcpbridge 提供的众多工具中，RenderPreview 可以直接返回 SwiftUI Preview 的截图，方便 AI 进行分析。对于暂时无法使用 Xcode 26.3 mcpbridge 的开发者，Hesham Salman 在本文中介绍的思路以及配套工具，同样可以实现类似的能力。其技术亮点在于利用 SwiftSyntax 构建声明依赖图，再通过 BFS 找出当前 Preview 真正需要的最小源文件集合，从而避免编译整个 App Target 带来的构建等待。

本文的精华在于思路：利用 SwiftSyntax + BFS 快速定位 Preview 依赖的代码片段。过去 SwiftSyntax 的使用门槛较高，但在 AI 辅助开发逐渐普及的今天，它正逐渐成为理解代码结构的重要基础设施。即便你不像 Hesham Salman 那样熟练掌握该工具，了解其基本能力后，也可以借助 AI 将类似思路落地——而这类工具在过去往往只属于少数熟悉编译器工具链的开发者。

---

Swift 的规模化实践：TelemetryDeck 的分析服务 (Swift at scale: building the TelemetryDeck analytics service)

很多人讨论 Swift on Server 时，关注点往往停留在“能不能用”，而 TelemetryDeck 给出的则是一个更实际的答案：不仅能用，而且已经支撑起一项面向开发者、每月处理超过 1600 万用户数据的 analytics 服务。Daniel Jilg 在这篇文章中回顾了团队为何选择 Swift + Vapor 构建后端，并分享了不少来自生产环境的经验：例如如何借助 Codable 简化 API 编解码与校验、为什么应让 DTO 更贴近 controller、以及为何缓存 TTL、API 版本管理和错误监控这些“老生常谈”，在规模化的生产环境中往往才是真正的护城河。

---

是时候告别 SwiftGen 了吗？ (Get Rid of Your SwiftGen Dependency)

很长一段时间，开发者需要依赖类似 SwiftGen 这样的工具来解决 Apple 资源系统中的一个老问题：资源访问是字符串类型（stringly-typed）。无论是 localization key、图片名称还是颜色资产，一旦拼写错误，往往只能在运行时才会暴露问题。Asser Osama 指出，随着 String Catalog（.xcstrings）与 Asset Catalog Symbols 的引入与逐步完善，Xcode 已经能够在编译阶段自动生成资源符号，这种原生能力在不少现代项目中或许已经足以替代 SwiftGen。

需要说明的是，“移除依赖”的前提是项目完全运行在标准的 Xcode 生态中。Xcode 的符号生成属于构建系统内部机制，而不是 Swift 编译器或 Swift Package Manager 的能力——这意味着对于使用 Bazel、Buck 等非标准构建系统的团队来说，SwiftGen 仍然可能是更可移植、更可控的选择。

工具

SwiftUI Agent Skill

由 Paul Hudson 编写的 SwiftUI Agent Skill，旨在帮助开发者编写更智能、更简洁、更现代的 SwiftUI 代码。该项目发布仅两天便获得了 1k+ Star。

在过去几周中，本周报已经推荐了不少知名开发者编写的各类 Skill。尽管这些 Skill 都凝聚了作者的经验，但我仍不建议开发者直接“拿来即用”。至少应在采用前完整阅读一遍：Skill 更像是作者对自己数十甚至上百篇文章经验的提炼，而不是可以直接替代思考的“最佳实践”。开发者在理解其背后的设计思路后，再根据自己的开发习惯与项目需求进行取舍，这样才能更大地发挥它们的价值。

往期内容

• OpenClaw 不错，但我好像没有那么需要 - #125
• 春晚、机器人、AI 与 LLM - #124
• 祝大家马年新春快乐！- #123
• Xcode 迈入 Agent 时代 - #112

💝 支持与反馈

如果本期周报对你有帮助，请：

• 👍 点赞 - 让更多开发者看到
• 💬 评论 - 分享你的看法或问题
• 🔄 转发 - 帮助同行共同成长

---

🚀 拓展 Swift 视野

• 📮 邮件订阅 | weekly.fatbobman.com 获取独家技术洞察
• 👥 开发者社区 | Discord 实时交流开发经验
• 📚 原创教程 | fatbobman.com 学习 Swift/SwiftUI 最佳实践

春晚、机器人、AI 与 LLM

作为一个观众数量超十亿的电视节目，央视春晚无疑是极佳的展示平台。今年春晚中，多家中国机器人厂商在不同节目中展示了其产品，其中讨论度最高的当属宇树（Unitree）的人形机器人。在表演环节，多款型号的人形机器人完成了大量较为复杂的武术与动态动作展示。与去年偏静态、偏站桩式的呈现相比，今年的动作复杂度与稳定性确实有明显提升，这一点也得到了全球媒体的关注与报道。

春晚之后，社交媒体上的讨论呈现出明显分化。除了对技术进步的惊叹之外，“预编程”、“没有 AI”、“缺乏实用性”等质疑声音同样不少。这在一定程度上反映了公众对机器人技术复杂度的低估——尤其是对运动控制、实时反馈系统和系统级整合难度的认知不足。

需要澄清的一点是：预训练并不等于“录制-回放”。当前人形机器人在此类表演中的确采用了高度规划的动作流程，这与人类舞者、运动员的训练逻辑有相通之处——大量的离线训练与调试构成了动作的基础，但在实际执行过程中，身体仍需依赖动态平衡与即时修正来应对真实环境的扰动。正是这种容错与实时修复能力，才让人形机器人这个天然不稳定的双足系统得以完成高动态的连续动作。

与此同时，近年来大语言模型（LLM）的爆发，让不少人将 LLM 与 AI 等同起来。事实上，AI 作为一个已有数十年发展的领域，远远不止语言理解这一分支。尤其是面对真实的物理世界时，视觉识别、路径规划、运动控制、强化学习等专用模型在工业与实体系统中的使用量，依然远高于 LLM。在机器人领域，真正决定能力上限的往往是感知系统、控制系统以及低延迟反馈算法，而不是语言推理能力。

即便未来为人形机器人引入更强的"认知能力"，更适合的路径也未必是直接接入 LLM，而可能是构建能理解物理规律的世界模型（World Models）与具备低延迟响应能力的控制系统——这两点恰恰是 LLM 的固有短板。具身智能（Embodied AI）的挑战，与纯文本推理存在本质差异。

至于“实用性”的问题，功夫或舞蹈确实难以直接对应现实工作场景。但恰恰是这些对平衡性、协调性与动态响应要求极高的动作，为人形机器人这种高度复杂且不稳定的系统提供了极佳的验证场景。它们更像是工程能力的压力测试，展示的是机械设计、电子控制与算法系统整合的成熟度，而非短期商业落地能力。

我个人对于人形机器人未来的市场规模仍然持审慎态度。技术进步与商业普及之间往往存在不小的鸿沟。但从今年春晚所呈现的进步幅度来看，可以合理判断：在未来十年内，机器人或智能机器以某种形式融入日常工作与生活场景，已不再是科幻想象。无论你是否喜欢“机器人”，技术演进的趋势已经十分明确，我们终将需要与它们共存。

至于“机器人奴役人类”的情景，我暂时并不担心。我更现实的担忧是：如果它们在工作中出现 Bug，给我一拳，我真的挨不住。

本期内容 | 前一期内容 | 全部周报列表

🚀 《肘子的 Swift 周报》

每周为你精选最值得关注的 Swift、SwiftUI 技术动态

• 📮 立即订阅 | weekly.fatbobman.com 获取完整内容
• 👥 加入社区 | Discord 与 2000+ 开发者交流
• 📚 深度教程 | fatbobman.com 探索 200+ 原创文章

近期推荐

如何在不破坏 App 的前提下迁移到 @Observable (How to Migrate to @Observable Without Breaking Your App)

随着越来越多的应用将最低系统版本提升至 iOS 17，@Observable 正在取代 ObservableObject 成为新的状态管理基础设施，但当项目已经深度依赖 ObservableObject + @Published 时，迁移远非简单替换宏即可完成。Pawel Kozielecki 结合一次真实的迁移踩坑经历，从底层机制差异出发，系统梳理了新体系下属性包装器的正确使用方式——用 @State 管理生命周期、用 @Bindable 处理双向绑定、只读场景直接使用普通属性，并特别指出了 @ObservationIgnored、计算属性追踪盲点等容易被忽视的细节。迁移的难点从来不在语法层面，而在于真正厘清“谁拥有 view model 的生命周期”这一根本问题。

---

验证多个回调按顺序触发 (Testing with Event Streams)

尽管 Swift Testing 提供了丰富的断言 API，但在实际使用中你会发现，并没有一个工具能够完全对应 XCTest 中“验证多个回调按顺序触发”（fulfillment + enforceOrder）的能力。confirmation 既需要嵌套使用，也无法直接校验触发顺序。对此，Matt Massicotte 提出了一种更符合 Swift 并发模型的思路：使用 AsyncStream 收集事件，并封装为一个轻量级的 EventStream 类型——当回调触发时 yield 事件标识，测试结束后通过 collect 获取完整事件序列，再与预期数组进行对比。对于“为什么不直接使用数组”这一疑问，Matt 也给出了充分理由：在存在 @Sendable 约束或 actor 隔离不一致的场景下，直接写入数组会触发并发安全问题，而基于 AsyncStream 的方案则天然符合并发模型的约束。

---

务必为 SwiftData 模型显式声明 Schema 版本 (If You’re Not Versioning Your SwiftData Schema, You’re Gambling)

SwiftData 的声明式写法与自动迁移能力很容易让人产生“框架会替我处理一切”的错觉，但现实是，一旦模型结构发生变化（字段新增、重命名、关系调整），如果没有显式的 schema version 与 migration plan，就只能依赖隐式推断。一旦推断失败，结果往往不是优雅的迁移，而是崩溃、数据丢失，甚至导致应用无法启动。Mohammad Azam 的建议直接而务实：显式声明 Schema 版本；为未来的结构变化预留迁移路径；将“迁移设计”视为模型设计的一部分，而不是事后补救。

本文的观点同样适用于 Core Data。即便模型完全兼容轻量迁移，为每个发行版本创建对应的模型版本文件（只要发生结构修改），不仅有助于追踪模型演化轨迹，也能在出现问题时实现清晰而可控的回滚。用明确的版本机制约束模型演进，本质上是在为长期维护建立安全边界。

---

用 Swift 开发 CLI 工具 (How to build a simple CLI tool using Swift)

一个有趣的现象是，在 AI Coding 时代，CLI 正在重焕青春——越来越多的开发者通过构建 CLI 工具来承载自己的 MCP 与 Agent 工作流。Natascha Fadeeva 介绍了如何用 Swift Package Manager 和 Apple 官方的 ArgumentParser 库构建结构化的命令行工具：定义主命令与子命令、处理异步网络请求、最终编译为可独立分发的二进制文件。对于已经熟悉 Swift 的 iOS 开发者来说，这条路径比维护一套 bash/Python 脚本更自然，也更容易随项目一起演进。

---

在 AI 编程时保持方向感 (Navigation Notes – Agentic coding)

作为一个拥有丰富经验的开发者，Joseph Heck 认为当 AI 能够主动执行任务、生成代码甚至推动改动时，开发者的角色从“逐行实现者”转变为“路径规划者”。真正稀缺的能力不再是写代码的速度，而在“导航”——也就是开发者在复杂代码与多代理环境中如何保持方向感。Joseph 给出了几条建议，例如：在提示词中始终加入"对任何模糊之处向我提问"；先让 Agent 制定计划并获得确认，再开始实施；提供确定性的反馈回路（单元测试、编译器错误），让 Agent 能够自我修正；以及将反复使用的指令集沉淀为 Skill 文件等。

Heck 并没有过度渲染“AI 颠覆开发者”的叙事，而是强调一种更冷静的现实：agentic coding 会放大已有的工程能力。如果你本来就善于模块划分与抽象设计，AI 会加速你；如果边界感模糊，AI 只会更快制造混乱。

---

为 Agent 驱动的 iOS 项目构建可靠交付管线 (Setting up a delivery pipeline for your agentic iOS projects)

当代码的生成、修改与重构开始由 Agent 驱动时，传统的 CI/CD 流程是否仍然足够？Donny Wals 以一次真实经历展开：健身时应用崩溃，他将 Crash Report 交给 Agent 分析，训练结束后 PR 已经准备就绪，合并后 TestFlight 构建随即落地。围绕这一实践，他系统梳理了如何为“agentic iOS 项目”构建一条可靠的交付管线（delivery pipeline），确保自动化改动依然可控、可验证、可发布。

文章的重点并不在某个具体工具，而在流程设计本身。Donny 强调，Agent 生成的代码本质上仍属于“未经人工逐行审查的改动”，因此更需要明确的边界与质量闸口：自动化测试、持续集成与发布流程必须承担最终的交付责任。Agent 可以显著提升实现速度，但工程纪律不能随之放松——速度提升之后，控制机制反而更为关键。

---

实时掌握 Foundation Models 的上下文消耗 (Tracking Token Usage in Foundation Models)

Apple 的 Foundation Models 运行在设备端，上下文窗口仅 4096 个 token，一旦超出便无法继续对话。iOS 26.4 新增了 token 用量追踪 API，帮助开发者实时掌握上下文消耗情况。Artem Novichkov 系统介绍了四个关键指标：模型上下文总容量（contextSize）、Instructions 的 token 消耗、单条 Prompt 的消耗，以及完整对话记录（Transcript）的累计用量。文章还揭示了一个容易被忽视的细节：当引入 Tool 时，其名称、描述与参数 Schema 会被序列化并计入 token，同一段 Instructions 在附加 Tool 后 token 数从 16 跃升至 79。对于设备端模型而言，token 的可观测性将成为优化体验的基础设施。

工具

App Store Connect CLI

App Store Connect CLI 是由 Rudrank Riyam 开发的非官方 App Store Connect 命令行工具，功能覆盖 TestFlight 管理、构建上传、代码签名、截图自动化、本地化同步、应用审核提交、notarization，以及财务报告下载等完整发布链路。它从设计阶段就强调 Agent 场景，并提供了面向 Agent 的实践文档。若你的发布流程重心在 TestFlight、元数据、提审、签名与 CI 自动化，ASC 可以作为 fastlane 的轻量替代方案之一。

---

GRDB 7.10.0: 新增 Android、Linux、Windows 支持

GRDB 7.10.0 是一个具有里程碑意义的版本更新：本次正式引入对 Android、Linux、Windows 的支持，并新增通过 Swift Package Manager 使用 SQLCipher（加密数据库）的能力——这两项功能都长期受到社区期待。这意味着这个 Swift 生态中最成熟的 SQLite 封装库，正在从 Apple 平台工具演进为真正的跨平台数据层解决方案。

Gwendal Roué 在 版本公告 中也特别说明，由于 Xcode 尚未支持 package traits，SwiftPM 目前仍会下载未实际使用的依赖；在相关问题解决之前，SQLCipher 支持将以 fork 形式长期维护。

---

Swift System Metrics

Swift System Metrics 为 Swift 应用（尤其是服务端项目）提供了统一的系统级指标采集能力，例如 CPU 使用率、内存占用、文件描述符数量等，并通过标准化的 Metrics 接口对外暴露，便于接入 Prometheus 等现有监控体系。它并非一个独立的监控系统，而是由 Swift Server Work Group 推动的基础设施组件，旨在与 Swift Metrics 生态对齐，使系统资源指标与应用级指标纳入同一可观测体系。1.0 的发布意味着 API 已趋于稳定，具备生产环境使用条件。对正在构建 Swift 后端服务、或持续完善 Swift 可观测性能力的团队来说，这是一个基础设施层面的关键拼图。

往期内容

• 祝大家马年新春快乐！- #123
• Xcode 迈入 Agent 时代 - #112
• 变幻的光影，不变的干草堆 - #121
• Skip 开源：从“卖工具”到“卖信任”的豪赌 - #120

💝 支持与反馈

如果本期周报对你有帮助，请：

• 👍 点赞 - 让更多开发者看到
• 💬 评论 - 分享你的看法或问题
• 🔄 转发 - 帮助同行共同成长

---

🚀 拓展 Swift 视野

• 📮 邮件订阅 | weekly.fatbobman.com 获取独家技术洞察
• 👥 开发者社区 | Discord 实时交流开发经验
• 📚 原创教程 | fatbobman.com 学习 Swift/SwiftUI 最佳实践

祝大家马年新春快乐！

今年的中国农历年是丙午年，是一个60年一遇的“赤马年”。

在干支纪年中，天干“丙”与地支“午”五行皆属火，双火叠加，形成了极为罕见的“火马”格局。因火色为赤，故此马年又称“红马年”。这匹“红马”承载着最纯粹的阳刚之气与蓬勃活力，预示着接下来的一年将充满奔放的能量与昂扬的进取心。

在这个 60 年一遇的吉庆节点，我在此祝各位读者新的一年：身体健康（CPU 满血），事业驰骋（性能优化），万事顺遂（无 Bug 运行），马到成功（编译通过）！ 🎉

本期内容 | 前一期内容 | 全部周报列表

🚀 《肘子的 Swift 周报》

每周为你精选最值得关注的 Swift、SwiftUI 技术动态

• 📮 立即订阅 | weekly.fatbobman.com 获取完整内容
• 👥 加入社区 | Discord 与 2000+ 开发者交流
• 📚 深度教程 | fatbobman.com 探索 200+ 原创文章

近期推荐

Swift 并发进阶阅读路线图 (Swift Concurrency from Zero to Hero | Reading List)

暂不说 AI 目前还很难像专家一样处理 Swift 6 并发相关的复杂代码，即便工具能力突飞猛进，作为使用者的你也不该只当旁观者：系统、全面地理解 Swift 并发的概念、用法与历史脉络，才能从源头构建更安全、更强健的应用。Alex Ozun 在本文中按难度划分关卡，整理了一份“从入门到进阶”的 Swift Concurrency 阅读路线图：每一关都配套了公开且免费的参考资料，难度也会逐级递增，希望你在完成这条主线之后，能从 Zero 走到 Hero。

---

15 步打造现代 iOS 项目 (A Modern iOS Project Setup in 15 Steps)

对于不少开发者而言，新项目的开始往往伴随着重复而琐碎的配置工作。Ertem Biyik 在这条串贴中用 15 个步骤梳理了一套现代 iOS 项目的工程化基线：以 Tuist 为核心管理依赖与生成，通过 xcconfig 统一环境配置与构建参数，借助 Makefile 简化初始化流程，并在 GitHub Actions 中完成 lint 与构建校验；同时，他还建议使用 AGENTS.md 统一 AI 上下文，并配合 sosumi.ai 获取更利于 LLM 阅读的 Apple 文档。

---

Micelio：后 Git 时代的代码托管工具 (Micelio: Growing Software Like Nature Grows Forests)

AI 深度参与开发流程后，许多传统工具开始显露出“水土不服”。Pedro Piñera 以“菌丝网络（mycelium）”为隐喻，指出随着 AI agent 参与开发的规模与频率不断提升，Git 这种只记录 what changed、却难以保留 why it changed 的历史模型，正在变得不够充分。本文是他对“后 Git 时代”的一次系统性思考，也是对“agent-first 协作方式”的公开实验。配套的开源 git forge Micelio 项目尝试以 session 为核心单元捕获上下文与推理，将代码托管的重心从“存 diff”转向“存决策”。项目仍处于早期阶段，但其问题意识与工程方向，都值得持续关注。

---

Swift 写时复制 (Copy-on-Write in Swift - How It Works and Why It Optimizes Memory)

写时复制（COW）是 Swift 的核心机制之一，也是值类型在保证语义一致性的同时获得良好性能的关键。Sagar Unagar 结合集合类型的内部实现，解释了 Swift 如何通过“结构体外壳 + 引用存储”的方式实现读共享、写分离：只有在发生写入且检测到非唯一引用时，才会借助 isKnownUniquelyReferenced 触发真正的拷贝。文章同时展示了自定义类型实现 COW 的基本模式。

---

Metal Shader 入门 (Taking First Steps into Metal Shaders)

对于大多数 SwiftUI 开发者而言，Metal 往往显得遥远而复杂。Letizia Granata 通过本文带你从 0 开始接触 Shader：从理解 GPU 与 CPU 的分工，到在 Xcode 中添加 .metal 文件，再到编写并在 SwiftUI 中应用一个最简单的 shader 效果。Letizia 没有深入渲染管线或图形学细节，而是聚焦“如何真正跑起来”，帮助读者跨过入门门槛。

---

为 Landmarks 构建 Vapor 后端 (Setting Up a Backend Server for Our Landmarks App)

Landmarks 是 Apple 在 SwiftUI 教程中提供的经典示例应用，但由于它使用本地 JSON 数据，与真实项目的客户端—服务器架构仍存在差距。Kyle Browning 使用 Vapor 为 Landmarks 构建了一个简单的后端服务，将静态示例升级为通过 API 获取数据的完整结构。文章围绕模型定义、路由配置、数据响应以及与 SwiftUI 前端的对接展开，重点不在复杂业务逻辑，而在于示范如何把一个“教学示例”扩展为更贴近真实世界的项目。

---

Spotlight 后台索引机制解析 (In the Background: Spotlight Indexing)

系统更新后的几天里机器发热、卡顿，很多人都知道这与 Spotlight 的重新索引有关，但它在后台如何扫描文件、何时触发重建索引、又如何调度系统资源，却鲜少被系统性梳理。Howard Oakley 基于日志与实测数据，对 Spotlight 索引的触发机制、进程行为以及对 I/O 与性能的影响进行了细致分析，提供了一次关于 macOS 内部运行机制的深入技术观察。

工具

ScreenStateKit：并发时代的 MVVM 演进

如果你欣赏 TCA 的单向数据流与可预测状态管理，却又不想在现有 MVVM 项目中彻底重构架构，那么 ScreenStateKit 状态管理库也许是一个折中方案。作者 Anthony Tran 将传统 ViewModel 拆分为两个职责清晰的部分：一个运行在 @MainActor 上、只负责持有 UI 状态的 ScreenState，以及一个以 Swift actor 实现、专门处理业务逻辑与异步任务的 ScreenActionStore，所有状态变更都通过强类型 Action 作为唯一入口，从而在保持 MVVM 结构直观性的同时，引入类似 TCA 的单向数据流与编译期并发安全。配合内建的加载与错误状态管理、重复请求防护（ActionLocker）、父子状态传播与分页支持。Anthony 亦撰写了一篇详尽的设计说明文章，对其架构理念与实践细节进行了系统阐述。

---

GitHub 子目录下载工具

如果你曾为了下载 GitHub 上的某个示例目录而被迫 git clone 整个仓库，这款 GitHub Downloader 显然正是为此而生。它是 Stewart Lynch 开发的一款原生 macOS 应用，允许你粘贴任意 GitHub 仓库或子目录 URL（包括 tree/branch/path 形式），自动识别默认分支，递归下载所选目录内容，并完整保留其原始层级结构。

---

SimTag：为模拟器标注分支上下文

在并行开发成为常态的今天，面对多个外观几乎相同的 iOS Simulator，开发者很容易迷失：到底哪个分支正在运行？是否调试了错误的构建版本？Aryaman Sharda 开发的 SimTag 会在每个 Simulator 窗口上叠加一个轻量标识，显示当前构建对应的 git 分支与提交信息。对于习惯使用 worktrees、进行 PR 审查或结合 AI 协作开发的团队来说，这是一个能够显著减少认知摩擦、避免“调错分支”的实用小工具。

往期内容

• Xcode 迈入 Agent 时代 - #112
• 变幻的光影，不变的干草堆 - #121
• Skip 开源：从“卖工具”到“卖信任”的豪赌 - #120
• 从 Anthropic 封杀与苹果谷歌结盟，看 AI 护城河的构建 - #119

💝 支持与反馈

如果本期周报对你有帮助，请：

• 👍 点赞 - 让更多开发者看到
• 💬 评论 - 分享你的看法或问题
• 🔄 转发 - 帮助同行共同成长

---

🚀 拓展 Swift 视野

• 📮 邮件订阅 | weekly.fatbobman.com 获取独家技术洞察
• 👥 开发者社区 | Discord 实时交流开发经验
• 📚 原创教程 | fatbobman.com 学习 Swift/SwiftUI 最佳实践

Xcode 迈入 Agent 时代

尽管在 Xcode 26 的最初版本中，苹果就已经加入了一定的 AI 辅助编程能力，但当时的体验更像是把 ChatGPT 生硬地嵌入到 IDE 中：功能存在，却彼此割裂。与当时风头正盛的 Cursor 相比，它更像是两个时代的产物。随着 Claude Code 等 AI CLI 工具逐渐成熟，Xcode 更显得步伐迟缓，甚至让不少开发者开始怀疑：在 AI 时代，它是否还能胜任“主力 IDE”的角色。

26.3 版本的到来，几乎没有任何预热，却用实际行动回应了这些质疑。通过集成 Claude Code / Codex，苹果给出的答案很直接：只要策略得当，Xcode 依然是苹果生态中极具潜力的开发环境。这一次，Xcode 并没有简单地塞进一个 CLI 工具面板，而是引入了一套原生的 Xcode Tools（MCP），并配合 Swift 6、SwiftUI、SwiftData 等官方技术文档，形成了高度一致、贴合最新实践的整体体验。即便对于已经熟练使用 CLI + XcodeBuildMCP + 各类 Skills 的开发者而言，这套原生方案依然具备很强的竞争力——尤其是几乎为零的配置成本，这对绝大多数开发者来说意义重大。

更值得注意的是，这次提供的 Xcode Tools 并不只是服务于 Xcode 本身，它们同样可以作为标准 MCP，为其他 AI 工具提供能力支持。这种开放姿态，并不完全符合外界对苹果一贯风格的印象。

当然，站在今天这个时间点，我们还不能断言 Xcode 已经重新回到了第一阵营。但可以肯定的是，26.3 释放了一个非常明确的信号：苹果愿意与主流工具和服务协作，去打造真正符合时代的开发体验。也正因为如此，我对下一阶段的 Siri 抱有更高的期待——很可能在 iOS 27 中，苹果会在现有 Intent 体系之外，为系统和应用提供更多标准化接口，让 AI 更自然地融入整个生态。

Xcode + Agent 只是起点。

Apple + Agent，才是更值得关注的未来。

本期内容 | 前一期内容 | 全部周报列表

🚀 《肘子的 Swift 周报》

每周为你精选最值得关注的 Swift、SwiftUI 技术动态

• 📮 立即订阅 | weekly.fatbobman.com 获取完整内容
• 👥 加入社区 | Discord 与 2000+ 开发者交流
• 📚 深度教程 | fatbobman.com 探索 200+ 原创文章

原创

Xcode 26.3 + Claude Agent：模型替换、MCP、Skill 与自适应配置

Xcode 26.3 版本中苹果直接提供了对 Claude Code/Codex 的支持。自此，开发者终于可以在 Xcode 中方便的使用原生 AI Agent 了。 这两天我针对新版本进行了一系列尝试，包括如何使用最新模型、配置 MCPs/Skill/Command、以及编写自适应的 CLAUDE.md。本文以 Claude Code 为例，分享一些文档之外的技巧。

近期推荐

macOS 录屏软件开发实录：从像素抓取到元数据重现

视频正在取代文字成为更受欢迎的表达方式，而好工具是创作的加速器。macOS 录屏软件 ScreenSage Pro 的开发者 Sintone 深度复盘了如何基于 ScreenCaptureKit 和 Metal 实现“录完即剪完”。从解决 SCK -3821 诡异报错，到由 ObservableObject 迁移至 @Observable 优化时间线性能，本文毫无保留地分享了从像素抓取到高性能合成的全过程。

---

哪种方式判断字符串是否在白名单里最快：Set、Array、Enum、Dictionary 还是 switch?

在 Swift 里，判断一个字符串是否属于某个键集合，可以写成 Set.contains、Array.contains、RawRepresentable enum 的 init?(rawValue:)、switch 多分支，甚至用 Dictionary 来做映射。看起来差别不大，但真要放进性能敏感路径，结果可能并不完全符合直觉。Helge Heß 做了一次简单的基准测试：Set.contains 毫无悬念地领先，其次是 enum(rawValue:)和 Dictionary（两者非常接近）；而很多人下意识会高估的 switch，反而排在 enum 之后，Array.contains 则垫底收场。作为一个小实验，这个结果或许正好可以拿来校准一下我们对 Swift 性能的直觉。

---

从一次性付费到 Freemium (Migrating an iOS app from Paid up Front to Freemium)

付费下载和免费 + 应用内购买是两种截然不同的商业模式，随着应用发展，开发者可能需要在两者之间转换。Donny Wals 在本文中分享了他将 Practical Core Data 应用从 $4.99 付费下载转为 freemium 的完整经历。文章不仅涵盖了 StoreKit 2 的技术实现细节（购买流程、状态管理、家庭共享），更有价值的是他对商业决策的深入思考：付费门槛虽然能筛选出认真的用户，但也阻挡了大量潜在用户体验产品价值的机会。对于教育类或工具类独立应用，freemium 可能是用户增长和收入之间更好的平衡点。

---

iOS 应用中的按需资源 (On-demand resources in iOS app)

应用体积一直是开发者需要关注的问题，尤其是在应用包含大量图片、音频或其他资源时。尽管苹果很早就在 iOS 中提供了 On-Demand Resources（ODR）来应对这一挑战，但这一功能的存在感并不强，常被开发者忽略。在本文中，Majid Jabrayilov 系统性地回顾了 ODR 的工作机制与使用方式，包括资源分组、标签管理、下载生命周期，以及与系统缓存策略之间的协作关系。

虽然苹果在推广 Background Assets 作为更现代的方案，但 ODR 在需要即时响应的按需下载、细粒度资源控制等场景下仍有其独特价值。

---

Observation 四个常见陷阱 (Objectively Better, Observably Trickier)

在全面拥抱 Observation 框架时，开发者需要警惕其工作机制与 Combine 的 @Published 并不相同，简单替换往往会引入隐蔽的问题。Danny Bolella 总结了迁移过程中四个常见陷阱：@State 持有引用类型时的非惰性初始化、嵌套 @Observable 对象导致的更新丢失、数组元素绑定方式的变化，以及与其他属性包装器产生的冲突。文章通过清晰的代码示例逐一给出解决方案，并反复强调一个核心原则：只有视图当前正在访问（调用 getter）的属性发生变化时，才会触发更新。理解并顺应这种“惰性观察”的思维方式，是正确使用 Observation 框架的关键。

---

在 macOS 应用中实现 Open Recent 菜单 (Add an Open Recent Menu to a SwiftUI app)

“Open Recent” 是 macOS 应用的标准功能，但对于 SwiftUI 开发者来说，正确实现这个功能并不直观。在本文中，Mark Szymczyk 通过一个简洁的示例，展示了如何利用 NSDocumentController 为应用接入系统级的最近文件管理能力：自动维护列表、更新菜单，以及与文档生命周期的无缝协作。对于文档型或工具类应用，这是一个低成本、却能明显提升“原生感”的细节优化。

工具

Radioform：一个原生、开源的 macOS 音频均衡器

macOS 一直缺少系统级的音频均衡器，由 Matthew Porteous 开发的 Radioform 填补了这个空白。该项目采用 SwiftUI 菜单栏 App + Swift Host + CoreAudio HAL Driver + C++ DSP 的分层架构，把 UI 与实时音频处理彻底解耦。DSP 部分实现了 10 段参数 EQ、参数平滑、限幅与实时安全控制；工程上也有完整 CI、签名公证与 DMG 发布流程。不是“能跑就行”的 Demo，而是接近可长期维护的生产级音频工程样板。

---

CircuitPro：macOS 原生的 PCB 设计工具

这是一个 macOS 原生应用较少涉足的领域：PCB 设计。CircuitPro 是一款面向 macOS 的 PCB EDA 工具，目标是把原理图、布局与元件库流程做成更符合 Apple 平台习惯的体验。（项目仍处于早期开发阶段）

项目里最吸引我的是自研的 CanvasKit。它更像一个面向 EDA 场景的 2D 交互引擎，而不只是普通画布组件：上层是声明式 CanvasView，中层是状态中枢 CanvasController，底层是输入路由、渲染树与工具系统。更关键的是，吸附、输入处理、连线引擎都被做成了协议化插拔点，让原理图和布局共享同一基础设施，同时保留各自的路由规则。

即便你对 PCB 设计本身不感兴趣，CircuitPro 也很值得关注，尤其是它在 SwiftUI + AppKit 融合架构上的工程实践。

求贤

了解二次元的 iOS 工程师

本公司是二次元文生图头部企业（总部新加坡），招聘岗位为大陆全职 remote。求职者需要了解二次元文化，懂得二次元用语（黑话）。

岗位职责 (Responsibilities):

• 我们正在寻找一位经验丰富的 iOS 工程师（中高级），负责主导我们 iOS 应用的开发与优化工作。

• 理想的候选人应具备深厚的 Swift 技术功底，出色的测试与团队协作能力，并拥有现代 iOS 架构及工具链的实战经验。

任职要求 (Requirements):

• 3 年以上 iOS 开发经验，主要使用 Swift，同时具备一定的 Objective-C 代码维护能力。

• 至少 1 年的 SwiftUI 和 SPM (Swift Package Manager) 实战经验，熟悉其生态系统及最佳实践。

• 熟悉 iOS 15+ 新特性，能够针对不同的 iOS 版本和设备屏幕尺寸进行适配及性能优化。

• 掌握单元测试和 UI 自动化测试 (XCTest, XCUITest)，有能力编写可维护的代码，以确保项目的稳定性和可扩展性。

• 精通 Git 工作流（Git Flow, 主干开发/Trunk-Based Development），并具备基本的代码审查 (Code Review) 技能。

• 理解基础的 iOS 应用模块化设计、多种单页面架构模式以及性能优化方法，并具备在项目中落地的能力。

加分项/优先考虑 (We will give priority to who):

• 拥有跨平台开发经验（满足以下任意一项即可）：

• 6 个月以上的任意前端技术栈经验 (TypeScript/JavaScript, React, React Native)。

• 6 个月以上使用 Kotlin 及相关框架的 Android 开发经验。

• 6 个月以上的任意后端开发框架经验。

• 拥有至少 6 个月的 iOS 基础设施工具或框架搭建经验，包括代码质量提升（Linting, 静态分析, CI/CD）、效率优化（模块化，Gradle 组件化*）、以及性能调优（启动速度、帧率、离线模式、多线程）。

• 拥有 1 年以上 SDK 开发经验，包括通用库开发，如图片加载库 (SDWebImage, Kingfisher)、富文本编辑器、网络层或持久化层 (SQLite, Realm, Core Data)。

• 具备 UI/UX 相关经验：

• 熟悉 Apple 人机交互指南 (HIG)，能够在理解跨平台设计差异的同时，实现符合 Apple 设计标准的 UI。

• 拥有扎实的动画和交互动效开发经验，熟悉 Core Animation, UIKit Dynamics 等。

• 有深色模式 (Dark Mode) 及主题切换功能的开发经验。

• 具备极强的审美感知力，拥有绘画、摄影或设计相关的技能或爱好（附带作品集者优先）。

• 拥有完整的 App 生命周期经验：曾独立开发、发布并维护过支持多国/多语言的 iOS 应用。

• 积极参与技术社区，例如：

• 具有主动学习和分享的心态，有进行技术演讲的经验。

• 有技术写作经验（博客、文章）。

• 有开源项目贡献经历。

• 有使用 AI 编程工具的经验，如 Claude, ChatGPT, GitHub Copilot, Cursor 或 Windsurf。

• 具备流利的英语沟通能力或持有日语 N2 证书。

联系人

xx2bab@gmail.com

往期内容

• 变幻的光影，不变的干草堆- #121
• Skip 开源：从“卖工具”到“卖信任”的豪赌 - #120
• 从 Anthropic 封杀与苹果谷歌结盟，看 AI 护城河的构建 - #119
• AT 的人生未必比 MT 更好- #118

💝 支持与反馈

如果本期周报对你有帮助，请：

• 👍 点赞 - 让更多开发者看到
• 💬 评论 - 分享你的看法或问题
• 🔄 转发 - 帮助同行共同成长

---

🚀 拓展 Swift 视野

• 📮 邮件订阅 | weekly.fatbobman.com 获取独家技术洞察
• 👥 开发者社区 | Discord 实时交流开发经验
• 📚 原创教程 | fatbobman.com 学习 Swift/SwiftUI 最佳实践