大家好，我第一次提交一款 iOS 单机买断游戏，只计划在海外 App Store 市场发布，不包含国区，最近被 App Store 审核折腾得有点崩。
时间线大概是：
- 第一次提交：等了约 18 小时，因为经验不足，没有写详细 Review Notes，也没提供完整录屏，被要求补充信息。
- 第二次提交：等了约 50 小时，进入
In Review后几乎立即被 Guideline 5.6 - Developer Code of Conduct 拒绝。 - 第三次提交：针对 5.6 做了全面清理，并补充详细 Notes 和真机录屏，等了 30 多个小时，结果进入审核后又几乎秒拒，文案完全一样。
Apple 的理由是：
We’ve identified a pattern of unusual behavior with the app that is commonly associated with fraudulent activity. Specifically, the app contains features that appear to have been intentionally hidden during the review process. Manipulative and misleading behavior is not consistent with guideline 5.6.
中文大意：
我们发现该 App 存在一种异常行为模式，这类行为通常与欺诈活动相关。具体来说，该 App 包含一些看起来像是在审核过程中被有意隐藏的功能。操纵性和误导性的行为不符合 Guideline 5.6 - Developer Code of Conduct 的要求。
比较奇怪的是，隐藏、休眠、未披露功能通常更直接对应 2.3.1(a)，但这里直接用了 5.6 Developer Code of Conduct，而且拒绝信息里还有 fraudulent activity、intentionally hidden 这种比较严重的措辞，相当于把问题上升到了开发者行为准则层面。
第一次 5.6 后，我已经把所有可能引起歧义的东西尽量清理了，包括：
- 未使用的开发 / 测试功能
- 未发布功能和旧逻辑
- 无用引擎模块
- WebView 模块
- 与 iOS 无关的第三方平台变量 / 宏，例如 Alipay Game、WeChat Game 等
游戏本身是纯单机买断制，没有：
- 用户账号
- IAP
- 广告
- 订阅
- 远程配置
- 热更新
- 远程代码加载
- 服务器下发游戏功能
外部网络行为只有：
- Game Center 排行榜分数提交
- 通过系统浏览器打开 Privacy / Support
- 打开 App Store 评分页面
所以从产品和技术结构上，也基本不存在“审核时隐藏，过审后再远程开启功能”的场景。
而且两次 5.6 都是进入 In Review 后几乎秒拒。
第三次提交前，我已经把主要功能、入口、网络行为、外部服务等都在 App Review Notes 里写得很清楚，也提供了完整真机录屏。
这种情况下依然秒拒，让我越来越怀疑它根本不是在根据实际游戏功能判断，甚至都还没看到备注里面的游戏功能，就被某个自动风险模型命中了构建产物或引擎层面的特征。
目前技术栈：
- Cocos Creator 2.4.5
- iOS 原生构建
- JSB
- Release 构建
- 开启 Encrypt JS
现在主要想请教几个问题：
- 有没有 Cocos Creator 项目遇到过类似 Guideline 5.6 / hidden features 秒拒？最后是怎么解决的？
-
.jsc脚本加密、JSB、脚本加载结构，有没有可能被 Apple 的风险检测误判成隐藏功能、动态代码加载或类似行为？ - Cocos Creator 的 iOS 构建里，还有哪些容易忽略的动态加载、热更新、跨平台兼容或残留模块值得重点检查？
- 较新的 Cocos Creator 版本在 iOS Release 构建上，会不会比 2.4.5 更精简、更干净一些？
- 有没有比较成熟的 iOS 上架前裁剪 / 检查清单？
目前我已经请求 App Review 进一步说明并进行人工复核，同时也提交了 App Review Appeal申诉，所以暂时不准备继续盲目删代码、修改然后重新提交，不知道要等多久才有回应，反复折腾已经把热情都磨灭了。
顺便吐槽一句，Apple 这套审核体验确实非常黑盒：
排队几十个小时，进入审核以后几乎秒拒，却完全不告诉开发者究竟是哪个功能、哪个模块，甚至哪一类行为触发了 5.6。
不公开具体风控规则，我完全可以理解，毕竟需要防止真正想绕过审核的人反向研究规则。
但至少应该给正常开发者一个可以整改的问题类别。现在这种只给一句“疑似隐藏功能”的做法，会让开发者在完全不知道触发方向的情况下反复排查、删代码、等待、重新提交，几乎等于让开发者为了一个黑盒判断跑断腿。
Apple 一直非常强调以用户体验为核心，这也是很多开发者愿意优先为 Apple 平台投入时间和精力的重要原因。但从这次经历来看，App Review 在面向开发者这一侧的体验，和 Apple 一贯所强调的“清晰、直观、减少用户不确定性”的产品理念存在很明显的反差。
审核严格本身可以理解，风险模型需要保密也可以理解，但如果一个严重到上升至 Developer Code of Conduct 的判断，只给出“疑似隐藏功能”这种非常宽泛的结论，却不给任何可操作的问题类别，也没有及时的人工兜底，那么开发者实际上承担了风险模型误判所带来的全部时间成本和试错成本。
尤其 5.6 还属于 Developer Code of Conduct，措辞已经涉及 fraudulent activity 和 intentionally hidden，性质明显比普通功能问题严重，却没有提供对应的具体问题，这种体验确实比较拉胯。
如果这个问题最终真的与 Cocos Creator 的构建结构、JSB、脚本加密或者某些引擎层特征有关，我觉得 Cocos 社区也应该重视一下。
很多独立开发者可能会把几个月甚至更长时间全部投入到玩法、画面、性能、适配和内容研发里。
如果一直埋头开发，到项目全部做完、真正准备上架 iOS 时，才发现某些引擎构建特征可能持续触发 App Store 的风险审核，那这个成本会非常高。
如果有类似经历，非常希望能分享一下最终是怎么解决的。
也希望以后能够整理出一套比较明确的：
Cocos Creator iOS Release / App Store 提交前检查清单
别大家一股脑只顾着研发，最后真正到了上架阶段才发现审核才是最大的坑。
谢谢大家。