冻结并测试候选版本
选择版本号和构建标识符，然后从干净的源修订版中创建候选版本。测试首次启动、完成一轮、设置、保存恢复、中断和恢复以及全新安装。验证预期屏幕尺寸和方向上的每个控件。如果问题需要更改代码，请重建并针对新工件重新运行受影响的检查；不要假设调试版本等同于候选版本。
收集您的列表所需的材料：应用程序名称、描述、当前版本的屏幕截图、年龄和内容答案、支持联系人、隐私披露以及任何应用程序内购买信息。确认商店的当前规则和目标要求适用于此特定版本。避免将计划基于固定的审核持续时间或旧的 API 截止时间。
使用平台的分阶段提交路径
对于 Google Play，在 Play Console 中创建应用、完成控制台设置、上传 Android App Bundle，并选择合适的测试或发布轨道。文档指出包名是唯一且永久的，因此首次上传前就要确定。安排上线日期前，先在控制台查看当前目标 API 和测试要求。
对于 Apple，请在 App Store Connect 中创建应用程序记录，选择版本，完成所需的元数据，然后提交以供应用程序审核。 TestFlight 可以分发 beta 版本并在发布前收集反馈。 Apple 将向提交添加构建与实际提交进行了区分；检查提交状态并确认最终操作已完成，而不是假设上传已在审核中。
使发布可重复
将发布构建文件、源代码版本、构建设置、变更日志和提交备注保存在一起。记录每家商店当前上线的版本。如果也发布网页版本，要分别测试其托管地址访问流程和手机浏览器布局。
关于发布手机游戏的常见问题
我应该同时发布两个移动平台吗？
仅当构建和提交都准备就绪时。独立平台的审查和发布步骤可能会有所不同，因此请明确说明可用的版本，并将其注释与平台相关联。
同一个测试清单可以涵盖网页游戏和商店应用吗？
一些游戏检查可以共享，但打包、安装、权限、更新和审核步骤有所不同。保持常见的游戏冒烟测试以及特定于平台的发布检查。
延伸阅读
发现信息过时了？ 报告需要更正的内容