Appstore 4.3 重復應用問題梳理

前言：

希望有更多的朋友一起針對蘋果ios審核上架處理分享，qq群:? 611641785，歡迎一起交流? ，后期會慢慢分享更多的干貨?

請不要為同一個 app 創建多個套裝 ID。如果您的 app 針對特定位置、運動隊、大學等存在不同版本，請考慮提交單個 app，并提供 App 內購買項目以提供不同的功能。同時，請避免繼續在已有大量類似 app 的類別下進行開發；App Store 上已經有太多模擬放屁、打嗝聲音的 app，以及手電筒和愛經 app。上傳大量相似版本 app 的開發者會遭到 Apple Developer Program 的除名。

有過向 App Store 提交 App 被拒經歷的人，大概都聽說過這個恐怖的 4.3 條款，下面做一個詳細的介紹：

【馬甲包】指的是內容幾乎一樣，只是主題色或者是名稱等不重要信息略有改動的雷同 App。

【4.3 條款主要針對誰】一方面源于很多大公司希望批量產出類似 App 進行 A/B 測試；另一方面源于很多小產品希望通過對相同的產品用不同的關鍵詞來進行宣傳，獲取更多的流量（同一個 App，上 10 個馬甲包，收入增 10 倍）；這些行為破壞了 App Store 的生態，導致蘋果會用非常嚴格的手段來進行打擊。

【4.3 條款麻煩在哪】第一點在于這個條款寧可錯殺也不放過，就算你什么錯都沒犯，也很可能被誤傷。?第二點在于，簡單的修改是不足以繞過這個條款的，一旦遭遇它，后面無論你怎么修改，再次重新提交也幾乎沒有通過審核的可能。

【4.3 條款并不是完全搞不定】如今上架馬甲包已經變成了很多公司的一個常規性業務，只要手段合適，是可以進行一定的規避的。

【什么情況可能導致遭遇 4.3 條款】提交 App 給人工審核之前，會先經過一次機器審核，基本上就是個反編譯的過程。如果項目里面大量復用了其他 App Store 上線項目的代碼，會被機器審核回絕；如果產品形態和其他現有 App 幾乎一致，會被人工審核拒絕。

判定拒絕來源

首先，搞清楚你是被人工審核拒絕，還是機器審核拒絕的。

你的應用進入審核（In Review）的時候，你會收到一封郵件，之后被拒絕（Rejected）的時候又會收到一封郵件。如果這兩封郵件的時間差非常小，比如小于半小時，那么基本上就是被機審拒絕了，否則大概率是人工審核拒絕。另外如果你的項目里面復用了其他項目的代碼，你自己心里也應該有數，

如果是被人工審核拒絕了，由于每次審核你的 App 的人可能不一樣，可以直接嘗試換個 BundleID 再次提交，如果屢次被拒，可能你不得不考慮一下更改一下 App 的 UI，包括但不限于導航方式、主題色、頁面結構等等，或者干脆加點功能、砍點功能。

工程混淆

對于機審被拒，首先要做的一步是代碼混淆。這個工作不是專門針對 4.3 條款的，項目本身為了防止被別有用心的人反編譯，也是常常需要進行加固處理的。

對于純代碼層面的混淆，直接推薦你看這篇博客：https://blog.csdn.net/yiyaaixuexi/article/details/29201699?，不同的手段所做的工作都差不多，難度也不高，無非就是讓反編譯出來的函數名、類名、變量名都顯示為隨機字符串。這篇博客里面的內容我已經實際使用、并提交 App Store 試過，親測有效。

對于工程層面的混淆，要做以下幾個工作：

項目里面的文件目錄、子文件夾排列等，盡可能改動要大，完全打亂最好

所有圖片、音頻資源文件名，建議批量修改，為了便于批量處理，可以加上較長的前綴，比如“CodeExampleTest_123.mp3”

類名、變量名也建議批量重構，Xcode 自帶了 Refactor – Rename 的重命名功能，直接加上前綴處理起來很快

BundleID 一定要換，作為一個新 App 重新提交，并且最好和之前的 BundleID 差別較大

App Store Connect 清理工作

1. 清理二進制文件

前往你的應用的 AppStoreConnect 頁面，在 TestFlight 欄目下，找到你之前提交過的構建版本，點擊“將構建版本設置為過期”，這一步是必須要做的

2. 清理 App 信息

之前填寫過的關鍵詞、開發者網站鏈接、App 名稱、App 圖標，全部換成無意義的隨機內容，和你的真正內容不要有關聯。如圖，這種空置的 App 我已經有好多個了。

3. 換賬號

如果有條件的話，建議購買多個 App Store 開發者賬號，使用空賬號提交馬甲包，避免在蘋果那邊沾染上不良記錄，保證自己的主力盈利的賬號不要被封號。

