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 一键克隆的当下，闭门造车“卖工具”将变得愈发困难。与用户建立真实连接，将“出品方的信誉与社区的信任”转化为不可复制的品牌资产，或许才是未来开发者真正的核心竞争力与护城河。
近期推荐
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 保留静态自定义图标。