社区拒绝档案
收集了苹果App Store和Google Play拒绝循环的最坏情况，作为截图和纯文本，供移动团队学习审查队列的真正成本。
提交规则
1到5张图片加上故事文本。
故事中不允许包含超链接。请使用本地图片。让拒绝痛苦具体有用。
6
种子故事
2
覆盖的商店
最大5个
每个故事的图片数量
《存档》
每个故事都是以文本为主，图像支持，故意不包含外部链接，以便存档仍然可读
"这个应用程序的用户将是谁？"
Adrien提交了版本1.0，苹果在指南2.1，信息需要下停止了审查。没有崩溃报告，没有破坏的功能，也没有在消息中请求二进制修复。唯一的阻塞是苹果希望在审查继续之前获得详细的答案，说明这个应用程序是为谁而设计的。
"App Store上已经有足够的这些应用程序了"
Adrien收到设计-垃圾拒绝，因为苹果认为与类似应用程序相比没有足够的独特价值。审查说该应用程序主要是一个屁声或打嗝应用程序，即使它有区别的功能，苹果也认为该功能足够突出，以至于将整个应用程序视为一个饱和类别中的重复内容。
"构建是好的。拒绝一直从应用程序转移到应用程序周围的文字。"
团队交付了一个干净的构建，然后花了一个多周的时间在元数据的异议中循环。每次重新提交都回答了上一个注释，但下一个回复却关注了另一个短语、截图或说明。没有code被改变。发布日历、新闻窗口和付费推广计划都被审查复制所困扰。
审批邮件到达之前，阻塞就已经出现了。
虽然构建已经通过审批，但发布仍然被阻塞，因为团队认为已经回答了合规提示。发布者必须停止发布，收集法律措辞，更新App Store Connect响应，并再次等待。客户在应用程序实际可用之前就看到发布公告。
"该应用程序需要一个屏幕的权限，但审查人员却将其视为整个产品."
一个狭窄的 Android 权限触发了广泛的政策审查。团队记录了该功能，添加了审查人员的说明，记录了演示路径，并仍然需要从主发布中删除权限以解除对客户的阻塞。最终的构建以降级的工作流方式发布，而团队正在准备更干净的权限分离。
"用户急需的破损结账功能并不是审查队列的紧急事项."
结账功能的bug需要快速修复手机问题，但商店发布进入审查时机却是最糟糕的时刻。支持票数不断上升，而团队只能眼睁睁地看着同样的待处理状态。他们最终在服务器端解决了问题，然后在紧急情况已经烧掉整个周末之后，看到二进制许可证的到来。
避免下一个恐怖故事
Capgo 让 Capacitor 团队能够发送实时更新、回滚故障的发布和目标渠道，而不必等待完整的 App Store 或 Google Play 审核周期。
编辑故事数据，包括一到五个本地图像路径，并打开一个 PR。保留名称匿名，除非您拥有该故事。
