原生商店审核：Mac App Store、Microsoft Store 与 App Store 的拒绝点

审核等待不是意外，是发布计划里必须预留的一段时间。

一、连续三次被拒，每次三天

以下情境为教学假设，人物、引语和数字不代表经核实的真实案例。

岑舟的 Mac 应用提交了三次。

第一次被拒：审核员打开后看到一个登录页，没有可用账号。他忘了在备注里提供演示账号。
第二次被拒：应用读取了用户选择的文件夹，但没有在隐私清单里声明对应类别。
第三次被拒：描述里写「支持自动整理所有文件」，审核认为实际功能与描述不符。

每次往返三天，三次就是九天。他的发布计划只留了两天缓冲。

三次拒绝都不是产品不能卖，而是提交材料不完整。审核失败的大多数原因，在提交前就能自查。

二、四类商店，四套关注点

同样是原生商店，审核关注点并不相同。

桌面商店与移动商店的严格程度不同。 移动端对隐私、账号删除与内购的检查更细；桌面端更关注沙箱与权限用途，但近年也在收紧。

同一功能在不同商店的判定可能不同。 桌面端允许的站外支付，移动端可能被要求走内购；按最严格的平台设计，减少返工。

同一款产品在不同商店要分别准备材料。 隐私政策 URL、演示账号、功能说明不能一份通用；表单字段与分类方式都不同。

商店政策会变。 去年能过的写法，今年可能被要求补充；把政策链接与检查日期记进发布清单，比记住条款更可靠。

政策更新要有人跟。 订阅商店的开发者公告，或在季度巡检里加一项；等被拒才知道规则变了，成本更高。

三、五类高频拒绝

以下五类覆盖了独立开发者最常遇到的拒绝。

演示账号要长期有效。 审核可能在数周后复查；临时账号过期，会换来一次「无法登录」的拒绝。

账号权限要覆盖审核场景。 演示账号应能看到核心功能，而不是只能进入首页；权限不全等于没给。

隐私申报要与实际采集一致。 少报会被拒，多报会增加用户看到的权限说明；以数据流图为准，逐项核对。

申报表要留底稿。 每次填写的内容与依据存档，下一次更新时只需增量修改；凭记忆重填容易前后矛盾。

账号删除不是加一个链接就够。 需要能真正删除或匿名化数据，并在合理期限内完成；只标记状态通常不够。

数字商品与实体商品的规则不同。 订阅、解锁、虚拟货币通常必须走平台内购；卖周边、卖服务另有规则，须逐条确认。

截图与描述要能被产品验证。 描述里出现的功能，审核员会实际点击；写了但找不到入口，就是夸大。

四、提交材料与时间预算

把材料做成一页清单，每次提交逐项打勾。

提交前清单
  演示账号：用户名、密码、有效期、特殊步骤
  审核备注：一句话说明产品用途与测试路径
  录屏：主流程 30–60 秒，含权限请求
  隐私：政策 URL、数据采集清单、权限用途说明
  账号：删除入口与操作路径
  元数据：截图、描述、关键词与实际功能一致

时间预算
  首审等待 + 重提等待 + 返工天数，按最坏情况排期

审核备注要写「怎么测」。 一句话说明产品给谁用、从哪进入核心功能、有没有需要特殊配置的步骤，能显著减少往返。

录屏比文字更省事。 主流程加权限请求，控制在 60 秒内；审核员不需要读长文档。

重提要针对拒绝理由逐条回应。 只改一处就重提，容易因为同一类问题再次被拒；把拒绝理由拆成条目，逐条给出修改位置。

回应要引用具体条款或截图。 「已经修改」不足以让审核员确认；给出修改位置与验证路径，才能减少往返。

申诉是另一条路径。 认为拒绝有误时可以申诉，但要有明确的政策依据；申诉不改变产品，只改变解释。

被拒后的三条路要提前想好。 改产品、改描述、换分发形态。第三条最贵，但有时比反复重提更快。

五、行动清单与复算验收

• 为每个目标商店列出材料清单与政策链接
• 准备长期有效的演示账号，并写入审核备注首行
• 对照数据流图逐项填写隐私申报
• 确认应用内存在可完成的账号删除路径
• 检查数字商品是否走平台内购
• 用真实截图与可验证的功能描述替换宣传语
• 录制 30–60 秒主流程视频，含权限请求
• 按最坏情况预留审核与重提时间

验收标准：提交前能逐条回答「审核员怎么进入核心功能、数据采集是否全部申报、账号能否删除」。 有一项答不上来，就先别提交。

上线缓冲 = 审核轮次 × 每轮等待天数 + 重提次数 × 返工天数

示例：2 轮 × 3 天 + 1 次 × 2 天 = 8 天

延迟成本 = 缓冲天数 × 示例日收入
若日收入 50 美元，八天缓冲的机会成本约 400 美元

使用边界与实操验收

本文只讲原生商店的审核准备与拒绝点，不涉及浏览器扩展的审核流程，那属于Chrome Web Store 上架：账号、Manifest V3、权限说明与审核拒绝复盘 ；商店账号的注册、角色与找回属于商店开发者账号：Apple、Google、Microsoft 与 Chrome 的团队与找回 。

隐私政策与法律文本的写法属于平台合规：隐私政策、数据最小化、封禁申诉与开源许可 ；商店页素材的排序与版本同步属于第 10 篇；移动端灰度属于第 07 篇。

本文也不主张「所有产品都值得进商店」。直装能更快发布，也少一层审核；商店的价值在于信任与支付，是否值得等待，取决于用户在哪里。

验证以一次通过率为准：连续三次提交，记录拒绝次数与原因分类。若同类原因重复出现，说明提交清单没有真正被执行。

把拒绝原因按五类归档。连续三次都在同一类，说明提交清单里那一项没有被真正执行。

关键参考与核验范围

本文的清单与时间示例为教学演示，实际规则请以各商店当期政策为准。核验日期：2026-10-24。

• App Store Review Guidelines ：Apple 的审核指南全文，含隐私、内购与元数据要求。
• Microsoft Store Policies ：微软商店的应用政策与提交流程说明。

上述两条只用于说明公开政策入口，不构成对审核结果的判断。政策条款会更新，提交前请核对当期版本与产品面向地区。

系列导航

• 上一篇：移动端内测与分阶段发布：TestFlight、封闭测试与 1% 灰度
• 下一篇：版本节奏与回滚：发布列车、兼容窗口与一次撤回
• 回到目录：一个人把软件交付到用户手里：签名、安装、更新与审核
• 相关阅读：Chrome Web Store 上架：账号、Manifest V3、权限说明与审核拒绝复盘 、商店开发者账号：Apple、Google、Microsoft 与 Chrome 的团队与找回