社区拒绝档案
收集了苹果App Store和谷歌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。保留名称匿名，除非您拥有该故事。
