七麦研究院 特邀 - 妖怪大人

先说说我们的故事吧，至于干货，看文章最后的总结就好。

从 2017 年 11 月 20 日起，到 2018 年 3 月 28 日，向苹果提交审核共计 20 个版本，收到了 11 个 3.1.1 、3 个 4.3 、5 个 2.1 和 2 个 2.3 ，一个开发者账号基本报废；最后终于找到了审核问题所在，在 3 月 28 日成功上架 App Store ，完成了这次应用版本更新的使命。

2017 年 11 月 20 日，提交了我们应用的正常升级版本（版本 1 ），2 天后，收到苹果反馈，违反了 3.1.1 ，被告知包含第三方支付。从这天开始，就开始了四个月与苹果审查人员的漫漫斗争路。起初，收到这个回复的时候，我们也是一脸懵逼，这个版本升级并没有特别的，支付相关的内容，而且我们也是一直老老实实的在使用苹果内购，并没有使用过什么微信和支付宝支付。然后问题丢给开发去排查，开发也是不知从何下手，只能怀疑是第三方 SDK 中含有什么违规内容，于是便将微信、QQ 等 SDK 全部换成了纯净版，提交审核（版本 2 ），以为会正常通过。2 天后，苹果反馈结果还是 3.1.1 。

这就很疑惑了，以前都正常的东西，现在怎么就突然出现问题了。此时我们团队在网上逛了各种论坛寻找解决方法的时候，发现 11 月中旬苹果升级了机器审核算法，很多曾经接过或者怀疑带有三方支付的 SDK 都被拉进了黑名单，近期有大量应用被苹果以 3.1.1 打回，其中，也有很多和我们一样，没有使用任何第三方支付的代码，但是也被 3.1.1 打回。看来是苹果爸爸调整了算法，我们被误伤了。

当然，不管是不是被苹果误伤，都得找到原因并进行修改。这时候需要说一下我们应用的代码结构了，我们整个应用分为结构较为独立的几个部分，大致分为以下几部分：

·游戏资源文件：公司内其他合作部门提供的资源，代码较简单，排查较容易；

·SDK 及引擎：公司内较为通用的内容，公司其他应用内也会使用到；

·平台级代码：只有我们自己的应用会使用到。

根据代码结构，我们首先怀疑了游戏资源文件中存在问题，因为游戏资源文件不是我们部门自己开发写的代码，且安卓/ iOS 使用的资源文件较类似，同时，我们对其中的内容也不是很了解。于是我们联系相关部门，对游戏资源文件进行了认真的检查和修改，将游戏资源中非苹果支付的支付字段全都去掉，替换游戏资源文件后提交苹果审核（版本 3 ）。提交审核几天后，苹果反馈 3.1.1 。

此时，我们觉得这样排查没有明确的排查方向。于是，我们觉得可以尝试进行申诉一下试试，因为之前是有通过申诉获得了有效信息并最终通过审核的经历。于是我们向苹果提起了申诉。没多久，苹果给回复了，告诉我们应用中有“ YYY SDK ”（一个同行竞品的 SDK ，此处具体什么 SDK 就不进行说明了）

这申诉结果让我们更加迷茫了，这是我们的竞品产品，我们怎么会使用竞争对手的 SDK ；于是我们怀疑可能因为是同行竞品和我们应用某些代码结构比较相似，而竞品应用使用了第三方支付被苹果拉黑了，导致我们的应用也没法过审了。于是，我们认为是被苹果误伤了，毕竟第三方支付动到了苹果的蛋糕，这是苹果坚决不能容忍的。

觉得自己是被误伤后，我们再次向苹果提出申诉，并且向苹果提出了电话沟通的请求，然而苹果这次的回复更加坚定“我们确认你的应用中含有第三方支付的方法，回去好好检查吧”，根本不给我们电话沟通的机会，不得不说还是苹果爸爸强硬，我们也不敢在申诉了，之前有过多次申诉被苹果直接将开发者账号拉黑的经历，已经不敢轻易惹怒苹果爸爸了。只能忍气吞声，默默的回去继续排查代码了。

游戏资源文件已经基本没有可以修改的内容了，申诉也没有效果，然后下一步继续排查引擎及 SDK ，对引擎及 SDK 内所有充值相关的字段都进行了替换，所有支付相关的字段，包括类似 alipay 的字段都进行了删除。提交审核后（版本 4 ），苹果反馈 3.1.1 。

