致4月份奋斗在苹果审核路上的人们，亲历提审经验

“去年下半年至今，苹果粑粑不断调整审核规则，让大家十分痛苦。面对客服强势回复，也是有苦说不出，只能摸索尝试调整。小编在这里也希望分析整合更多实用操作，帮大家解燃眉之急。?”

????从2017年开始，苹果上架越来越困难，主要表现方式有：马甲包、第三方SDK、打包工具有残留信息等。提交时遇到这些问题后，苹果粑粑基本不会给与准确回复，只会通过邮件回复2.1、3.1、4.3等，这个时候就需要开发人员不断尝试了。

接下来我们也整合了一些信息和实战经验分享给大家。我先来看一下Cocoa的一次提交案例：

从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，此时，我们好像看到了方向，打包配置工程很可能存在问题。这时，我们在网上看别人的审核攻略的时候，发现了两个很重要的点：
1、有公司实在没法通过苹果审核，最后更换了打包工程，更换了开发者账号，重新提交后，通过了审核。—-打包工程和开发者账号都可能会影响审核
2、苹果机审基本上所有扫除来的问题都会直接反馈的（除非同时触发多个问题，会直接反馈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、苹果从去年11月升级了机审算法，机审更加严格，而且在今年1月份再次升级审核规则，一次触发到多条问题的时候，会被2.1大礼包打回（相信很多都收到了这个大礼包）。

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

3、针对3.1.1如何解决：首先，去掉第三方支付相关内容，如有需要，可采取下发文件的形式实现网页支付；其次，重点检查第三方SDK，是否都是纯净版本；然后，版本较老的，已停止使用的SDK或其他代码，及时更新或者删除；最后停止使用后的SDK，要及时删除工程配置中的内容，避免留下隐患。

4、针对4.3如何解决：修改应用界面Icon、添加废弃代码、改名字、修改素材及UI色调、修改功能界面，可改功能可做小开关、更换开发者账号（多次审核不过适用），切记要解决问题后，再正式提交。