先說說我們的故事吧，至于干貨，看文章最后的總結就好。

從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。

·??關于4.3，如何區分是機審不通過還是人工審核不通過：