App 被 Apple 或 Google…

当应用或更新被 App Store / Google Play 审核拒绝，需要定位违规条款、撰写申诉回复、修复问题并在 24–72 小时内重新提交时使用。

适用场景

解决思路

1. 先做初步评估：让用户逐字粘贴完整拒绝信息（含 guideline 编号），确认是 App Store、Play Store 还是两者，确认是首次提交还是更新（首次提交审查更严），获取 App ID 与应用分类，询问本版本相对上次通过版本的改动，并确认是否有时间敏感性（上线日期、营销绑定）。在完成拒绝类型分类前不要开始写修复方案。
2. 按 Apple guideline 编号归类到对应桶并套用典型修复：2.1 性能/完整性（真机测试、修崩溃、补演示内容）；2.3.x 元数据不准确（截图与实际应用一致、移除不支持设备、修描述）；2.5.x 软件要求（只用审核通过的 API、修私有 API、修 HealthKit/SiriKit 误用）；3.1.1 内购（数字商品必须用 IAP、不得外链支付）；3.1.2 订阅（自动续订披露、恢复购买、条款链接）；3.2.2 不可接受的商业模式；4.0 设计（垃圾、抄袭 UI、布局损坏）；4.2 最低功能（网页壳、单薄应用、宣传册式应用）；4.3 垃圾（与自家或他人应用重复，最常见）；4.5.x Apple 站点与服务；5.1.1 隐私/数据收集（隐私政策 URL、数据收集披露、ATT 提示文案）；5.1.2 数据使用与共享（隐私营养标签与实际收集一致）；5.1.5 定位服务（论证 Always 定位、ATT 式说明字符串）；5.1.7 健康与医疗（免责声明、无 FDA 不得做诊断声明）；5.2.x 知识产权（需商标/版权方授权）；5.3.x 游戏、赌博、彩票（牌照要求）；5.6.1 开发者行为准则（垃圾、假评论、操纵）。
3. 针对 Guideline 2.1（崩溃/功能不完整）：读取 Apple 测试所用设备与 iOS 版本；在该确切配置（或最接近的可用配置）上复现；若为环境问题，在 Resolution Center 提供演示账号与走查视频；若为崩溃，提交修复后的二进制包并在回复中注明具体代码行。
4. 针对 Guideline 2.3.10（元数据/截图不准确）：替换任何展示二进制包中不存在 UI 的截图；若不支持 iPad 则移除 iPad 相关表述；从截图中移除第三方商标。
5. 针对 Guideline 3.1.1（必须使用 IAP）：移除外部支付链接与“在网页购买”CTA，改用 StoreKit（自 2024 年起美国用户可使用 External Purchase Link Entitlement，但这是可选加入且需申请该 entitlement）。
6. 针对 Guideline 4.3（设计垃圾/重复）：这是最难恢复的拒绝。步骤：1) 确认你的应用被拿来与哪些应用比较；2) 做实质性差异化：独特功能、独特品牌、元数据中清晰的价值主张；3) 若是自家产品组合，合并或下架旧应用；4) 若是首次提交，除非从根本上改变应用，否则通常无法恢复。
7. 针对 Guideline 5.1.1（隐私）：隐私政策 URL 必须可访问、有效且针对该应用；ASC 中 App Privacy 部分必须准确列出每个 SDK 的数据收集；ATT 提示字符串必须具体（不能是泛泛的“改进应用”）；NSUsageDescription 字符串必须解释“为什么”而不只是“是什么”。
8. 针对 Guideline 5.1.5（定位）：使用“Always”定位必须能证明应用确实需要后台定位；大多数应用应只申请“When In Use”；更新 Info.plist 与提示文案。
9. 按 Google Play 政策归类并套用典型修复：受限内容（内容审核、年龄门）；隐私、欺骗、设备滥用（隐私政策、准确的 Data Safety 表单）；知识产权（取得授权或移除）；变现与广告（使用 Play Billing）；商店信息与推广（信息与应用一致）；垃圾与最低功能（增加独特价值）；家庭（COPPA/GDPR-K 合规、广告 SDK 白名单）；权限（移除或通过 Special Permissions Declaration 表单论证高风险权限）；健康虚假信息（加免责声明、提供资质）；前台服务（在 Play Console 表单中论证）。Play 还有无人审的自动封禁，这类需用 Play Console 申诉表单附书面理由。
10. 使用 Resolution Center 回复模板：开头问候 App Review Team 并感谢关于 guideline <X.Y.Z> 的反馈；UNDERSTANDING 用一句话描述他们指出的问题；CHANGES MADE 逐条列出具体改动；DEMO INFO 提供演示用户名、密码、编号测试步骤、必要时走查视频 URL；结尾说明已提交 build <X.Y.Z (build N)> 并致谢署名。
11. 遵守回复规则：绝不与 guideline 争辩，先承认；除非问题本身就是元数据，否则不要只改元数据就重新提交同一二进制包；始终引用新的 build 号；即使应用某些流程不需要登录，也提供演示凭据以减少审核摩擦。
12. 按情况决定申诉还是修复：审核员错误适用 guideline → 通过 Apple App Review Board 申诉（礼貌、基于事实、简短）；审核员测试错误（如设备不对）→ 在 Resolution Center 回复复现信息，无需正式申诉；首次遇到 Guideline 4.3 垃圾 → 做实质差异化后重新提交，不要申诉；确实符合却被误判的子政策 → 附证据（截图、代码引用）申诉；5.6.1 开发者账号威胁/封禁 → 立即申诉并提供背景，不要忽视。Apple App Review Board 响应时间为 5–10 个工作日；不要为琐碎问题申诉，修复后重新提交更快。
13. 申请 Apple 加急审核：通过 App Store Connect → Contact Us → App Review → Expedited Request。有效理由：影响用户的关键 bug 修复、时间敏感事件（绑定日期的上线、合作方集成）、安全修复。不要以营销为由申请，Apple 会拒绝并可能标记账号。
14. 按输出模板产出：REJECTION DIAGNOSIS（应用名）、REJECTION TYPE（平台、guideline/政策编号、桶分类、严重度 low/medium/high）、ROOT CAUSE（一段大白话）、FIX PLAN（代码改动、元数据改动、配置改动如 Info.plist 与 ASC 设置、预估工时）、RESOLUTION CENTER RESPONSE 草稿、RESUBMISSION CHECKLIST（在 Apple 测试所用设备上测试、演示账号已验证、build 号已递增、隐私营养标签一致、已在 Resolution Center 发布回复、如有正当理由已申请加急审核）、POST-RESUBMISSION（预期复审时间 Apple 24–48 小时 / Google 不定；若再次被拒的下一步升级措施）。
15. 解决后做防再犯检查：在最旧支持的 iOS/Android 版本上测试；所有 NSUsageDescription 字符串面向人类书写；隐私政策 URL 有效且与应用内收集一致；截图中无第三方 logo/商标；无“BETA”“BUG FIXES”或泛泛描述；演示账号就绪并填充真实数据；任何第三方社交登录旁都提供 Sign in with Apple。
16. 跨技能交接：通过后优化商店信息 → aso-audit；隐私营养标签需大改 → metadata-optimization（描述）+ 手动更新 ASC；拒绝由付费墙流程引起 → paywall-optimization；拒绝由引导页权限提示引起 → onboarding-optimization。

适用边界 · 注意事项

• 仅需提交前商店信息健康检查时，应使用 aso-audit，而非本流程。
• 仅需修复元数据（描述、关键词等）时，应使用 metadata-optimization，而非本流程。
• 不要以营销为由申请 Apple 加急审核，Apple 会拒绝并可能标记账号。