苹果App Store 荒谬
由Adrien分享
苹果无法识别的app用户
"Who will be the users of this app?"
Adrien提交了版本1.0，苹果在指南2.1中停止了审查，需要更多信息。没有崩溃报告，没有破坏的功能，也没有要求二进制修复的消息。唯一的阻塞就是苹果想要一个详细的答案，说明这个app是为谁而设计的，才能继续审查。
- App
- iPad app版本1.0
- 延迟
- 2026年5月29日，审查暂停
- 结果
- 苹果要求开发者解释目标用户之前继续审查。
社区拒绝存档
App Store 拒绝恐怖故事
苹果 App Store 和 Google Play 拒绝循环的最坏部分，收集为截图和纯文本，以便移动团队可以了解审查队列的真正成本。
提交规则
1 到 5 张图片加上故事文本。
不允许在故事中添加链接。使用本地图片。让拒绝痛苦、具体和有用。
6
已种子故事
2
覆盖的商店
最大 5 个
每个故事的图片数量
The archive
那些比一个糟糕的冲刺还要昂贵的拒绝
每个故事都是以文本为首，图像为辅，且故意避免外部链接，以确保存档始终可读。
苹果应用商店 痛苦
由Adrien分享
苹果认为的应用程序不够不同
"App Store上已经有足够的这些应用程序了。"
Adrien因苹果没有看到与类似应用程序相比的足够独特价值而获得了设计-垃圾邮件拒绝。审查说，应用程序主要是一个屁声或打嗝应用程序，即使它有区别于它的功能，也足以让苹果将整个应用程序视为一个饱和类别中的重复内容。
- 应用程序
- Entertainment sound app
- Delay
- Rejected on May 15, 2026
- Outcome
- Apple rejected it under Guideline 4.3(b), saying the app duplicated a saturated category.
Apple App Store Launch blocker
The metadata loop that ate launch week
"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
- 用户生产力应用
- 延迟
- 9 天
- 结果
- 在没有二进制更改的情况下，重新编辑截图、字幕和审阅笔记后，审批通过。
苹果应用商店 荒谬
审批通过，然后被一个额外的合规问题阻塞
"审批邮件到达之前，阻塞就已经到位了。"
在审批通过后，发布仍然被阻塞，因为团队认为已经回答了合规提示。发布负责人必须停止发布，收集法律文本，更新 App Store Connect 回复，并再次等待。客户在应用实际可用之前就看到发布公告。
- 应用
- B2B商业对话平台伴侣应用
- 延迟
- 4天
- 结果
- 在重新回答出口控制问题并等待下一轮审查后发布。
Google Play 昂贵的
The permission policy time sink
"该应用程序需要屏幕权限，但审查人员却将其视为整个产品的权限。"
A narrow Android permission triggered a broad policy review. The team documented the feature, added reviewer instructions, recorded a demo path, and still had to remove the permission from the main release to unblock customers. The final build shipped with a degraded workflow while the team prepared a cleaner permission split.
- App
- 现场操作应用
- Delay
- 13天
- Outcome
- 在移除权限、录制新演示和重写商店声明后获得批准。
Google Play 痛苦
等待背后的策略队列中的修复
"用户急需修复的破损收银机，但审查队列并不急切。"
一个收银机bug需要快速的移动修复，但商店发布进入了审查的最糟糕的时间。支持票数不断上升，而团队却在等待同样的待定状态。他们最终在服务器端缓解了问题，然后在紧急情况已经烧掉整个周末之后，等待二进制批准的到来。
- App
- 电子商务应用
- 延迟
- 6天
- 结果
- 本地商店修复在团队已经在其他地方缓解了事件之后才到达。
避免下一个恐怖故事
在商店花时间时，使用Capgo来快速修复紧急问题。
Capgo 让 Capacitor 团队能够实时发送更新、回滚错误的发布以及针对特定渠道而不必等待完整的 App Store 或 Google Play 审核周期。
添加拒绝的故事
编辑故事数据，包括一到五个本地图像路径，并打开 PR。除非您拥有该故事，否则请保持名称匿名。