应用商店提交与常见驳回原因

首次提交应用商店应在发布前几周进行，而不是等到构建完成当天再提交。这不是因为审核速度慢，而是因为围绕提交所需的账号和元数据工作一再被低估。

账号设置所需时间比审核更长

在提交任何内容之前，必须先拥有开发者账号。对于企业账号，通常需要提供企业注册文件并完成验证，具体可能需要几天到几周，取决于所在司法管辖区以及文件信息匹配的速度。

延误往往源于一些琐碎但可预见的问题：企业名称与注册信息不完全一致，地址格式不被验证系统接受，或法律实体类型需要补充证明材料。这些问题都不难解决，但都会占用日历时间。

这项工作应在项目开始时启动，而不是等到项目结束。它是最常见的发布日期延误原因，而且与开发本身无关。

首次提交被驳回，大多属于以下几类：

审核所需信息不完整。如果应用需要登录，必须提供可用的测试凭据。无法登录的审核人员会驳回提交。如果某个流程需要特定数据或特定设备状态，也必须加以说明。
崩溃或明显缺陷。审核人员会实际操作应用，遇到崩溃就会驳回。
隐私披露缺失或不一致。必须提供隐私政策，且应通过有效网址访问，并与应用实际收集的信息一致。例如，声明不收集任何数据，却请求联系人权限，就是审核人员会检查的不一致之处。
请求权限却没有明显用途。请求位置、相机或联系人权限时，需要提供审核人员认为合理的用途说明，应用内解释文字也必须具体，而不能泛泛而谈。
占位内容。Lorem ipsum、空白页面、无功能按钮、“即将推出”版块。应用商店页面展示的应是完成的产品。
支付处理不符合平台规则。哪些支付必须使用平台自有支付机制，有明确且严格执行的规定。处理错误可能需要重新设计核心流程。
元数据不匹配。截图展示了应用中不存在的功能，或描述承诺了并不存在的功能。

这些问题在提交前都可以避免，而按照这份清单进行一次提交前检查只需一小时。

每个平台、每种语言的应用商店页面都需要准备：

特定设备尺寸的截图最常导致临时赶工，因为制作这些截图需要在相应设备尺寸上运行正常的构建版本。妥善完成这项工作需要一天，仓促处理则会导致应用商店页面无法充分展现产品价值。

在主要平台上，审核通常会在一两天内完成，但具体时间会有所变化，节假日期间也会变慢。请按几天的周期进行规划，并为首次提交至少被驳回一次做好准备——这很正常，并不代表失败；修复问题后重新提交通常会更快。

不要把发布活动安排在提交后的第二天。提交、获得批准，并在准备就绪前暂缓发布——两大主要平台都支持先批准构建版本、之后再发布，从而完全消除时间安排风险。

更新也需要经过审核。对于任何有时效性的内容——例如严重缺陷的修复——都应为审核预留一两天，而不要假设可以立即发布。

还要注意，并非所有用户都会更新。相当一部分用户会长期停留在旧版本上，这意味着服务器端变更必须继续兼容仍在使用的版本，也值得尽早决定将支持这些版本多长时间。