又一个 iOS 发版神器火了:App-Store-Connect-CLI,让 TestFlight 和提审流程终于能命令行化

很多 iOS 开发者都有同一种烦：

发版这件事，本来就已经够碎了，结果还要在 App Store Connect 后台里来回点。

上传包、看构建、配元数据、管 TestFlight、查崩溃、提审、看状态……流程一长，人就容易烦，CI 也很难接得漂亮。尤其是团队一大，或者你同时维护好几个 App，后台点点点这套东西，真的很容易把人劝退。

我最近看到一个挺实用的项目：App-Store-Connect-CLI。

它做的事很直接：把 App Store Connect 常见操作，收进一个可以脚本化、可接 CI/CD、适合终端工作的 CLI 里。

这玩意不是那种“看着很全，真用起来很虚”的仓库。它的方向很明确——就是帮你把苹果发版流程，从“手动后台劳动”变成“可复用命令流”。

这项目到底是干嘛的？

一句话说清：

App-Store-Connect-CLI 是一个面向 App Store Connect API 的命令行工具。

它主打几个关键词：

• 快
• 轻量
• 可脚本化
• 适合终端 / IDE / CI 场景

从 README 能看到，它覆盖的事情很广，核心包括：

• App 列表与信息查看
• 构建上传与构建查询
• TestFlight 分组、反馈、崩溃日志
• 元数据、本地化、截图、视频预览
• 证书、描述文件、Bundle ID
• 提审、校验、提交状态追踪
• Xcode Cloud 工作流触发与查询
• 一整套 release workflow 自动化

如果你平时就在折腾 iOS 自动化，这个项目的味道你一眼就能闻出来：

它不是做“教程展示”，而是做“可落地执行”。

为什么这类工具会越来越值钱？

因为现在大家做 iOS 发布，已经不满足于“能发出去”了。

真正麻烦的是这三件事：

1. 流程太碎

App Store Connect 后台把很多功能都放齐了，但也意味着动作分散。

你今天只是想确认一个构建、看一下 TestFlight 状态、顺手准备提审，最后很可能在多个页面之间反复横跳。

CLI 的价值就在这：

把离散动作串成流程。

2. 团队协作难标准化

手动点后台最怕什么？

最怕“每个人都有自己的手法”。

有人先传包，有人先配 metadata；有人知道去哪里看 build，有人只能临时找。最后流程靠口口相传，一换人就乱。

而命令行工具天然适合沉淀成：

• shell 脚本
• CI 工作流
• 团队 SOP
• 本地一键命令

这比“发版靠记忆”靠谱太多了。

3. 自动化越来越刚需

现在稍微像样一点的团队，都会希望这些事情能自动化：

• 构建完成后自动进入下一步
• TestFlight 分发流程标准化
• 发版前自动校验
• 提审流程尽量减少人工介入

而这个项目最吸引我的地方，就是它并不只给你一堆零散命令，还给了更高层的 workflow 思路。

我觉得它最有价值的几个点

一、从“命令集合”升级成“发版工作流工具”

README 里最值得注意的不是单个命令，而是这类能力：

• asc release run
• asc workflow run
• asc workflow validate
• asc status

这说明作者想做的，不只是“我帮你调几个 API”。

而是：

我帮你把 App Store Connect 这套复杂动作，抽成一条能重复跑的流水线。

对于经常发版的人来说，这比单点功能更值钱。

二、对 TestFlight 场景很友好

很多团队最频繁碰的，其实不是“正式提审”，而是 TestFlight。

比如：

• 看反馈
• 查崩溃
• 管测试组
• 跟踪 build

这项目在这块给得比较全，说明它不是只盯着“上线最后一步”，而是覆盖了开发到分发之间那段最频繁、最琐碎的工作。

三、明显考虑了 CI/CD 和无头环境

这一点很关键。

很多工具在本地能跑，到了 CI 就开始抽风。

这个项目 README 明确提到：

• 支持无交互场景
• 提供 --bypass-keychain 这类处理方式
• 输出格式会根据 TTY / 非 TTY 自动切换
• 可以显式指定 json / table / markdown

这不是花活，这是实战细节。

只要作者开始认真处理这些边角，说明这个工具大概率是真的给工程团队用过，而不是只做给 GitHub 首页看的。

四、文档结构很像“真准备长期维护”的项目

一个 CLI 项目值不值得关注，除了功能，还要看文档和边界。

这个仓库把内容拆得比较清楚：

• Commands
• CI/CD
• Workflows
• API Notes
• Testing
• Contributing

这种结构说明什么？

说明作者并不是只想把它做成一个“爆红一周”的小工具，而是想让它能被别人接着用、接着维护、接着扩。

对开发者来说，这点其实很重要。

它适合什么人？

我觉得这项目最适合下面几类人：

1. 独立开发者 / 小团队

如果你自己就负责开发 + 提审 + TestFlight，那这类 CLI 特别省心。

很多重复动作可以直接收进脚本，少开很多后台页面。

2. 有 CI/CD 需求的 iOS 团队

如果你们已经有自动化构建，希望继续把“上传、校验、提审、状态追踪”往流水线里塞，这项目很值得看。

3. 经常和 App Store Connect 打交道的人

比如发布经理、iOS 工程师、DevOps、负责移动端交付流程的人。

只要你对苹果后台那套流程感到烦，这个项目大概率就对你有帮助。

上手前有几个现实提醒

我还是得泼一点冷水。

这类工具再好，也不是“装上就无脑飞”。

你至少要先接受几个前提：

1. 这是第三方非官方工具

仓库里也写得很清楚，它不是 Apple 官方出品。

这意味着你在团队里落地前，最好先做一轮验证，尤其是权限、稳定性、边界行为这些地方。

2. 认证配置是门槛

App Store Connect 相关工具，最烦的一直不是命令本身，而是认证和密钥配置。

这个项目已经尽量把流程写清楚了，但你真正接进团队环境时，还是要认真处理：

• API Key 管理
• 私钥存放
• 本地与 CI 的认证分离
• 是否走 keychain
• 是否做 repo-local config

这些都属于“项目值不值钱”和“团队能不能稳定用下去”之间的分水岭。

3. 自动化越强，越要先 dry-run

README 里也给了 --dry-run 这种思路，这非常对。

尤其涉及 release / submit 这类动作时，先看计划，再真正执行，永远是好习惯。

自动化不是为了省掉脑子，而是为了把重复劳动机器化。

最后一句

如果你做 iOS 发布已经做烦了，尤其是对 App Store Connect 后台那套点点点流程越来越没耐心，那 App-Store-Connect-CLI 真的值得你看一眼。

它最吸引人的地方，不只是“能不能调用 API”，而是它在努力把整套苹果发版动作，整理成可脚本化、可复用、可接 CI 的工程流程。

这才是命令行工具真正该有的价值。

项目地址：

https://github.com/rudrankriyam/App-Store-Connect-CLI