游戏资源文件，引擎及 SDK 都修改了之后，就只剩下平台级代码未做修改，于是再对平台级代码中支付相关的字段名，能替换的替换，能删除的删除，处理干净之后，提交审核（版本 5 ），然而2天后还是收到了苹果 3.1.1 的反馈。

三个模块都修改尝试了，然而都是一样的结果，我们只能怀疑是修改的不够彻底，于是将三个模块都进行了更加彻底的修改，甚至已经牺牲了有些功能不能正常使用，然而提交这个版本后（版本 6 ），还是收到了苹果 3.1.1 的反馈。

此时，我们账号已经提交了很多个版本了，审核速度开始变慢，根据我们代码结构，引擎及 SDK 这部分其他应用也在使用，于是我们将修改后的引擎及 SDK 集成在其他应用中提交审核，提审过几个应用后，通过审核了。说明 SDK 相关的内容是没有问题了，游戏资源部分基本上是不会存在问题的。此时压力全部落在了我们身上，使用同样的 SDK ，其他应用都能够通过，我们的却不通过，肯定是因为我们自身代码出现问题了。

在很无奈的情况下，我们再回顾苹果审核条款，发现这样一句话似乎会有不一样的解读：

由于我们的应用确实是有一点点隐藏功能开关的，于是我们怀疑苹果是检测到了我们的隐藏功能开关，认为我们提交审核的是非完整版的应用，而完整版的应用需要使用第三方支付才能够解锁获得（现在回头来看，真的是病急乱投医了）。然后，为了验证这个问题，我们同时提交了两个版本，一个版本去除了隐藏功能开关，将隐藏的功能直接删除掉（版本 7 ），另一个版本只保留隐藏的那一小部分功能，提交审核（版本 8 ）。然而，反馈回来的双双都是 3.1.1 。这样的反馈结果说明，是真的存在什么第三方支付问题，隐藏功能开关的猜测是不成立的。

此时，开发那边发现我们应用的打包配置工程中有一个地方存在几千个没有什么用的，不知道是谁写的 schema（打开其他应用的参数），怀疑是这数千个 schema 中的某一个和其他公司的相同了，从而触发了苹果的特征库，导致我们应用的被 3.1.1 打回。项目组也已经没有什么可靠的办法，既然有可能，就去试一试吧。于是删除了这部分内容，提交一个包（版本 9 ），然而结果还是 3.1.1 打回（现在回头来看，这个时候是已经比较接近最终答案了，但是在当时的情况下，是没法立即确认出问题了）。

这时候，我们的上架问题已经很紧迫了，手上新的版本也早已经停止了下来，新的需求也不接了，大佬们也都在关注着这个问题。在排查了两个多月后，我们还是没能解决问题，产品，技术上都没有什么更好的办法。然后，经过项目组讨论后，我们被迫开启了应用重构之路。计划将整个应用重新写一遍，功能一点一点加上去，一次次去提审，一点点去排除 3.1.1 的问题，直到找到问题原因，解决问题，再上架。虽然这个方案时间成本非常高，但是我们也是别无他法了。

几天后，重写的最简单的应用，仅仅包含注册登录和最简单的功能，提交苹果后（版本 10 ），收到苹果反馈 4.3 。庆幸，终于不是 3.1.1 了，但是这时候我们还是没法确定 3.1.1 问题不存在了。为了验证我们这个包是否是确定通过了苹果机审的，我们针对 4.3 问题，进行了相应的处理，添加了部分废弃的代码，希望能够通过机审。然而，这个套路并没有通过苹果的审核（版本 11 ），然而这个版本还是被 4.3 打回了。

虽然第一个包没有收到 3.1.1 问题，看上去重写的方案是可行的，但是，我们没法确定 3.1.1 问题已经解决了，同时我们也不甘心找不到问题一点点的重写整个代码。

分析之前的结果，我们除了代码的精简外，还替换了打包工程，于是我们怀疑我们打包工程是不是存在什么问题呢。于是，我们使用新写的，最精简的代码，在老的打包工程里打包提交审核，几天后，苹果反馈 3.1.1 ，此时，我们好像看到了方向，打包配置工程很可能存在问题。这时，我们在网上看别人的审核攻略的时候，发现了两个很重要的点：

·有公司实在没法通过苹果审核，最后更换了打包工程，更换了开发者账号，重新提交后，通过了审核。——打包工程和开发者账号都可能会影响审核；

·苹果机审基本上所有扫除来的问题都会直接反馈的（除非同时触发多个问题，会直接反馈 2.1 大礼包）。——确定最新的包只有 4.3 ，没有 3.1.1 。

