不用 fastlane 也能发布你的应用商店页面
deliver 和 supply 能通过命令行把你的元数据、截图和二进制文件推送到两大商店——免费、开源，只要接入 CI，内容就能一直保持最新。代价是得有人搭建并维护这条流水线：Ruby、Xcode 或 Gradle、一个 Fastfile，还有 UI 测试的持续维护。如果你不想跑流水线，免代码的路径包括商店网页控制台、直接调用商店 API，或是一款能帮你起草页面内容的工具。Mokbi 是真正能完成发布的免代码路径：它设计你的截图和 feature graphic，撰写并把整个页面翻译成 50 种语言，然后通过 Play Developer API 直接推送到 Google Play，同时在 App Store Connect 中为你准备好 App Store 版本，等你提交。不需要 Ruby，不需要 Xcode，不需要 UI 测试。fastlane 之所以是默认答案，是有原因的。它是一个免费的 MIT 许可工具包，其 deliver 动作（别名 upload_to_app_store）可以一条命令把截图、应用预览视频、元数据和二进制文件上传到 App Store Connect。在 Android 这边，supply（别名 upload_to_play_store）做的是同样的事——元数据、截图，以及 APK 或应用包。把它们放进 CI 运行，你的商店页面就会随每次发布重新生成，永远不会和应用脱节。
所以诚实地讲，问题不在于"fastlane 好不好用"——它确实好用。真正的问题是：你想不想自己维护那条让它变好用的流水线，还是宁愿不用流水线就更新商店页面。
deliver 和 supply 到底做了什么
两者都是对官方商店 API 的封装。在幕后，fastlane 调用的其实是你自己也能调用的接口。
deliver（iOS）。上传应用名称、描述、关键词、更新说明、网址、分类和审核信息，以及各语言的截图和预览视频。二进制文件通过苹果的iTMSTransporter上传；元数据通过 App Store Connect API 上传。上传后还可以直接提交审核。supply（Android）。把元数据、截图和 APK 或 AAB 上传到 Google Play，并可以选择发布轨道、推进构建版本。要注意一个坑：上传的截图会替换某个语言现有的截图，而不是追加。
两者都用 API 密钥认证——苹果用 App Store Connect API 密钥，谷歌用服务账号 JSON——所以配置好之后，它们就能在 CI 中无人值守地运行。这正是它的全部吸引力所在：元数据和截图都变成了代码，纳入仓库版本管理，随每次构建发布。
fastlane 真正的成本
fastlane 安装和运行都是免费的。成本在于搭建和维护，而这要用工程师的时间来支付。
- 需要维护的运行环境。fastlane 是一套 Ruby 工具链（Ruby 3.0+），通常用 Bundler 管理。iOS 相关工作需要 Mac 上的 Xcode；Android 那边需要 Gradle。这些都是需要安装并持续打补丁的实打实的基础设施。
- 需要编写的配置文件。
Fastfile定义你的 lane；Deliverfile或 Android 的元数据文件夹保存页面详情。第一次把它调通，通常要花一两天。 - 需要搭建的 CI。自动化只有在流水线里才能发挥价值，这意味着 API 密钥、签名密钥，以及一个配置好并保持正常运行的构建节点。
- 如果使用截图抓取功能，还有持续维护成本。fastlane 的
snapshot通过模拟器里的 UI 测试来按语言抓取截图。这类测试很脆弱：常见的情况是一套设置能顺利跑上几个月，然后一次 UI 变更就打断了整个流程，测试代码得重新适配新的界面状态。snapshot 默认会对不稳定的运行进行重试，这只是掩盖了网络和数据引起的不确定性，而没有真正解决问题。而且原始输出没有文案说明或背景，团队往往还得在另一个工具里完成最终设计。
这些都不是在贬低这个工具。这是一笔诚实的交易：fastlane 把一项反复出现的手工杂活变成了代码，作为回报，你要维护这些代码。对于每周发布、有工程师专门负责发布自动化的团队来说，这笔交易很划算。但对于一年只更新几次页面的独立开发者或 PM 来说，维护这条流水线花费的时间，可能比它省下的时间还多。
不用 fastlane 更新商店页面
如果你不用 fastlane，依然有三种方式把元数据和截图放到商店上。
1. 商店网页控制台
最直白的路径。在 App Store Connect 里你可以手动编辑每种语言，把截图拖进对应尺寸的插槽；在 Google Play Console 里你可以按语言编辑商店页面并上传截图。不用写代码，不需要密钥，没什么要维护的——点点鼠标就行。缺点是完全靠手工，如果要在很多语言里一屏一屏地操作，会很慢也容易出错。一两种语言还好；到了 20 种语言就很痛苦。
2. 直接调用商店 API
两大商店暴露的 API 和 fastlane 调用的是同一套，所以你可以直接编写脚本调用它们，而不必引入 fastlane 的 Ruby 技术栈。苹果的 App Store Connect API 是一个用短期 JWT（ES256，用你的密钥签名）认证的 REST API，提供创建截图集、预留并上传图片字节、修改元数据等接口。谷歌的 Play Developer API 采用"编辑（edits）"模型——你打开一个编辑操作，修改页面内容和图片，然后提交。这能给你完全的控制权，适合搭建自定义的内部管理面板，但你自己要编写并维护这套集成。这比完整的 fastlane 流水线投入更小，但也不是零投入。
3. 帮你起草页面内容的托管工具
另一条免代码路径，是用一款工具帮你生成商店页面内容，剩下要做的只是把它放到商店上。这正是权衡关系发生反转的地方：不再是工程师负责一条流水线，而是 PM 或设计师直接在浏览器里掌控整个页面。你放弃的是 CI 自动化，换来的是完全不需要工程师参与。
Mokbi 的定位——说实话
Mokbi 并不打算取代 fastlane 的 CI 方案。如果你的目标是每次构建都自动重新生成截图、全程无需人工介入，那么 fastlane 流水线才是正确的工具，而且它是免费的。我们面向的是另一种情况：想在不碰 Ruby、Xcode、Fastfile 或 UI 测试的前提下，发布一份精美的商店页面的人。
在浏览器里，你可以设计截图、起草商店文案，并把整个页面翻译成 50 种语言——不需要模拟器，不需要 CI，不需要写代码。一个设计师或 PM 就能从头到尾独立掌控整个营销素材。
最后一公里，Mokbi 也覆盖了。它设计截图和 feature graphic，撰写并把整个页面翻译成 50 种语言，然后通过 Play Developer API 把结果直接推送到 Google Play，同时在 App Store Connect 中准备好 App Store 版本，等你点击提交——苹果要求最终的提交及其审核必须由你自己完成，这是苹果的规则，不是我们这边的缺口。用的正是 fastlane 所调用的那些接口，只是少了那条流水线。
该怎么选
- 每周发布、有工程师、要求零偏差？选 fastlane。它免费、自动化，还能让截图和元数据与应用版本始终保持一致。在这方面没有更好的选择。
- 一年只更新几次页面，腾不出 CI？用网页控制台，或者用一款能帮你起草页面的工具。以这个更新频率来看，维护流水线并不划算。
- 需要编程控制，但不想要 fastlane 的技术栈？直接调用 App Store Connect 和 Play Developer API。
- 希望让设计师或 PM 独立掌控多语言页面？在浏览器里起草、翻译并发布——Mokbi 会推送到 Google Play，并把 App Store 版本准备好，等你提交。
fastlane 凭借免费、自动化，理所应当地占据了主流地位。免代码路径并不是"更好"——它是另一种权衡：你放弃了 CI 自动化，换来的是没人需要为更新一份页面而搭建或照看一条流水线。