馬甲包指南 - 攻克 App Store 4.3 條款

4.3 重複 App 請不要爲同一個 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 條款的，項目自己爲了防止被別有用心的人反編譯，也是經常須要進行加固處理的。

對於純代碼層面的混淆，直接推薦你看這篇博客：blog.csdn.net/yiyaaixuexi… ，不一樣的手段所作的工做都差很少，難度也不高，無非就是讓反編譯出來的函數名、類名、變量名都顯示爲隨機字符串。這篇博客裏面的內容我已經實際使用、並提交 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 審覈的時候，能夠不用急着一次上線所有內容。

1. 內容上 在內容上只上線最最核心的東西，第一次提交，能不要的東西均可以不要，好比設置頁什麼的。這樣萬一你後續提交的都被拒，那麼這一版可能成爲你至關長時間沒法更新、甚至永遠都沒法更新的一個版本，你要保證它起做用。

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

3. 地區上 一開始上線，想碰審覈的時候，上線地區能夠不要選擇全部地區，能夠只隨便選擇一個地區，儘可能保證過審。這個地區在你的 App 上架以後是能夠隨便改的，因此你一開始不妨就讓它在一個語言不通的小國家上線，反正也不會有人用。

等經過審覈以後，考慮到，你下次提交不必定還能過審，經過審覈的應用必定不要「取消發佈」，而是要讓它在一個小地方先上線。等你肯定你以後的更新要失敗了，你沒辦法改代碼了，再經過勾選地區的方式，讓你的應用在其餘地區上線。就算髮一版，總比什麼都沒有要強。

最後

不要迷信蘋果，不要自我懷疑。上架 App 是商業行爲，App Store 拒絕你上架不能說明任何問題。蘋果公司能力極強，可是 App Store 的審覈團隊並不神聖。

不服就幹，App Store 讓你上架，你就是合理的；App Store 不讓你上架，說明你能力不夠，搞贏 4.3 條款，你就是贏家，千萬不要由於被拒就以爲問題出在你自身，上有政策，下就有對策。

---

關於做者

KyXu，多年獨立開發經驗，長期致力於幫助廣大移動端開發者 變現、擁有本身的產品、成爲獨立開發者，微信公衆號：KyXuIndie

加我微信入專欄讀者羣：balabala-ba

關注專欄解鎖更多幹貨：xiaozhuanlan.com/kyxuDev