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