Fatbobman's Swift Weekly #131
Copyright Walls Demolished by Vibe Coding, and the Developer's New Moat
Copyright Walls Demolished by Vibe Coding, and the Developer’s New Moat
Anthropic recently announced that because its latest model, Mythos, has become “too powerful” at cybersecurity work and software vulnerability discovery—reaching a level the company finds unsettling—it has taken the unusually restrained step of not releasing the model publicly. Access is limited to a handful of critical infrastructure companies within Project Glasswing, and ordinary developers cannot reach it through the API either. (Some analysts have pointed out, of course, that this arrangement also conveniently helps prevent model distillation and locks in enterprise-tier customers.) But even with this “beast” kept on a leash for the moment, the coding capabilities of today’s mainstream AI models are already more than enough to make cloning a product trivially easy.
Last week, a developer on Reddit claimed that he had spent a year “reverse-engineering the SwiftUI API” to build an entirely new Swift web framework. The post was fluent and precise in its terminology, and it drew considerable attention. Paul Hudson soon appeared in the comments and called it out: the so-called “independent research” was in fact little more than a string replacement performed on his MIT-licensed open-source project Ignite—down to the point that the original author’s personal, stylistically distinctive code comments had been preserved verbatim. The entire repository was then squashed into a single commit to erase its history, and the license was illicitly changed to the copyleft GPL. A number of developers in the community suspect that the “reverse-engineering SwiftUI” narrative itself was AI-generated as well. More intriguingly, the author in question was actually a major contributor to Ignite himself—when Vibe Coding has driven the cost of “repackaging a project” close to zero, “I was involved in this” can itself become a rhetorical device for blurring the lines of responsibility.
Around the same time, Vibe Island—a polished macOS menu-bar app for monitoring AI coding agents—was pixel-for-pixel cloned shortly after its release. Although the copycat published its code under the banner of an “open-source alternative,” the impact on the original author’s sales and creative motivation was real and significant. Yet even if the author wished to pursue legal action, he would run into a new problem of the times: in both establishing ownership and enforcing his rights, he might need to prove that his work possesses sufficient human originality and account for the extent of AI-generated content involved—otherwise, he would face considerably greater legal uncertainty.
Indeed, the legal walls protecting code are beginning to crumble on the “ownership side” first. Last month, China’s Copyright Protection Centre officially rolled out a new version of its software copyright registration application and accompanying review rules, which explicitly require the filer to make a notarized personal commitment that “no AI has been used to develop the code, author the documentation, or generate the registration materials,” and the review process now focuses on whether the human intellectual contribution clears the originality threshold required by copyright law. Content without substantive human involvement will struggle to obtain registration. Violators may also be placed on a registry of dishonest filers, with consequences tied to their personal credit records.
This trend is converging with the recent direction of case law in Europe and the United States: if a piece of code is primarily “rewritten or recombined” at high speed by an AI responding to prompts, its chances of obtaining copyright protection drop considerably.
We have to face a harsh truth: “I had a brilliant idea and vibe-coded it into existence” is no longer enough to constitute a business moat. The new paradigm we call Vibe Coding has not only reshaped development workflows and dramatically improved efficiency—it has simultaneously shaken the foundational logic of the software copyright system from three directions at once: the bar for ownership has risen, the burden of proof for infringement has grown heavier, and functional cloning has been quietly normalized.
What makes it all the more disheartening is that, controversial as these clone projects may be, they still rack up no small number of stars on GitHub. That suggests that when the cost of getting something is vanishingly low, moral appeals alone can no longer hold back the rush toward “free equivalents.”
Perhaps, as we noted in Issue 120’s discussion of Skip’s move to go open source—in an era where the cost of implementing code is approaching zero and any app can be cloned at any moment by an AI, building behind closed doors and “selling the tool” will only get harder. Forging real connections with users, and turning “the credibility of the maker and the trust of the community” into brand equity that cannot be copied—this, perhaps, is the true core competency and moat for developers in the years ahead.
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 ☕️
Recent Recommendations
Swift Blog Carnival: Tiny Languages
The Swift community has launched its first Blog Carnival, with April’s theme being Tiny Languages. Christian Tietze invites developers to write about this topic—custom DSLs, result builders, scripting languages, routing rules… any perspective related to “tiny languages” is welcome. The submission deadline is May 1.
So far, three entries have been published:
Matt Massicotte reflects on his journey from Rake to Make, and then to various Swift-based task runners, noting that he still hasn’t found an ideal replacement
Chris Liscio shares the design of Capo’s embedded DSL, used to describe keyboard and MIDI bindings, built on Point-Free’s
swift-parsinglibraryNicolas Zinovieff presents an experimental symbolic math DSL, leveraging protocols and operator overloading to make expressions like
(1 + 2 * "X") * (3 - "Y")valid Swift code, with lazy evaluation when concrete values are provided—implemented in under 300 lines
Indicating Selection in macOS Menus Using SwiftUI
SwiftUI provides several components for representing selection, such as Picker, Toggle, and Menu. However, clearly guiding users through choices and accurately reflecting the current selection is not as straightforward as it may seem. Gabriel Theodoropoulos starts from basic Button implementations and gradually evolves toward Picker and Toggle, systematically outlining common approaches and their limitations.
The value of this article lies not in presenting a “single correct solution,” but in reminding developers that SwiftUI’s standard components do not automatically guarantee the best user experience. In practice, you still need to balance system consistency and implementation flexibility.
Building List Replacement in SwiftUI
Choosing between List and ScrollView + LazyStack remains a common challenge for SwiftUI developers. In this article, Majid Jabrayilov rebuilds parts of his CardioBot app using the SwiftUI Container View API (iOS 17+), creating three reusable components—ScrollingSurface, DividedCard, and SectionedSurface—as a replacement for List.
These components closely mirror the usage of List + Section, while eliminating constraints tied to List, such as listRowBackground and listItemTint.
Listis not just a “styled LazyVStack”—the two differ fundamentally in architecture, scrolling behavior, integration with navigation containers, and performance on large datasets. For a deeper comparison, see this previous article.
AppIntents meet MCP
While many still see AppIntents as a companion to Siri and Shortcuts, Florian Schweizer explores a more forward-looking direction: exposing AppIntents as MCP (Model Context Protocol) tools, enabling LLMs to directly interact with your app’s capabilities.
Based on SwiftMCP, Florian uses macros to build an MCP server and seamlessly maps AppIntents into MCP tools. This allows AI agents to invoke app functionality directly, enabling cross-app automation.
Rumors have suggested since last year that Apple is bringing MCP support into its ecosystem. Perhaps we’ll get answers at WWDC 26 in a couple of months.
Ride the Lightning Air: Building Interactive WidgetKit Widgets
Many developers are misled by WidgetKit documentation, mistakenly treating AppIntentTimelineProvider as the key to interactive widgets. In reality, it is designed for user-configurable widgets (e.g., editing options via long-press), not for interactivity.
The actual foundation for interactive widgets remains TimelineProvider. Wesley Matlock demonstrates the correct approach through a fictional airline widget: Using TimelineProvider + Button(intent:) + App Group shared storage to build interactive widgets.
The data flow forms a clean loop: User action → Intent execution → State update → Widget reload → UI refresh
File Storage and iCloud: A Complete View from Local to Cloud
In iOS and macOS development (and usage), file storage is often treated as a basic capability—but it actually defines the lifecycle and behavior of your data.
In Working with files and directories in iOS, Natascha Fadeeva systematically explains the App Sandbox structure and the roles of Documents, Library, and Caches, helping developers understand where different types of data should reside—and how to avoid unnecessary iCloud backups.
Meanwhile, Howard Oakley in Understanding and Testing iCloud explores what happens next: iCloud is not a single service, but a collection of subsystems such as CloudKit, iCloud Drive, and system update services. Different types of data follow different synchronization and backup paths.
File placement is not just an organizational concern—it defines whether data is backed up, synchronized, and how it flows across devices.
As a result, iCloud issues are rarely just about “whether sync is enabled.” They often involve multiple layers, including client state, network conditions, caching behavior, and server-side throttling.
Tools
Bad Dock: Animate Your Dock Icon
This is a “ridiculous yet serious” macOS experiment. Eric Martz uses the public NSDockTile / NSDockTilePlugin APIs to bypass the squircle constraints introduced in Big Sur and render a video stream directly inside a Dock icon.
The implementation is straightforward but well-structured: decoding video with AVAssetReader, reducing frame rate to ~12fps, and managing memory with a ring buffer. The result is a polished technical proof-of-concept built from what initially seems like a playful idea.
The real value of projects like this lies not in their functionality, but in revealing that system API boundaries often extend far beyond what the documentation suggests.
Note: This project implements runtime dynamic Dock icons (continuously rendered while the app is running). After the app exits, only a static custom icon can be preserved via NSDockTilePlugin.
Thanks for reading Fatbobman’s Swift Weekly! This post is public so feel free to share it.
被 Vibe 摧毁的版权壁垒，与开发者的新护城河
Anthropic 不久前宣布，由于其最新模型 Mythos 在网络安全与代码漏洞挖掘方面的能力“过于强大”，已达到令人不安的程度，因此采取了极为罕见的克制措施：仅向 Project Glasswing 内的少数关键基础设施企业开放，不面向公众发布，普通开发者也无法通过 API 调用（当然，也有分析者指出，这一安排同样有助于防止模型蒸馏，并锁定企业级客户）。但即便这头“猛兽”被暂时按住，当前主流 AI 模型的代码能力，已经足以让复制一款产品变得轻而易举。
上周，Reddit 上一位开发者宣称，自己花了一年时间“逆向 SwiftUI API”，打造了一个全新的 Swift Web 框架。帖子行文流畅、术语考究，一度吸引了不少关注。但 Paul Hudson 很快现身评论区打假：所谓“独立研发”，实际上只是将他的 MIT 开源项目 Ignite 做了简单的字符串替换，甚至连原作者带有个人风格的代码注释都原封不动保留，随后将整个仓库压缩为一次提交以抹除历史，并违规改为具有传染性的 GPL 协议。社区中不少开发者都怀疑，这套“逆向 SwiftUI”的叙事本身也是由 AI 生成。更耐人寻味的是，该作者本就是 Ignite 的主要贡献者之一——当 Vibe Coding 将“重新打包一个项目”的成本降至极低时，“我参与过”本身也可能成为一种模糊责任边界的话术。
几乎在同一时间，macOS 上精致的 AI 工作状态监控应用 Vibe Island 在发布后不久便遭遇了像素级仿制。尽管仿制者打着“开源替代品”的旗号公开了代码，这依然对原作者的商业销售与创作热情造成了明显冲击。然而，即便作者希望采取法律手段，也将面临一个新的时代难题：在确权与维权过程中，他可能需要证明其作品具备足够的人类独创性，并说明 AI 生成内容的参与程度，否则将面临更高的不确定性。
事实上，代码的法律壁垒正从“确权端”开始松动。上个月，中国版权保护中心正式启用新版《计算机软件著作权登记申请表》及相关审查新规，明确要求经办人实名承诺“未使用 AI 开发编写代码、撰写文档或生成登记材料”，并在审查中重点评估人类智力投入是否达到著作权法所要求的“独创性”门槛；缺乏实质人类参与的内容，将难以获得确权。违规者还可能被纳入失信名单，并与个人征信挂钩。
这一趋势也与欧美近期的判例方向趋于一致：如果一段代码主要由 AI 根据提示词快速“改写或重组”生成，其获得著作权保护的可能性将显著降低。
我们必须承认一个残酷的事实：“我有一个绝妙的 Idea，并把它 Vibe 成代码”，已经不足以构成商业壁垒。这种名为 Vibe Coding 的新范式，不仅改变了开发流程、显著提升了效率，也从三个方向同时动摇了软件版权体系的基础逻辑：确权门槛提高、侵权举证变难、功能复刻被默许。
令人遗憾的是，即便这些克隆项目饱受争议，它们依然在 GitHub 上收获了不菲的 Star。这说明，在获取成本极低的前提下，仅靠道德呼吁，已经很难阻止人们对“免费平替”的追逐。
或许，正如我们在 第 120 期周报中讨论 Skip 的开源举措 时所提到的那样——在代码实现成本趋近于零、应用随时可能被 AI 一键克隆的当下，闭门造车“卖工具”将变得愈发困难。与用户建立真实连接，将“出品方的信誉与社区的信任”转化为不可复制的品牌资产，或许才是未来开发者真正的核心竞争力与护城河。
如果您发现这份周报或我的博客对您有所帮助，可以考虑通过 爱发电，Buy Me a Coffee 支持我的创作。
近期推荐
Swift Blog Carnival: Tiny Languages
Swift 社区正在发起第一届 Blog Carnival，四月的主题是 Tiny Languages。Christian Tietze 邀请开发者围绕这一主题撰写博客：自定义 DSL、Result Builder、脚本解析器、路由规则……任何与“微型语言”相关的思考都可以作为切入点，截止日期为 5 月 1 日。
目前已有三篇投稿：
Matt Massicotte 回顾了他 从 Rake 到 Make，再到各类 Swift 任务运行器的探索历程，坦言至今仍未找到理想替代品
Chris Liscio 分享了 Capo 应用内置 DSL 的设计：用于描述键盘与 MIDI 绑定，基于 Point-Free 的
swift-parsing库构建Nicolas Zinovieff 则展示了一个 符号数学 DSL 的实验：通过协议与运算符重载，让
(1 + 2 * "X") * (3 - "Y")成为合法的 Swift 表达式，并在提供具体值时惰性求值，核心实现不超过 300 行
在 macOS 菜单中清晰显示当前选中状态 (Indicating Selection in macOS Menus Using SwiftUI)
SwiftUI 提供了不少用于表达选择的组件，例如 Picker、Toggle、Menu，但如何清晰地引导用户进行选择，并准确标识当前选中项，并没有想象中那样理所当然。Gabriel Theodoropoulos 从最基础的 Button 出发，一步步演进到 Picker 与 Toggle，系统梳理了几种常见方案及其各自的局限。文章的价值不在于给出“唯一正确解”，而在于提醒开发者：SwiftUI 提供的标准组件，并不会自动带来最佳的用户呈现效果。很多时候，你仍需在“系统一致性”与“实现自由度”之间做出权衡。
构建 List 的替代组件 (Building List replacement in SwiftUI)
如何在 List 与 ScrollView + LazyStack 之间做出选择，一直是困扰不少 SwiftUI 开发者的问题。在本文中，Majid Jabrayilov 在重构其 CardioBot 应用时，选择基于 SwiftUI 的 Container View API（iOS 17+）构建了三个可复用的 UI 组件：ScrollingSurface、DividedCard、SectionedSurface，以替代 List。这些组件在使用方式上与 List + Section 高度相似，但彻底摆脱了 listRowBackground、listItemTint 等仅在 List 中生效的限制。
List并非只是“有默认样式的LazyVStack”——两者在底层架构、滚动控制、与导航容器的协同、以及大数据集下的性能表现上均有本质差异。如何在两者之间做出综合判断，可以参考这篇旧文。
AppIntents meet MCP
当大家还在将 AppIntents 视为 Siri 与快捷指令的“配套工具”时，Florian Schweizer 给出了一个更值得关注的方向：将 AppIntents 直接暴露为 MCP（Model Context Protocol）工具，从而让 LLM 能够调用你的应用能力。Florian 基于 SwiftMCP，通过宏构建 MCP Server，并将 AppIntents 无缝映射为 MCP Tools，使 AI Agent 能够直接调用应用中的 Intent，实现跨应用自动化。
去年便有传闻，苹果正在为其生态系统引入 MCP 支持。或许再过两个月，在 WWDC 26 上答案便会揭晓。
创建交互式小组件 (Ride the Lightning Air: Building Interactive WidgetKit Widgets)
很多开发者都会被 WidgetKit 的文档误导，错将 AppIntentTimelineProvider 视为实现交互按钮的关键——实则不然。它是为“用户可配置 Widget”（如长按后编辑设置项）准备的，与交互行为并无直接关系。而真正用于实现交互（按钮点击触发行为）的，依然是最基础的 TimelineProvider。Wesley Matlock 通过一个虚构航空公司的登机状态 Widget，完整演示了正确路径：使用 TimelineProvider
Button(intent:)+ AppGroup 共享存储来构建交互式 Widget。整个数据流形成一个清晰的闭环：用户操作 → Intent 执行 → 状态写入 → Widget 刷新 → UI 更新。
文件存储与 iCloud：从本地到云端的完整认知
在 iOS / macOS 开发和使用中，文件存储往往被当作“基础能力”，但它实际上直接决定了数据的生命周期与系统行为。
在 Working with files and directories in iOS 一文中，Natascha Fadeeva 系统梳理了 App Sandbox 的结构，以及 Documents、Library、Caches 等目录的职责划分，帮助开发者建立“什么数据该放在哪里”的基本认知，并说明如何避免无关文件被 iCloud 备份。
而 Howard Oakley 撰写的 Understanding and Testing iCloud 则从系统层面揭示了这些数据的“后续命运”。iCloud 并非单一服务，而是由 CloudKit、iCloud Drive、系统更新等多个子系统组成，不同数据类型对应不同的同步与备份路径。
文件的存储位置，并不仅仅是组织问题，更是在定义它是否会被备份、同步，以及在设备之间如何流转。
因此，iCloud 问题往往不是“是否开启同步”这么简单，而是涉及客户端、网络、缓存以及服务端限流等多个环节。
工具
Bad Dock: 让你的 Dock 图标动起来
这是一个“离谱但严肃”的 macOS 实验项目。Eric Martz 利用公开的 NSDockTile / NSDockTilePlugin API，绕过 Big Sur 之后 Dock 图标的 squircle 限制，将视频流直接渲染进 Dock 图标。实现思路并不复杂，但非常完整：使用 AVAssetReader 解码视频、主动降帧至约 12fps、通过 ring buffer 控制内存占用，最终将一个“整活想法”打磨成了结构清晰的技术验证。
这类项目的价值不在功能本身，而在于展示：系统 API 的边界，往往比文档写得更远。
补充说明：该项目实现的是运行时动态 Dock 图标（应用运行时持续绘制）；应用退出后，仅能通过 NSDockTilePlugin 保留静态自定义图标。