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 稽核的時候，可以不用急著一次上線全部內容。
-
內容上
在內容上只上線最最核心的東西，第一次提交，能不要的東西都可以不要，比如設定頁什麼的。這樣萬一你後續提交的都被拒，那麼這一版可能成為你相當長時間無法更新、甚至永遠都無法更新的一個版本，你要保證它起作用。 -
資訊上
一開始的版本，除了要把 ASO 的關鍵詞寫好之外，截圖、App Store 描述可以都只放最最基本的內容，爭取先把第一關過了，後面更新再改這些內容，哪怕程式碼不動，直接通過發版來更新這些內容也行。 -
地區上
一開始上線，想碰稽核的時候，上線地區可以不要選擇所有地區，可以只隨便選擇一個地區，儘量保證過審。這個地區在你的 App 上架之後是可以隨便改的，所以你一開始不妨就讓它在一個語言不通的小國家上線，反正也不會有人用。
等通過稽核之後，考慮到，你下次提交不一定還能過審，通過稽核的應用一定不要“取消釋出”，而是要讓它在一個小地方先上線。等你確定你之後的更新要失敗了，你沒辦法改程式碼了，再通過勾選地區的方式，讓你的應用在其他地區上線。就算髮一版，總比什麼都沒有要強。
最後
不要迷信蘋果，不要自我懷疑。上架 App 是商業行為，App Store 拒絕你上架不能說明任何問題。蘋果公司能力極強，但是 App Store 的稽核團隊並不神聖。
不服就幹，App Store 讓你上架，你就是合理的；App Store 不讓你上架，說明你能力不夠，搞贏 4.3 條款，你就是贏家，千萬不要因為被拒就覺得問題出在你自身，上有政策，下就有對策。
關於作者
KyXu，多年獨立開發經驗，長期致力於幫助廣大移動端開發者 變現、擁有自己的產品、成為獨立開發者，微信公眾號：KyXuIndie
加我微信入專欄讀者群：balabala-ba
關注專欄解鎖更多幹貨：xiaozhuanlan.com/kyxuDev