分析我们最近提测的包，两个包都只反馈了一个问题，说明两个包不同的地方肯定是存在问题的。两个包是替换了打包工程的，说明我们怀疑的方向是对的。

为了验证打包工程哪里存在问题，我们对打包工程和代码的关系进行了分析：

打包工程里面有什么？打包工程里面也有代码内容，虽然这不是我们写的的代码，但是这些代码最终也会被打进包里，提交到苹果进行审核。在听了开发的描述之后，我对打包工程进行了这样的分析：（这也是我和项目组成员解释的较多的一个图)

平台级代码分为是哪个模块的话，我们最简单的部分看做是代码模块 3 ，这部分必须要用的工程配置看做是 C ；

于是，我们之前提交的版本便可以这样进行分析：

3+a+b+c=3.1.1

3+C=4.3

而打包工程 C 和 c 可以看做是一样的内容，于是我们得出结论，打包工程 a 和 b 部分存在违反了 3.1.1 的内容。

在分析这个问题的同时，我们还在尝试在新的打包配置工程+最简单代码的版本上尝试通过机器审核，在对应用界面做了部分修改后（改的惨不忍睹），提交审核（版本 12 ），终于通过了机审，人工审核未通过，此时我们已经不奢望通过人工审核了，我们的标准已经调整到通过机审就是天大好消息了。这个版本通过机审后，我们也坚定的相信，我们这个版本是不存在 3.1.1 问题了。

再回到打包配置工程的问题上来，我们需要验证 a ，b 是不是真的存在问题，于是我们提交了去掉了 a 和 b 的版本（版本 13 ）：

3+c=2.3+2.1（机审通过）

这样的结果，确定了打包配置工程中的a，b部分存在问题了，但是代码 1 ，2 部分还未确定，于是我们又提交了增加代码模块 1 ，2 的版本（版本 14 ）：

1+2+3+c=2.1（机审通过）

至此，我们 3.1.1 的问题原因终于找到了。而这时，开发根据定位的问题，将可能怀疑的对象和之前苹果反馈给我们的“ YYY SDK ”进行了比较（反编译），发现原来我们打包工程配置中包含一个 SDK 命名和“ YYY SDK ”的文件命名一样，而友商的“ YYY SDK ”中这个文件确实包含各种第三方支付方式。

接下来问题便简单多了，直接在我们主账号下，删除了部分打包工程配置的一部分内容后，3 月 26 日提交审核，3 月 28 日审核通过，3 月 29 日正式上架。这持续了 4 个月的上架审核过程，也暂时的告一段落了。庆幸在 4 月份之前完成了上架，因为再晚一点，还必须要完美适配 iPhone X 才能上架。

最后，将我们整个上架过程中的一些收获分享给大家：

干货

1、苹果 2017 年 11 月中旬升级了机器审核算法，机器审核更加严格；2018 年 1 月份再次升级审核规则，一次触发到多条问题的时候，会被 2.1 大礼包打回。

2、苹果有自己的特征代码库，只要和这个特征代码库存中代码撞车了，均会被认为是违反了相应的条款，不管这部分代码是否真的是违规了。

3、3.1.1 如何解决：

·去掉第三方支付相关内容，如果有需要，可采取下发文件的形式实现网页支付

·重点检查第三方 SDK ，是否都是纯净版本

·版本较老的，已经停止使用的 SDK 或其他代码，及时更新或者删除

·相关 SDK 停止使用之后，及时删除工程配置中的内容，以免留下隐患

4、4.3 如何解决：

·修改应用界面，icon

·添加废弃代码

·改名字

·修改素材及 UI 色调等

·修改功能界面等，可改功能可做小开关

·如果多次不过审，请更换开发者账号，解决问题之后，再正式提交

其他经验

·一个账号多次提交审核不通过的时候，速度会变慢，可以尝试更换其他开发者账号提交审核；

·成功上架的应用，才会被纳入特征库，才会被用来比对代码相似度（在一个账号下上架的应用，在另外的账号进行提审，会触发 4.3 ）；

·机器审核的时候，所有问题会一次全部反馈，如果机审没有反馈某一条问题，说明机器审核的时候不存在该问题；

·人工审核的时候，会按照一定的顺序进行检测，出现一个问题的时候就会停止审核，修改这个问题后，下次才会进行其他问题的审核；

· 3.1.1 审核方式：预先对一些带有第三方支付的SDK采集技术特征，然后机器扫描是否介入了这个SDK。

- end -

本文由七麦研究院特邀作者【妖怪大人】原创，转载需联系妖怪大人获取授权，七麦研究院有权向非授权转载追究责任。

查看往期精彩文章