Dave Verwer 在 iOS Dev Weekly 第 751 期宣布，这份已经持续近 15 年的周报将交由新的团队继续运营，而他自己接下来会全职投入 Swift Package Index。我的博客在早期获得关注，也曾得益于 iOS Dev Weekly 的推荐；而我在周报中坚持撰写每期周评，同样在很大程度上受到 Dave Verwer 的启发。对于很多 Apple 平台开发者来说，iOS Dev Weekly 早已不只是一份链接合集。它既是社区路标，也是长期陪伴。
不过，相较于“Dave 离开 iOS Dev Weekly”这个略带告别感的表述，我更愿意把这件事看作一次重心转移：从整理 Swift 社区的信息流，转向建设 Swift 生态的基础设施。
Swift Package Index 最初由 Dave Verwer 和 Sven A. Schmidt 共同创建，是 SwiftPM Library 的继承者与重构版。刚出现时，它很容易被理解为一个“找 Swift 包的网站”。但几年过去后，SPI 已经明显超出了普通索引站点的范畴。它不仅记录包的基本信息，也通过真实构建来验证不同 Swift 版本和平台的兼容性，托管 DocC 文档，展示维护状态、依赖关系、许可证、测试与质量评分，还通过 Ready for Swift 6 这样的项目，观察整个包生态向新语言特性迁移的进度。
这些能力看似分散，实际上指向的是同一件事：让 Swift 包生态变得更可判断、更可比较，也更可信。对于个人开发者来说，选择依赖时可以少一点“开盲盒”；对于团队来说，在引入第三方库前能更清楚地评估风险；对于包作者来说，也多了一个展示项目健康度和文档质量的公共窗口。一个成熟的包生态，不能只靠 Package.swift 存在。它还需要可见的兼容性、持续的文档、稳定的构建验证，以及围绕这些信息逐渐形成的信任机制。
我在 第 135 期 中提到：CocoaPods 正在退场，SwiftPM 才刚翻到第二章。随着 CocoaPods Trunk 进入只读倒计时，Flutter 等跨平台生态也开始转向 SPM，Apple 平台依赖管理的“大一统”看起来已经越来越接近。但这并不意味着 SwiftPM 已经完成了真正意义上的破圈。它当然会成为 Apple 平台的默认答案，可如果 Swift 想在 Linux、Android、Wasm、嵌入式等更多场景中继续扩展，SwiftPM 需要面对的就不只是“能不能安装依赖”，而是整个生态是否足够透明、可靠、可持续。
在这一点上，SPI 的价值可能比它的名字暗示的要大得多。它可以是索引，也可以是生态仪表盘；可以是文档托管平台，也可以是兼容性实验室；未来甚至有机会在包集合、供应链安全、版本不可变性、公共 registry 等方向上承担更多角色。Dave 此前也曾提到，SwiftPM registry 能为 Swift 依赖管理带来更安全、更快的分发方式，而公共开源 registry 仍是一个值得期待的空白。
iOS Dev Weekly 记录的是 Swift 社区每周的涟漪，而 Swift Package Index 触及的则是这些涟漪之下的水位。Dave 的转身，或许也说明 Swift 生态已经走到一个新阶段：我们仍然需要好的内容策展者，但更需要能让整个生态长期运转下去的基础设施建设者。
近期推荐
轻松理解 Monad (Monads are Easy)
Monad 可能是函数式编程中“名气最大、解释最吓人”的概念之一，但它真正解决的问题，其实只是如何在“带上下文”的值之间，安全、连续地组合计算。Krishna Kotecha 用 Swift 开发者容易理解的方式，通过“仓库扫描书籍”的类比，把 Monad 拆解成了一个极其具体的流程 —— 值是书、容器是箱子、map 是逐个扫描，而 flatMap 则负责拆开嵌套箱子并重新压平成一个统一的箱子。无论是 Optional、Result，还是链式 Optional chaining，本质上都带有明显的 Monad 风格。在 Swift 中，你写下的每一个 ?.，本质上都是一个伪装成语法糖的 flatMap。
Krishna Kotecha 不仅把 Monads 讲得十分直观，文章中的配图也相当出色。这些“拆箱再装箱”的流程图，把
flatMap的核心思想展现得非常形象。
Swift 类型驱动设计：更好的金额格式化 (Type-Driven Design in Swift: Better Money Formatting)
对很多 Swift 开发者来说，Type-Driven Design 往往停留在“避免传错参数”的层面。但在涉及金额、状态机、权限、订单等复杂业务时，类型本身其实也可以成为业务规则与领域约束的一部分。Uwais Alqadri 在本文中，以“金额的原始值与展示值必须分离”为切入点，讨论了为什么金融类应用不应直接使用 Double 或格式化后的展示文本参与金额计算。文章不仅通过多个实际案例说明了不同 locale、货币精度与 rounding rule 带来的潜在问题，也进一步引出了 Type-Driven Design 在业务建模中的价值。
AndroidX ViewModel 是 KMP 项目的最佳选择吗？(Is AndroidX ViewModel the best choice for KMP projects?)
对于 Swift 开发者来说，ViewModel 通常只是一个承载视图状态与交互逻辑的对象。在 SwiftUI 中，它可以是一个 @Observable 类型，也可以只是一个围绕 View 状态组织起来的普通引用类型；任务生命周期往往交给 .task、视图层级或其他更贴近 SwiftUI 的机制处理。但当 Swift 开发者进入 Kotlin Multiplatform 或 Android 生态时，很容易低估 AndroidX ViewModel 所承担的职责：它不仅是 MVVM 中的“ViewModel”，同时也是 Android 生命周期、ViewModelStore 与 coroutine scope 的一部分。
Gustavo Fão Valvassori 从 Android ViewModel 的历史背景讲起，解释它为何会与 Activity / Fragment 的重建、配置变化和 viewModelScope 深度绑定，并进一步讨论当这一套机制被带入 KMP 项目后，在 iOS 原生 UI 中可能产生的摩擦。对于 Swift 开发者而言，文章最有价值的地方并不在于是否应该直接采用 AndroidX ViewModel，而是帮助我们理解：同样叫作 ViewModel，在不同平台上可能承载着完全不同的架构责任。
如何优雅地废弃自定义兼容 API (Deprecating your own convenience API)
为了兼容不同的系统版本，或为新旧系统提供一致的行为与体验，开发者通常会通过统一封装、为旧系统补齐兼容实现，或者用自定义 modifier 抹平不同系统之间的行为差异。但随着应用最低支持版本不断提高，其中很多代码最终都会悄悄变成没人敢删的“死代码”。Majid Jabrayilov 以一个非常典型的 SwiftUI 场景为例，利用 @available(..., deprecated:, obsoleted:) 标记这些“过渡 API”的生命周期。当最低部署版本提升后，编译器会自动将这些兼容层标记为 warning 甚至 error，从而提醒开发者及时移除。
某种意义上，
@available不仅是在管理 API 的可用性，也是在管理“技术债的保质期”。
让 SwiftUI View 在截图中隐藏
SwiftUI 一直缺少一个看似简单、但其实相当实用且底层的能力：让某个 View 在屏幕上正常显示，但在截图、录屏、投屏或其他系统捕获路径中被隐藏。公开 API 提供的更多是“捕获状态检测”，而不是真正意义上的捕获隐私保护。OpenSwiftUI 的开发者 Kyle Ye 从公开 API、secure UITextField 技巧、CALayer.disableUpdateMask 私有行为，一路分析到 SwiftUI 内部 DisplayList 与 RendererEffect 的工作机制，最终实现了一个真正 SwiftUI 风格的视图扩展。它不需要把 SwiftUI 内容塞进 secure text field subtree，而是直接利用 SwiftUI 内部已经存在的 screencaptureProhibited rendering property，将对应 layer 从 capture output 中移除。
Windows 平台 Swift 公共符号服务器上线 (A Public Symbol Server for Swift on Windows)
The Browser Company 近日公开了 Swift on Windows 的 Symbol Server。通过该服务，开发者可以在 WinDBG、Visual Studio、Windows Performance Analyzer 等 Windows 原生调试工具中，直接获取 Swift Runtime 与标准库的 PDB 符号文件，从而获得完整的符号化调用栈与更清晰的崩溃分析能力。
这篇文章真正有趣的地方，并不仅仅是如何配置 Symbol Server，而是它系统梳理了 Swift 在不同平台上的调试基础设施：从 Mach-O、ELF、PE/COFF 等对象文件格式，到 DWARF 与 PDB/CodeView 两套调试信息体系，再到 Darwin、Linux 与 Windows 在 symbol 管理上的不同设计。对于长期只在 Apple 平台开发的 Swift 开发者来说，这篇文章会让你第一次比较直观地意识到：Swift 想真正成为跨平台语言，仅仅“能够编译运行”远远不够，它还需要深入融入目标平台原生的调试体系与工具链生态。
在 AI 容器中用 Swift 替代 Bash (Replacing Bash with Swift in an AI Harness)
随着 AI Agent 工具的发展，“让模型执行代码”正在逐渐从简单的 terminal 调用演变成新的运行时设计问题。这篇文章记录了一个相当有趣的实验：Alejandro Martinez 尝试在 AI Harness 中，用可嵌入的 Swift 解释器替换 Bash，让模型不再生成 shell script，而是直接生成并执行 Swift 代码。结合 SwiftScript 与 ShellKit，展示了如何通过嵌入式解释器、受控工作目录与 sandbox，为 LLM 提供一个更可控的 Swift Runtime。
SwiftScript 是一个相当有意思的实验性项目，由 Oliver Drobnik 创建：一个完全由 Swift 编写、可嵌入应用的 Swift 解释器。它基于
swift-syntax解析并直接执行 Swift AST，而不是通过swiftc编译生成二进制，因此更接近 JavaScriptCore 或 Python Runtime 这类“嵌入式脚本运行时”。
对 SwiftUI 的纠结与期许 (Hanging on the Promise of SwiftUI)
SwiftUI 发布七年后，我们似乎仍处于一种微妙的状态：它已经足够重要，重要到几乎所有 Apple 平台开发都无法绕开它；但它又依然不够完整，很多稍微复杂一点的真实应用，最终仍不得不重新回到 AppKit / UIKit。Patrick McConnell 在这篇文章中，集中表达了他对 SwiftUI 的复杂情绪：它很好，好到让人愿意持续投入；但也正因为如此，当它在扩展性、完整性与底层能力上始终“差一点”时，才会显得格外令人沮丧。
我一直觉得，只有苹果在第一方应用上真正全力、大规模地使用 SwiftUI，SwiftUI 才可能进入更快的成熟期。第三方开发者不应成为框架的小白鼠，而应该优先享受到框架带来的便利与稳定。
工具
App Store & Google Play Screenshots Generator
App Store & Google Play Screenshots Generator 是一个面向 AI coding agent 的商店截图生成 skill，由 Parth Jadhav 开发。它不是简单给你一套截图模板，而是把“收集产品信息 → 组织卖点文案 → 选择视觉风格 → 本地编辑 → 批量导出尺寸”的流程做成了一个可执行工作流。
项目会为当前目录生成一个 Next.js + ShadCN 的本地编辑器，支持拖拽排序、在线修改标题、上传真实截图、切换 iOS / Android 设备，并将项目状态保存为可版本化的 app-store-screenshots.json。它最值得借鉴的地方，是把商店截图明确视为广告素材：每张图只表达一个卖点，优先呈现用户收益、情绪和痛点，而不是机械展示 UI。
对独立开发者来说，这类工具很实用。它不能替代最终的审美判断和平台规则核对，但能把上架截图制作中大量重复、琐碎、容易出错的部分收拢到一个 agent 友好的本地流程里。
Editorio: macOS 原生 Markdown 与代码编辑器
Lovre Crncevic 因为不甘忍受 Electron 编辑器的臃肿，以及各类笔记软件泛滥的订阅制，决定为自己打造一款纯原生的轻量级 Markdown 与代码编辑器。
Editorio 使用 Swift + AppKit 构建原生界面，并使用 Rust 构建底层文本引擎以提升性能，支持 Markdown 实时预览、项目侧边栏、minimap、主题切换，以及多种编程语言的语法高亮。作者表示，Editorio 典型内存占用约 40MB，而冷启动与文件读取则保持在毫秒级响应。某种程度上，它让人重新想起了过去那些“小而快”的经典 Mac 应用。
Lovre 承诺，该应用永久免费，并在 Reddit 上的讨论中表示：等项目代码进一步整理后，他计划将 Editorio 在 GitHub 上开源。
5.1 版本对非英文的输入支持有问题，我已反馈作者。5.2 版本（审查中）中已解决。
活动
2026 年度 Swift 官方导师计划 (Swift Mentorship Program 2026)
Swift Mentorship Program 是 Swift 社区近年来持续举办的一项官方 Mentorship 活动，旨在帮助更多开发者真正参与 Swift 开源生态。项目通过导师配对的方式，让参与者在 10 周时间内，与经验丰富的 Swift 开发者共同完成一次真实的开源贡献：既可以是 Swift 编译器本身，也可以是任意使用 Swift 编写的开源项目。相比单纯的线上教程或 issue 列表，这种“带着新人真正完成一次贡献”的方式，显然更接近真实的开源协作体验。
该项目最早由 Swift Contributor Experience Workgroup 推动，近几年已经逐渐成为 Swift 社区固定活动之一。除了技术学习外，它也承担着降低社区参与门槛、培养新贡献者以及加强社区群体连接的作用。官方还特别鼓励 Women in Swift、Black in Swift 与 Pride in Swift 等社区成员参与其中。
2026 年度活动已经开启，Mentor 与 Mentee 的报名时间分别从 5 月与 6 月开始，7 月正式进入为期 10 周的 Mentorship 周期。
WWDC26 派对之夜：城市、场次和报名信息
WWDC26 主题演讲将于当地时间 06 月 08 日 10 在库比蒂诺举行。
作为连续多年入选 Apple 开发者网站 WWDC 社区活动的 WWDC.playground，由 SwiftGG 发起的 WWDC26.playground 线下观影派对将于北京时间 06 月 08 日晚间至 06 月 09 日凌晨，在北京、上海、广州、深圳、杭州和青岛等多座城市举办。
入场时间和报名费用等形式，在不同城市/场次间可能有所不同，请以实地情况为准。👉 各地报名方式