社区拒绝存档
收集苹果App Store和Google Play拒绝循环的最坏部分，作为截图和纯文本，供移动团队学习审查队列真正的成本。
提交规则
1到5张图片加上故事文本。
故事中不允许内链。只使用本地图片。保持拒绝痛苦、具体和有用。
6
已种子故事
2
覆盖的商店
5个最大
每个故事的图片数量
The archive
每个故事都是以文本为首，图像为辅，且故意避免外部链接，以确保存档始终可读。
"这个app的用户将是谁？"
Adrien提交了版本1.0，苹果在指南2.1，需要更多信息下暂停了审查。没有崩溃报告，没有破坏的功能，也没有要求二进制修复的消息。唯一的阻塞就是苹果想要一个详细的答案，说明这个app是为谁而设计的，才能继续审查。
"There are already enough of these apps on the App Store."
阿德里安因苹果没有看到与类似应用程序相比的足够独特价值而获得了设计 - 垃圾拒绝。审查结果表明该应用程序主要是一款屁声或打嗝应用程序，即使它具有区别它的功能，苹果也认为该应用程序的主要功能足够突出，以至于苹果将整个应用程序视为一个饱和类别中的重复内容。
"The build was fine. The rejection kept moving from the app to the words around the app."
The team shipped a clean build, then spent more than a week cycling through metadata objections. Each resubmission answered the previous note, but the next reply focused on another phrase, screenshot, or explanation. No code was changed. The launch calendar, press window, and paid acquisition plan were all held hostage by review copy.
"审批邮件到达之前，阻塞就已经来了。"
构建已经通过审批，但由于团队认为已经回答的合规提示，发布仍然被阻塞。发布负责人必须停止发布，收集法律文本，更新 App Store Connect 回复，并再次等待。客户在应用实际可用之前就看到发布公告。
"该应用程序需要屏幕上的一个权限，但审查人员却将其视为整个产品。"
一个狭窄的Android权限触发了广泛的政策审查。团队记录了该功能、添加了审查人员的指示、记录了演示路径，但仍然需要从主发布中删除权限才能解除客户的阻塞。最终的构建以降级的工作流程发布，而团队正在准备更干净的权限分离。
"The broken checkout was urgent for users, but not urgent for the review queue."
A checkout bug needed a fast mobile fix, but the store release entered review at the worst possible time. Support tickets climbed while the team watched the same pending status. They eventually mitigated the issue server-side, then watched the binary approval arrive after the emergency had already burned through the weekend.
Avoid the next horror story
Capgo 让 Capacitor 团队能够实时发送更新、回滚错误的发布以及针对特定渠道而不必等待完整的 App Store 或 Google Play 审核周期。
编辑故事数据，包括一到五个本地图像路径，并打开一个 PR。除非您拥有该故事，否则请保持名称匿名。