或者可以和其他同樣被 4.3 條款折騰的開發者一起購買空閑賬號，專門用來處理馬甲包。

分階段測試審核

不確定自己的應用能不能通過 4.3 審核的時候，可以不用急著一次上線全部內容。

內容上

在內容上只上線最最核心的東西，第一次提交，能不要的東西都可以不要，比如設置頁什么的。這樣萬一你后續提交的都被拒，那么這一版可能成為你相當長時間無法更新、甚至永遠都無法更新的一個版本，你要保證它起作用。

信息上

一開始的版本，除了要把 ASO 的關鍵詞寫好之外，截圖、App Store 描述可以都只放最最基本的內容，爭取先把第一關過了，后面更新再改這些內容，哪怕代碼不動，直接通過發版來更新這些內容也行。

地區上

一開始上線，想碰審核的時候，上線地區可以不要選擇所有地區，可以只隨便選擇一個地區，盡量保證過審。這個地區在你的 App 上架之后是可以隨便改的，所以你一開始不妨就讓它在一個語言不通的小國家上線，反正也不會有人用。

等通過審核之后，考慮到，你下次提交不一定還能過審，通過審核的應用一定不要“取消發布”，而是要讓它在一個小地方先上線。等你確定你之后的更新要失敗了，你沒辦法改代碼了，再通過勾選地區的方式，讓你的應用在其他地區上線。就算發一版，總比什么都沒有要強。

應對蘋果審核的非技術因素

機審還是人審

App Store 審核，一般分為機器審核和人工審核兩部分，先機審、后人審。

開始審核的時候，你會收到一封郵件；被拒的時候，你又會收到一封郵件。

如果兩份郵件間隔時間小于半小時，一般來說，被拒的過程就是機器完成的。

大部分是 2.1 條款和 4.3 條款

回復時機

這個 “回復” 分為兩種情況，一種是審核被拒了，在后臺的 resolution center 給你發了消息，這種情況下你可以不改 App 包，而是直接在 resolution center 給審核團隊進行回復、辯解；另外一種情況是，被卡審核了，拖個十天半個月不給審核、也不給拒絕。

對于前者，你需要回復消息；對于后者，你需要把 App 撤回再提交。而不管是哪種情況，需要做到的一點是：盡量間隔 2-3 天再進行回復。

有這么幾個好處：

比如遇到 2.1 條款，等了兩三天之后，看起來像是你真的認證檢查過自己的問題了，而不是直接回懟

比如遇到卡審，等了兩三天之后，看起來像是你把他們沒有明確指明的 App 里面的問題解決了

避免遇到同一個審核工作人員

間隔的這兩天剛好是周末的話，反正周末他們也不怎么審核，你也沒浪費時間

另外還需要注意，如果你準備撤回 App 再提交，要確保：

如果審核明確說明，你再次提交會遭遇 “longer review time”，則要慎重

撤回 App 再提交的話，最好給 App 加上一些明顯的功能性改動，不要讓對方認為你只是重新打包了一下（對方是有足夠的動機來檢查你的應用的 MD5 值的）

換賬號不解決問題

有時候很多開發者并不是有意要上馬甲包，而是比如說，我本來做了一個濾鏡的 App，現在想換一套濾鏡，再出一個 App，但是 App Store 希望你把功能整合在一起，做成一個 App，給了一個 4.3 條款打回來。于是開發者就準備和審核作斗爭。

斗爭半天無果，就準備再注冊個開發者賬號，結果發現還是沒有結果。

這里面有很多基礎性的因素，來幫助蘋果判定你這個新賬號還是對應的以前的開發者：

兩個賬號銀行卡信息一樣

兩次上傳 App 包的設備一樣（判定是不是同一臺 Mac 對他們簡直太小兒科了）

兩次上傳 App 包的 IP 地址一樣（MAC 地址、GPS 位置等信息同理）

新舊賬號有關聯（開發者為了省事，進行賬號授權，通過一個賬號來管理多個賬號下面的 App）

這就是為什么，很多人覺得自己給 App 做了翻天覆地的改變，什么代碼混淆、UI 改動全都試過了，還是沒有結果。你兩次上傳 App 用的都是同一個 WiFi，當審核團隊都是傻子嗎？

看到這可能很多人都絕望了，因為如果網絡環境、地址位置、設備、賬號全都換一套，成本太高太高了。

所以，如果你真準備從這個角度來騙過審核，就不如直接找個朋友的賬號。代碼你來搞定，從打包到上架全過程都由對方完成，你在北京，他在深圳，毫無關聯。這樣雖然也不一定就能幫你過審核，但是至少把非技術性的這塊最容易暴露自己的問題解決了。

——————————————————

后記：

希望有更多的朋友一起針對蘋果ios審核上架處理分享，qq群:? 611641785，歡迎一起交流? ，后期會慢慢分享更多的干貨?