Fatbobman's Swift Weekly #120
Skip Goes Open Source: A High-Stakes Bet from “Selling Tools” to “Selling Trust”
Skip Goes Open Source: A High-Stakes Bet from “Selling Tools” to “Selling Trust”
Just two months after announcing that the Fuse edition would be free for indie developers, Skip Tools made another bold move: making its core engine, skipstone, completely free and open source. This decision marks a fundamental shift in Skip’s business model—from selling a product to relying on services and community sponsorships. The change reflects both the pressure of an underperforming commercial strategy and the team’s willingness to take risks. In an era dominated by AI and a largely entrenched developer tooling landscape, Skip chose to actively pivot rather than stand still.
Many technically strong and distinctive products fail to gain traction not because of their technology, but because of a lack of trust. As Skip itself points out, companies fear a “rug pull”: if the vendor shuts down or gets acquired, the products and tech stacks built on top of that tool may need to be rebuilt from scratch. By going open source, Skip aims to eliminate this trust barrier—placing itself on equal footing with other cross-platform tools, while also activating the community to help grow the ecosystem.
That said, while the community has largely praised Skip’s open-source decision, concerns remain. After giving up license keys as a stable revenue stream, can sponsorship alone sustain long-term development? History shows that while some open-source business models succeed, many do not. This concern is hardly unfounded. At the time of writing this issue—just days after the open-source announcement—discussion on social media was lively, yet Skip had only a handful of individual sponsors on GitHub. The gap between enthusiastic conversation and real financial support appears wider than expected. This may also explain why Skip ultimately chose to go open source: if developers cannot be convinced to pay for the tool, at least they might be persuaded to use it.
An interesting shift has emerged amid this mix of optimism and anxiety. The conversation has quietly moved from “Why pay for Skip instead of using free KMP?” to “Do you prefer writing Swift or Kotlin?” This change is significant. It suggests that Skip has successfully reframed the competition—from a debate over business models to one centered on language ecosystems. In doing so, the competitive arena expands from a single company to the entire Swift community. In this language-level contest, Skip has—perhaps intentionally, perhaps not—repositioned itself from a central protagonist to underlying infrastructure.
From the beginning, Skip was driven by the belief that there was a real commercial opportunity with sufficient returns. Without such expectations, it is unlikely that either the company or the community alone could have pushed Swift forward on non-Apple platforms so quickly. This path closely resembles how The Browser Company aggressively promoted Swift on Windows in pursuit of building the Arc browser.
As a Swift developer, I sincerely hope this pivot delivers the results Skip is aiming for. Open source is both an experiment in trust and an investment in the ecosystem. If you, too, hope to see Swift thrive beyond iOS, consider starting by becoming a individual sponsor ($10/month). This is not just support for Skip—it is a vote for the broader Swift cross-platform ecosystem. How far open-source Skip can go ultimately depends on how many people are willing to move from being observers to active participants.
Previous Issue｜Newsletter Archive
📢 Sponsor Fatbobman’s Swift Weekly
Promote your product to Swift & iOS developers across:
- Blog: 50,000+ monthly visitors
- Newsletter: 4,000+ subscribers, 53% open rate
Perfect for developer tools, courses, and services.
Enjoyed this issue? Buy me a coffee ☕️
Original
isolated(any) and #isolation: Letting Swift Closures Automatically Inherit Isolation
Swift 6 introduces many new features and keywords to its concurrency model. While some of them may rarely be used in day-to-day development, lacking an understanding of these concepts can leave you stuck in specific scenarios—even with AI assistance. This article walks through a real concurrency issue encountered during development and testing, demonstrating how @isolated(any) and the #isolation macro can be used to let functions inherit isolation automatically, allowing the compiler to infer the execution context of closures.
Recent Recommendations
A Deep Dive into SwiftData migrations
As apps evolve, changes to data models are almost inevitable, and performing safe data migrations remains a significant challenge for many developers. In this article, Donny Wals provides a comprehensive overview of SwiftData’s migration system, covering everything from basic versioning to complex custom migration strategies. He also shares several particularly valuable recommendations: even a V1 model should be wrapped in a VersionedSchema to prepare for future changes; new schema versions should be introduced only between App Store release cycles, rather than being modified repeatedly during development; and for lightweight migrations, even when SwiftData can handle them automatically, it is still advisable to explicitly define them in a SchemaMigrationPlan to make intentions clearer and easier to test.
One of the highlights of the article is its detailed explanation of when to use willMigrate versus didMigrate in MigrationStage.custom, along with a “bridge version” strategy for handling complex refactors, such as splitting entities.
Why MVVM-C with Coordinators does Scale -> A real-world SwiftUI perspective
Despite the title referencing “MVVM-C,” this is not simply an article defending a specific architectural pattern. Bruno Valente Pimentel redefines what “scalability” really means—arguing that it should not be measured by the number of screens or files, but by how well an architecture supports efficient collaboration and independent feature evolution. As the author puts it, “architecture is not about patterns, but about reducing fear”—the fear of changing code, collaborating with others, and evolving features.
No matter which architecture you prefer, when building SwiftUI apps you should seriously ask yourself: are we leveraging SwiftUI’s strengths, or trying to bend SwiftUI into the shape of UIKit as we know it?
TCA (Composable Architecture): The Honest Review
Following Bruno’s reevaluation of MVVM-C, Chandra Welim offers an objective assessment of another highly debated architecture: TCA. The article summarizes five key strengths of TCA (predictable state management, excellent testability, time-travel debugging, composability, and strong type safety) alongside five major challenges (learning curve, boilerplate, team adoption, overengineering for simple apps, and third-party dependencies). It also provides pragmatic guidance: TCA is a powerful tool, but it is not suitable for every scenario. For simple MVPs or teams without a functional programming background, traditional MVVM may be a more practical choice; for large-scale projects with complex state and a need for time-travel debugging, TCA can offer unmatched control. The core takeaway: TCA is worth it when you truly need it—but most apps don’t.
There is no silver bullet in architecture—only trade-offs in a specific context.
Improving the usability of C libraries in Swift
Although Swift is designed to interoperate with C, calling C APIs directly often results in a poor developer experience—exposing raw pointers, requiring manual memory management, and using naming conventions that feel foreign to Swift. To achieve a more “native” experience, developers often have to write and maintain cumbersome wrapper layers. In this article, Doug Gregor explains how API Notes and Clang Attributes can be used to “guide” the Swift compiler into generating Swift-friendly interfaces without modifying the underlying C library implementation.
The significance of this improvement lies in shifting the cost of “wrapping C libraries” from the logic layer (writing Swift glue code) to the declaration layer (authoring API Notes or adding annotations to headers). This is particularly important for the adoption of Embedded Swift, where existing C libraries are fundamental to the ecosystem. As the toolchain matures, developers may eventually need only a few annotations to use C libraries in Swift as if they were native. The article also provides regex-based automation scripts for generating API Notes in bulk from structured C headers.
Introduction to Building Swift for Yocto
For most iOS developers, Yocto may be unfamiliar, but it is the de facto standard in the embedded Linux world—offering precise control over every component included in a system. As Embedded Swift advances, integrating Swift into the Yocto ecosystem becomes a key challenge. Jesse L. Zamora demonstrates how to build a Swift runtime for Yocto using the recently revived meta-swift layer. Using a Raspberry Pi Zero 2 as an example, the article walks through the entire workflow, from setting up a Docker environment and building Yocto, to flashing the image and running Swift code on the device.
It is worth noting that a full build can take several hours and requires some familiarity with Yocto’s build system. However, the provided meta-swift-examples repository includes a Dockerized environment and one-click scripts that significantly lower the barrier to entry.
meta-swift is the Yocto layer for Swift. It had long been stalled at Swift 5.7, but thanks to community efforts, it now supports Swift 6.1.3.
TIL how to auto-move Xcode DEBUG builds to Applications
When developing apps that include App Intents, you may run into this issue: App Intents only appear in Shortcuts.app when the app is located in the /Applications directory. Since DEBUG builds are placed in DerivedData by default, this makes testing Shortcuts integration difficult. Carlo Zottmann previously relied on complex post-build scripts to move apps around, but in this article he shares a more “native” solution—using just three lines of .xcconfig to have Xcode automatically deploy build artifacts to a specified directory and clean them up properly when builds are removed.
This trick is useful not only for testing App Intents, but for any scenario where DEBUG builds need to live in a specific location.
Visualise anything with SwiftUI Charts
If you needed to build a custom, animated, and interactive circular stress indicator in SwiftUI, how would you approach it—using Shape, or Canvas? In this article, Kyryl Horbushko presents a creative solution by leveraging Swift Charts’ SectorMark to implement the component elegantly and efficiently.
Kyryl’s approach challenges the common assumption that Swift Charts are only suitable for traditional data visualization. For developers building complex dashboards in health or finance apps, this represents a highly instructive “dimensionality reduction” strategy—solving custom UI problems with a data visualization framework, while benefiting from built-in animations and interaction support.
Tools
Commander: A Focused Yet Flexible AI Coding Experience
I enjoy using CLI tools on macOS (such as Claude Code and Codex), but the visual experience of native terminal apps leaves much to be desired, so I usually rely on VS Code extensions to improve the workflow. However, one design choice in VS Code has consistently bothered me: even when the Claude Code panel is maximized, any file modifications made by the AI will still open new editor tabs or windows, disrupting the existing interaction flow.
Marcin Krzyżanowski’s macOS-native app Commander offers a compelling alternative. It provides a more polished interface than the terminal while preserving my “flow”—files are opened only when needed, and system-default apps can be used for viewing. Commander currently supports Claude Code and Codex, includes Git worktrees and code diff features, and is completely free. It occupies a sweet spot between the “focus” of the terminal and the “flexibility” of VS Code.
Oh My Agents: Centrally Managing Configuration for All AI Coding Assistants
With the rise of AI coding assistants like Claude Code, Cursor, Codex, and Windsurf, developers are facing a new challenge: managing scattered prompts, skills, and rules across multiple projects. Each agent has its own configuration format (CLAUDE.md, CURSOR.md, etc.), and manual copying is both inefficient and error-prone. Oh My Agents, created by Wei Wang (onevcat), addresses this problem directly.
Core features:
Centralized management of all AI agent configurations
Rule-based distribution with one-click syncing across projects
Bidirectional sync, allowing project-level improvements to flow back into the central repository
Change previews to prevent accidental overwrites
Note: Currently macOS-only (Windows/Linux support in progress). Free during the beta period.
Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.
Skip 开源：从“卖工具”到“卖信任”的豪赌
在宣布 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 能走多远，取决于有多少人愿意从旁观者变成参与者。
如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 爱发电，Buy Me a Coffee 支持我的创作。
原创
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 期间免费。
Couldn't agree more, considering what if building trust through open-source is actually the only viable long-term strategy for dev tools, despite the financial risk.