上个月我的 iOS App 收到了独立开发者最不想看到的拒审理由：Guideline 5.6 --- Developer Code of Conduct。网上关于 5.6 的中文资料很少，大多数帖子停在"被拒了，怎么办"就没有下文。我的案子申诉 3 天就解除了，现在 App 已经上架。总结一下就是5.6基本上是标记了账号，这个时候一直去改代码的收效很低
先说清楚一个前提：这套打法只适用于 App 真的干净的情况。 如果你确实藏了审核期/非审核期切换的功能，需要把相关的隐藏去掉，然后在重新提交，如果还是5.6在继续申诉，直接申诉的话容易被查出来封号
时间线
- 9 月初：v1.0 提交被拒，理由 Guideline 5.6
- 9/7：在 Resolution Center 提交申诉
- 9/10：收到答复，5.6 判定解除，要求重新提交新构建
- 随后：按清单自查整改、重新提交，走正常审核，顺利上架
背景
我的 App 叫 Quartzline，一个只读的加密货币行情 + 资讯工具：行情列表、走势图、自选、恐惧贪婪指数、新闻聚合。没有账号、没有交易、没有内购、没有广告、没有任何第三方 SDK，全部数据来自 5 个硬编码的公开端点。
就是这么一个"干净得不能再干净"的 App，收到了 5.6。
复盘下来，最可能的触发点是这个 App 记录的历史：早期构建带可选的注册登录，反复被拒；后来我大改了产品、彻底删掉了账号体系，然后在同一个 App 记录 上重新提交。"功能大变 + 删掉登录 + 同记录重交"这套组合，在审核方眼里的观感大概就是"换壳绕审核"。注意这只是我的推测------Apple 从头到尾没有告诉我触发点是什么，这正是 5.6 的特点。
5.6 和普通拒审完全不是一回事
普通拒审（2.1 崩溃、4.x 设计问题）会告诉你哪里有问题，改完重交就行。5.6 不是：
- 措辞高度模板化，不指明具体问题。核心指控通常是"隐藏功能 / 误导审核 / 开发者不诚信"
- 它怀疑的不是你的某个 bug，而是你这个账号的诚信
- 由专门的 Code of Conduct 团队处理，回复慢，1--2 周没动静是常态
- 处理不好会升级：不是"这版被拒"，而是账号被终止
理解了这一点，应对思路就清楚了：回应诚信指控的唯一方式是可验证的事实，不是道歉，不是态度好。
我做对的三件事
1. 立刻停手。 收到 5.6 后：不提交新构建、不新建 App 记录、更不注册新的开发者账号。最后一条尤其致命------Apple 的关联识别一旦命中，事情会直接从"拒审"升级为"封号"。
2. 申诉信只写审核员当场可以验证的事实。 9/7 我在 Resolution Center 回复了那条拒审，全信的骨架是一份可验证清单：
- 无任何远程配置：没有 feature flag、没有服务端下发 UI，App 的行为在审核后不可能发生变化
- 全部网络请求只指向 5 个硬编码的公开端点（CoinGecko 行情、Fear & Greed 指数、三家新闻站的公开 RSS），端点以字符串字面量编译在二进制里，
strings一跑就能验证 - App 内不加载任何远端网页：文章页是本地渲染的 HTML，外链一律走 SFSafariViewController
- 无账号、无 UGC、无统计/广告 SDK、无任何第三方框架，纯 Apple 官方框架
- 自选列表存在本地 UserDefaults，不出设备
然后主动提出可以提供：全部界面的走查录屏、完整端点清单、甚至源码。这封信的潜台词不是"我错了我改"，而是"我没有东西可藏，且每一条你都可以当场验证"。
3. 发出之后忍住不动。 只每天检查 Account Holder 邮箱，别的什么都不做。焦虑驱动的动作在这个阶段全是负收益------每多催一次、多开一个渠道，案子就往队尾挪一次。
- 不猜、不认，只陈述准确历史------"这个记录从未有过已批准版本、从未上架、没有任何用户安装过"，这些 Apple 自己数据库里都查得到
- 把举证责任交回去，只问一个具体问题："当前构建里的哪个功能或行为导致了这个判定？ 请指出来，我们彻底解决"
- 可疑的变化主动交代，别等被发现。我删掉了登录功能，这在 5.6 语境下看起来像销毁证据，所以要主动解释：App 全程只读、没有任何服务端用户状态，登录本来就没有存在的意义------而且现在没有账号系统，意味着不存在给不同用户展示不同内容的机制，这恰恰是对我们最有利的可验证事实
- 如果你是老账号、历史干净，一定写进去。"做了 X 年开发者、从未收到过 Code of Conduct 判定"是把案子从自动化判定拉到人工复核的最有效杠杆
解除 ≠ 上架：后半程同样重要
答复里明确要求 resubmit a new binary，接下来这个包要重新过全部条款的正常审核，没有豁免。重交前我做了一轮自查，几条实用的：
- 构建号必须递增（Apple 要的是 new binary）
- 清掉所有占位文案。我设置页里居然还留着 "PRIVACY POLICY (TEMPLATE --- replace before release)"，审核员点一下就能看到，必挂 2.1
- 隐私政策和申诉信的口径必须完全一致。 我隐私政策里写着"打开文章会加载出版方网站"，和申诉信里"App 内不加载任何远端网页"直接矛盾------改掉；漏列的端点也补齐
ITSAppUsesNonExemptEncryption = false写进 Info.plist，以后每次上传不再被问出口合规- 提交前用
strings把 Release 二进制里的域名全部列一遍，确认和申诉信说的一模一样。你刚拿"只有 5 个端点"当核心论据，二进制里冒出一个解释不了的域名，代价远大于省下的几分钟 - Review Notes 里主动写一句：感谢解除此前的 5.6 判定，本构建无账号、无任何远程配置------把结论钉在书面记录里，接手的审核员不必重新判断
另外三条红线，解除后千万别碰：不改 Bundle ID （5.6 是解除在这个记录上的，换记录等于把刚拿回来的东西扔掉）、不新建 App 记录 、不把申诉信里说了不做的功能加回来（白纸黑字有记录）。
重新提交后 24--48 小时走完正常审核，通过，上架。
总结
- 5.6 不是死刑，申诉是真有用的，我的案子 3 天解除
- 5.6 怀疑的是账号诚信，回应方式是可验证的事实，不是道歉和态度
- 只用 Resolution Center 一个线程；不猜原因、不认没做过的错；可疑变化主动交代
- 申诉期间四不做：不交新构建、不换 App 记录、不注册新账号、不反复催
- 解除 ≠ 上架，重新提交前把口径一致性（隐私政策、Review Notes、二进制域名）当成大事来查
每个 5.6 案子的具体情况都不一样，我的经验不构成万能模板，但"可验证事实 + 单线程沟通 + 不乱动"这三条应该是通用的。有问题评论区聊或者加我q345499860。