最近几档苹果相关播客不约而同吐槽同一件事：Xcode太难用，苹果应该为“vibe coding”——也就是用Claude Code这类LLM工具直接生成代码——把界面改得更好懂。独立开发者Scott Willsey看完只回了一句：我不明白你们为什么还要打开Xcode。他在博客里给出一套完整方案：Xcode.app必须装在电脑里，但从归档、签名、公证到装机安装，全程可以只靠命令行和一个自己写的脚本完成，图形界面只在最初配置账号和证书时用一次。
这套流程听起来像小众技巧，实际上xcodebuild、notarytool、stapler、devicectl都是苹果自己文档化的标准命令行工具，公证服务甚至早在2023年11月1日就正式停止接受旧工具altool的提交，逼所有人转向notarytool——命令行这条路苹果铺了不止一年。真正值得追问的是另一件事：原文标题把Mac和iOS并列成“一个脚本搞定”，但公证和装订这套机制，本来就只属于Mac。
一次性设置换来永久免开Xcode
Willsey的方案有两层。第一层是XcodeGen：用一个project.yml描述项目结构，每次构建前自动重新生成.xcodeproj文件夹，只有YAML文件进git，省掉Xcode不断改写工程文件引用给版本控制带来的老麻烦。
第二层是身份和权限，这部分绕不开图形界面：登录Apple开发者账号、创建一张Developer ID Application证书、用notarytool交互式存一次公证凭据。证书对应的私钥会连同证书一起装进登录钥匙串，且无法重新下载，丢了就得重新申请。
- 结论.这套脚本真正的价值不是绕开苹果，而是把苹果早已写好的命令行工具喂给LLM agent，配上一份CLAUDE.md，Claude Code就能照着标准流程自己执行整条链路，不用每次都问一遍怎么做。
Mac和iOS不是同一套发布逻辑
这是原文标题最容易让人误解的地方。notarytool公证和stapler装订，只服务于要分发给别人、又不走Mac App Store的.app，目的是让Gatekeeper放行。iOS应用完全走不到这一步——苹果官方文档明确写着iOS/iPadOS应用不需要也不应该公证或装订。
脚本里出现的devicectl，作用也只是把开发签名的app装到你自己连着的手机上做调试，跟“发布给用户”是两码事。真正把iOS应用交到别人手里，还是要走provisioning profile加App Store Connect提交、审核这条老路，release.sh这条流水线并不覆盖这一段。
公证和装订是Mac软件的通行证，iOS用的是另一本护照。
流程里删不掉的人工步骤
这套“无头”流水线也不是完全无人干预。notarytool store-credentials必须交互式跑一次，手动粘贴一个App专用密码，没有脚本能替你做这一步。密码改过之后，公证会静静报401错误，多半不是脚本坏了，而是密码该换了。
日常调试常用的CODE_SIGNING_ALLOWED=NO能快速编译不签名的版本，适合CI跑一遍看能不能编过，但这类构建绑不上iCloud KVS、App Groups这些entitlements，拿去发布是错的。签名之后的.app也不能再改动内容，改了公证大概率失败；ZIP包更不能直接装订，标准做法是先签名App、公证、装订，再打进DMG，DMG本身也要重新公证、装订一遍。
- 风险.一次性人工步骤删不掉——机器丢失或钥匙串损坏，等于要重新走一遍GUI流程，“再也不用打开Xcode”的承诺打了折扣。
谁该在意，接下来看什么
对用Claude Code之类工具做“vibe coding”的独立开发者，这套思路值得抄：把release.sh和一份CLAUDE.md放进仓库，agent照着执行就能完成Mac应用的整条发布链，不用每次都手把手教。维护Mac CI/CD管线的工程师则要留意altool已经停用这件事——如果老流水线还在用它提交公证，早晚会失效。
对真正要把应用送进App Store的团队，这条命令行流水线只覆盖了一半：Developer ID分发和本机安装之外，provisioning profile和App Store Connect提交这一步依然绕不开。接下来更值得盯的，不是苹果会不会把Xcode界面改得更友好，而是它会不会进一步收紧notarytool、devicectl这类自动化调用的门槛——毕竟这些工具现在正被越来越多LLM agent直接当作命令在跑。