当 Build in Public 重新转入地下 - 肘子的 Swift 周报 #157
内容提要
AI 大幅降低复刻成本，独立开发者“公开构建”的创意易被抢先克隆，可能迫使大家转向闭门开发，破坏互助氛围。文章还推荐了 SwiftUI 日历性能优化、fastlane 多语言截图排查等实践，并介绍 Redlamp、AnnotateIt、InnoDI、SimAgentation 等 AI 时代新工具。
延伸解读
AI 复刻对独立开发者的实际威胁
文章指出，AI 大幅压缩了复刻所需的时间与成本，模仿者可以跳过试错，快速做出外观和功能相似的版本。对于仍在寻找市场位置的独立开发者，几周甚至几个月的时间差就可能非常重要。这并非理论风险，而是社区中已频繁出现的案例。
Build in Public 氛围可能被破坏
过去，公开分享创意和开发过程帮助独立开发者建立社区、获得反馈。但当公开信息成为别人寻找复刻目标的捷径，分享的风险变了。如果开发者觉得保持沉默更安全，Build in Public 可能变成 Build in Private，失去的是愿意展示不成熟想法并相互启发的交流氛围。
SwiftUI 性能优化的共同原则
两篇关于日历组件的文章都强调：不要让 cell 承担可以在更高层级完成的重复工作。上层准备数据和交互上下文，下层 View 接收稳定、接近最终展示形式的值，与渲染无关的信息不要进入 SwiftUI 的 observation/update graph。这能有效减少主线程的 graph updates 开销。
AI 时代框架设计的新目标
InnoDI 等工具通过显式声明和构建时验证来减少隐式行为。文章认为，当学习成本不再完全由人类开发者承担，“让代码的意图和行为更容易被验证”的重要性正在迅速提高。框架作者需要重新思考消费者，从“让开发者更容易编写代码”转向“让代码更容易被验证”。
Q&A
为什么独立开发者可能不再愿意公开构建（Build in Public）？
因为AI大幅降低了复刻成本，仿制者能根据公开的设计截图和思路快速抢先上线克隆品，导致原创者面临创意被窃取的风险，从而可能转向闭门开发。
AI时代下，UIKit和SwiftUI哪个更适合Coding Agent？
文章指出，UIKit的命令式逻辑直接明确，可能比SwiftUI更适合Coding Agent；但问题不在抽象本身，而在于抽象后需要补齐观察与验证手段。
如何优化SwiftUI日历组件的性能？
优化原则包括：不让cell承担可在更高层级完成的重复工作；上层准备数据和交互上下文，下层View接收稳定值；与渲染无关的信息不要进入SwiftUI observation/update graph。
fastlane snapshot多语言截图全部显示英语，可能是什么原因？
可能原因有五个：setupSnapshot的调用时机、snapshot的启动方式、localize_simulator、App Bundle中是否包含对应的.lproj、残留的App状态是否影响语言设置。
Redlamp是什么？它有什么特点？
Redlamp是一款用Swift和Metal开发的开源macOS RAW照片编辑器，采用MPL-2.0许可证，界面类似Lightroom。作者Pedro Gomes在AI辅助开发中保留了个人判断，如数据库可重建、重要信息保存在照片旁等。
AnnotateIt如何帮助Create ML训练？
AnnotateIt将图片标注、本地训练Object Detector、预测和修正整合在一个Mac应用中，无需配置Python环境或云端GPU，数据保留在本机，降低了尝试本地Object Detection的门槛。
InnoDI是什么？它如何适应AI Coding时代？
InnoDI是一套基于Swift Macro的依赖注入框架，将依赖声明转化为显式声明并生成容器初始化器和测试替换接口。它通过Macro、SPM Build Plugin和CLI验证依赖图，强调让代码意图和行为更容易被验证。
SimAgentation如何辅助AI调整界面？
SimAgentation让开发者在浏览器中操作iOS模拟器，选中界面元素或框选区域并写下修改意见，工具将反馈连同元素信息、源码线索和截图通过MCP交给编码助手，并显示处理状态。
