在宣布 Fuse 版本对独立开发者免费 仅两个月后，Skip Tools 再次做出惊人之举——全面免费并开源核心引擎 skipstone。这意味着 Skip 彻底改变了经营方式：从“卖产品”转向“卖服务+社区赞助”。这次变化，既有对之前商业模式执行不佳而被迫调整的无奈，也体现了 Skip 团队的果敢——在当前 AI 盛行、开发工具格局固化的背景下，主动求变，力求突破。
很多优秀且有特点的产品没能获得应有的使用量，最大的阻碍往往不是技术，而是“信任”。正如 Skip 官方所言，企业最担心的是“rug pull”——万一公司倒闭或被收购，押注在这个工具上的产品和技术栈将面临推倒重来的风险。Skip 希望通过开源消除这种信任危机，让自己和其他跨平台工具站在同一起跑线上，同时激活社区力量，加速生态建设。
尽管社区对 Skip 的开源决定给予了充分肯定，但也有不少人担心：在放弃了 license key 这一稳定收入来源后，仅靠赞助模式能否支撑持续开发成本？毕竟，成功的开源商业案例虽有，但失败的也不少。这种担忧并非杞人忧天。在我撰写本期周报时（宣布开源数天后），尽管开源消息在社交媒体上引发了热议，但在 GitHub 上，Skip 的个人赞助者仅有十几位。从“热闹的讨论”到“真金白银的支持”，中间的鸿沟似乎比想象中还要深。这或许也解释了为什么 Skip 最终选择了开源——在无法说服开发者”付费使用”时，至少要争取到他们”免费使用”的机会。
一个有趣的现象是，在肯定与忧虑并存的情绪中，讨论的焦点悄然发生了变化：从“为什么要花钱买 Skip 而不是用免费的 KMP?”变成了“你是更喜欢写 Swift 还是 Kotlin?”。这个转变意义重大——它意味着 Skip 已经成功将竞争维度从“商业模式”转移到了“语言生态”，而参与竞争的主体也从“一家小公司”扩展为“整个 Swift 社区”。在这场语言之争中，Skip 聪明地（或许是无意间）将自己的角色从“主角”变成了“基础设施”。
Skip 最早的出发点是看到了一个商业机会，认为有足够的商业回报。如果不是有这样的预期，仅靠官方或社区的力量，Swift 可能无法快速推进在其他平台上的进展。这一路径与 The Browser Company 为了打造 Arc 浏览器而大力推动 Swift 在 Windows 平台上的适配如出一辙。
作为一个 Swift 开发者，我由衷希望 Skip 的这次调整能够取得预期效果。开源是一场信任的实验，也是一次生态的投资。如果你也期待 Swift 能在 iOS 之外的平台上拥有更多可能，不妨从成为一个独立赞助者($10/月)做起——这不仅是对 Skip 的支持，更是对整个 Swift 跨平台生态的投票。开源的 Skip 能走多远，取决于有多少人愿意从旁观者变成参与者。
原创
isolated(any) 与 #isolation：让 Swift 闭包自动继承隔离域
Swift 6 为并发引入了许多新功能与关键字。虽然其中不少内容在日常开发中可能鲜少用到，但一旦遭遇特定场景，若对这些新概念缺乏了解，即便有 AI 辅助也可能陷入僵局。本文将通过一个在开发测试中遇到的实际并发问题，来介绍如何利用 @isolated(any) 以及 #isolation 宏，实现函数的隔离域继承，从而让编译器自动推断闭包的运行环境。
近期推荐
SwiftData 数据迁移全解析 (A Deep Dive into SwiftData migrations)
随着应用的发展，数据模型几乎无可避免地会出现变化，如何安全地进行数据迁移对很多开发者来说都是一个不小的挑战。在本文中，Donny Wals 全面讲解了 SwiftData 的数据迁移机制，从基础的版本控制到复杂的自定义迁移策略。其中，Donny 给出了几个特别有价值的建议：即使是 V1 版本也应该使用 VersionedSchema 进行封装，为未来的迁移打好基础；只在 App Store 发布周期之间引入新的 Schema 版本，而不是在开发过程中频繁修改；对于轻量迁移，即使 SwiftData 可以自动完成，也建议显式地写入 SchemaMigrationPlan 中，使意图更加明确且易于测试。
文章的一大亮点是详细解释了 MigrationStage.custom 中 willMigrate 与 didMigrate 的适用场景，并提出了应对复杂重构（例如拆分实体）的“桥接版本（Bridge Version）”策略。
为什么 MVVM-C 在 SwiftUI 项目中依然能扩展 (Why MVVM-C with Coordinators does Scale -> A real-world SwiftUI perspective)
尽管标题中包含“MVVM-C”，但这并非一篇单纯为某种架构模式辩护的文章。Bruno Valente Pimentel 在文中重新定义了“扩展性”的内涵——它不应仅以屏幕或文件的数量来衡量，而应看其是否支持高效的多人协作及功能的独立演进。正如作者所言：“架构无关乎模式，而关乎减少恐惧”——减少修改代码、团队协作以及功能演进时的恐惧。
无论你倾向于哪种架构模式，在用它构建 SwiftUI 项目时，都应该认真思考：我们到底是在利用 SwiftUI 的特性，还是在试图把 SwiftUI 改造成我们熟悉的 UIKit？
TCA 架构的真实评估 (TCA (Composable Architecture): The Honest Review)
继 Bruno 为 MVVM-C “正名”后，Chandra Welim 对另一个极具争议的架构——TCA 进行了客观评估。作者总结了 TCA 的五大优势（可预测的状态管理、优秀的可测试性、时间旅行调试、组合性、强类型安全）和五大挑战（学习曲线、样板代码、团队采纳、对简单应用过度设计、第三方依赖），同时给出了务实的建议：TCA 是一个强大的工具，但绝非适用于所有场景。对于简单的 MVP 或缺乏函数式编程背景的团队，传统的 MVVM 或许是更务实的选择；而对于状态错综复杂、需要“时间旅行”调试的大型项目，TCA 则能提供无与伦比的掌控力。核心结论：TCA 在你需要时很值得，但大多数应用并不需要它。
架构选择没有银弹，只有在特定上下文中的权衡。
让 C 库在 Swift 中“像原生 API 一样好用” (Improving the usability of C libraries in Swift)
Swift 虽然生来就兼容 C，但直接调用 C API 往往体验不佳——开发者通常需要面对裸指针、手动内存管理以及不符合 Swift 命名习惯的函数。为了获得“原生”体验，开发者不得不编写和维护繁琐的 Wrapper 层。在这篇文章中，Doug Gregor 详细介绍了如何利用 API Notes 和 Clang Attributes 机制，在不修改 C 库实现代码的前提下，“指导” Swift 编译器生成符合 Swift 风格的接口。
这项改进的意义在于，它将“封装 C 库”的成本从逻辑层（编写 Swift 胶水代码）转移到了声明层（编写 API Notes 或添加头文件注解）。这对于 Embedded Swift 的普及至关重要，因为嵌入式开发高度依赖现有的 C 库生态。随着工具链的完善，未来开发者可能只需要给 C 库加几个注解，就能直接在 Swift 中像使用原生库一样调用它。文章还提供了基于正则表达式的自动化脚本，可以为结构化的 C 头文件批量生成 API Notes。
在 Yocto 系统中构建 Swift (Introduction to Building Swift for Yocto)
对于大多数 iOS 开发者来说，Yocto 可能比较陌生，但它是嵌入式 Linux 领域的事实标准——它能够精确控制系统中包含的每一个组件。随着 Embedded Swift 的推进，如何在 Yocto 生态中集成 Swift 成为了一个关键问题。Jesse L. Zamora 详细演示了如何使用近期重获更新的 meta-swift 在 Yocto 系统中构建 Swift 运行环境。文章以 Raspberry Pi Zero 2 为例，从 Docker 环境搭建、Yocto 构建、镜像烧录到实际运行，演示了完整的工作流。
需要注意的是，完整构建过程需要数小时，且要求对 Yocto 构建系统有基本了解。不过，文章提供的 meta-swift-examples 仓库已经包含了 Docker 化的构建环境和一键脚本，大大降低了上手门槛。
meta-swift 是 Swift 语言的 Yocto 层，此前曾长期停滞于 Swift 5.7，但在社区的努力下，目前已支持到 Swift 6.1.3。
让 Xcode 的 DEBUG 构建自动部署到 /Applications (TIL how to auto-move Xcode DEBUG builds to Applications)
开发包含 App Intents 的应用时，你可能遇到过这个问题：App Intents 必须在 /Applications 目录下才能在 Shortcuts.app 中显示。这意味着 DEBUG 构建默认放在 DerivedData 中时，开发者无法测试 Shortcuts 集成。 Carlo Zottmann 曾长期使用复杂的 Post-build 脚本来搬运 App，但他在本文中分享了一个更“原生”的方案——通过三行 .xcconfig 配置让 Xcode 自动将构建产物部署到指定目录，并在清理构建时正确删除已部署的文件。
这个技巧不仅适用于 App Intents 测试，也适用于任何需要将 DEBUG 构建放到特定位置的场景。
用 Swift Charts 构建自定义可交互仪表盘 (Visualise anything with SwiftUI Charts)
如果你需要自定义一个可动画、可交互的环形压力仪表盘（Stress Indicator）的 SwiftUI 组件，你会如何进行？是使用 Shape，还是 Canvas？Kyryl Horbushko 在本文中展示了一个非常有创意的解法——利用 Swift Charts 的 SectorMark，优雅且高效地实现了需求。
Kyryl 的实现打破了我们对 Swift Charts 仅用于“数据可视化”的刻板印象。对于需要开发健康类、金融类复杂 Dashboard 的开发者来说，这是一种极具参考价值的”降维打击”式方案——用数据可视化框架解决自定义 UI 问题，既减少代码量，又获得内置的动画和交互支持。
工具
Commander：兼顾专注与灵活的 AI 编程体验
我喜欢在 macOS 上使用 CLI 工具(Claude Code、Codex)，但原生终端应用的视觉体验实在不敢恭维，因此多数情况下我都在 VSCode 中通过插件来改善体验。然而，VSCode 的一个设计始终让我困扰：即便将 Claude Code 的对话栏最大化，AI 修改文件时仍会自动打开新的文件栏或窗口，打断既有的交互节奏。
Marcin Krzyżanowski 开发的 macOS 原生应用 Commander 给了我一个新的选择。它提供了一个比终端更优的交互界面，同时保护了我的“心流”——文件只在需要时才开启，并能调用系统默认应用查看。Commander 目前支持 Claude Code 和 Codex，内置了 Git worktrees 和 Code diff 支持，且完全免费。它在终端的“专注”与 VSCode 的“灵活”之间，构建了一个绝佳的中间地带。
Oh My Agents: 统一管理所有 AI 编程助手的配置
随着 Claude Code、Cursor、Codex、Windsurf 等 AI 编程助手的涌现，开发者面临着一个新问题：如何管理散落在各个项目中的 prompts、skills 和 rules? 每个 Agent 都有自己的配置规范(CLAUDE.md、CURSOR.md…)，手动复制粘贴不仅低效，还容易导致版本混乱。王巍(onevcat) 开发的 Oh My Agents 提供了解决方案。
核心功能:
- 集中管理所有 AI Agent 配置
- 定义分发规则，一键同步到多个项目
- 双向同步，项目改进可拉回中央库并更新所有关联项目
- 预览变更，避免意外覆盖
注：目前仅支持 macOS (Windows/Linux 开发中)，Beta 期间免费。