App Store & Play

它是什么

发布一款移动应用不只是写代码：你还得给它签名、打包、提交审核，并发布到 Apple 的 App Store 和 Google Play。每个商店都有自己的开发者账号、签名体系、元数据和审核流程。Apple 使用 App Store Connect，配合预置描述文件（provisioning profile）和用于 Beta 测试的 TestFlight；Google 使用 Play Console，配合应用签名和分阶段发布。这是把一个构建产物变成人们可以安装之物的最后一公里。

优势

• 触达面巨大：这两个商店是数十亿用户发现并信任应用的途径。
• 内置分发、支付、更新和崩溃报告。
• Beta 通道（TestFlight、Play 内部/封闭测试）可实现安全的预发布。
• 分阶段发布，并能在发现问题版本时叫停。

取舍

• 审核可能很慢，偶尔会以政策或准则为由被拒。
• Apple 收取年度开发者费用、Google 收取一次性费用；两者还会从销售中抽成。
• 签名、证书和预置描述文件繁琐且容易配置出错。
• 需要维护两套独立的流水线、元数据集和商店上架信息。

何时使用

每一款面向消费者的移动应用最终都会经历这一步。要尽早规划：预留你的应用名称、配置好两个开发者账号，并接好自动化构建，这样每次发布就不是一次手忙脚乱。

Vibe coding 契合度

这正是 AI 助手最能省去繁琐之处的地方。可以让模型用 Fastlane 或 Expo 的 EAS Submit 之类的工具把发布流程脚本化，让签名、版本号和上传都变成一条命令。让它生成商店元数据、截图规格和发布检查清单，并在出现拒审时用通俗语言解释原因。把重复的部分自动化，把政策上的判断交给人来把关。

# Expo: build and submit to both stores
npx eas build --platform all
npx eas submit --platform ios
npx eas submit --platform android