4.3 重復(fù) App
請(qǐng)不要為同一個(gè) app 創(chuàng)建多個(gè)套裝 ID。如果您的 app 針對(duì)特定位置、運(yùn)動(dòng)隊(duì)、大學(xué)等存在不同版本，請(qǐng)考慮提交單個(gè) app，并提供 App 內(nèi)購買項(xiàng)目以提供不同的功能。同時(shí)，請(qǐng)避免繼續(xù)在已有大量類似 app 的類別下進(jìn)行開發(fā)；App Store 上已經(jīng)有太多模擬放屁、打嗝聲音的 app，以及手電筒和愛經(jīng) app。上傳大量相似版本 app 的開發(fā)者會(huì)遭到 Apple Developer Program 的除名。

有過向 App Store 提交 App 被拒經(jīng)歷的人，大概都聽說過這個(gè)恐怖的 4.3 條款，下面做一個(gè)詳細(xì)的介紹：

• 【馬甲包】指的是內(nèi)容幾乎一樣，只是主題色或者是名稱等不重要信息略有改動(dòng)的雷同 App。
• 【4.3 條款主要針對(duì)誰】一方面源于很多大公司希望批量產(chǎn)出類似 App 進(jìn)行 A/B 測試；另一方面源于很多小產(chǎn)品希望通過對(duì)相同的產(chǎn)品用不同的關(guān)鍵詞來進(jìn)行宣傳，獲取更多的流量（同一個(gè) App，上 10 個(gè)馬甲包，收入增 10 倍）；這些行為破壞了 App Store 的生態(tài)，導(dǎo)致蘋果會(huì)用非常嚴(yán)格的手段來進(jìn)行打擊。
• 【4.3 條款麻煩在哪】第一點(diǎn)在于這個(gè)條款寧可錯(cuò)殺也不放過，就算你什么錯(cuò)都沒犯，也很可能被誤傷。 第二點(diǎn)在于，簡單的修改是不足以繞過這個(gè)條款的，一旦遭遇它，后面無論你怎么修改，再次重新提交也幾乎沒有通過審核的可能。
• 【4.3 條款并不是完全搞不定】如今上架馬甲包已經(jīng)變成了很多公司的一個(gè)常規(guī)性業(yè)務(wù)，只要手段合適，是可以進(jìn)行一定的規(guī)避的。
• 【什么情況可能導(dǎo)致遭遇 4.3 條款】提交 App 給人工審核之前，會(huì)先經(jīng)過一次機(jī)器審核，基本上就是個(gè)反編譯的過程。如果項(xiàng)目里面大量復(fù)用了其他 App Store 上線項(xiàng)目的代碼，會(huì)被機(jī)器審核回絕；如果產(chǎn)品形態(tài)和其他現(xiàn)有 App 幾乎一致，會(huì)被人工審核拒絕。

判定拒絕來源

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

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

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

工程混淆

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

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

對(duì)于工程層面的混淆，要做以下幾個(gè)工作：

• 項(xiàng)目里面的文件目錄、子文件夾排列等，盡可能改動(dòng)要大，完全打亂最好
• 所有圖片、音頻資源文件名，建議批量修改，為了便于批量處理，可以加上較長的前綴，比如“CodeExampleTest_123.mp3”
• 類名、變量名也建議批量重構(gòu)，Xcode 自帶了 Refactor - Rename 的重命名功能，直接加上前綴處理起來很快
• BundleID 一定要換，作為一個(gè)新 App 重新提交，并且最好和之前的 BundleID 差別較大

App Store Connect 清理工作

1. 清理二進(jìn)制文件

前往你的應(yīng)用的 AppStoreConnect 頁面，在 TestFlight 欄目下，找到你之前提交過的構(gòu)建版本，點(diǎn)擊“將構(gòu)建版本設(shè)置為過期”，這一步是必須要做的

2. 清理 App 信息

之前填寫過的關(guān)鍵詞、開發(fā)者網(wǎng)站鏈接、App 名稱、App 圖標(biāo)，全部換成無意義的隨機(jī)內(nèi)容，和你的真正內(nèi)容不要有關(guān)聯(lián)。如圖，這種空置的 App 我已經(jīng)有好多個(gè)了。

3. 換賬號(hào)

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

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

分階段測試審核

不確定自己的應(yīng)用能不能通過 4.3 審核的時(shí)候，可以不用急著一次上線全部內(nèi)容。

1. 內(nèi)容上
   在內(nèi)容上只上線最最核心的東西，第一次提交，能不要的東西都可以不要，比如設(shè)置頁什么的。這樣萬一你后續(xù)提交的都被拒，那么這一版可能成為你相當(dāng)長時(shí)間無法更新、甚至永遠(yuǎn)都無法更新的一個(gè)版本，你要保證它起作用。

2. 信息上
   一開始的版本，除了要把 ASO 的關(guān)鍵詞寫好之外，截圖、App Store 描述可以都只放最最基本的內(nèi)容，爭取先把第一關(guān)過了，后面更新再改這些內(nèi)容，哪怕代碼不動(dòng)，直接通過發(fā)版來更新這些內(nèi)容也行。

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

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

最后

不要迷信蘋果，不要自我懷疑。上架 App 是商業(yè)行為，App Store 拒絕你上架不能說明任何問題。蘋果公司能力極強(qiáng)，但是 App Store 的審核團(tuán)隊(duì)并不神圣。

不服就干，App Store 讓你上架，你就是合理的；App Store 不讓你上架，說明你能力不夠，搞贏 4.3 條款，你就是贏家，千萬不要因?yàn)楸痪芫陀X得問題出在你自身，上有政策，下就有對(duì)策。

閱讀更多內(nèi)容請(qǐng)前往我的付費(fèi)專欄 - KyXu 教你獨(dú)立開發(fā)，這是一個(gè)教獨(dú)立開發(fā)者賺錢的專欄，讓你的開發(fā)能力迅速變現(xiàn)！

延伸閱讀

入門：我就會(huì)寫代碼，怎么做獨(dú)立開發(fā)

入門：獨(dú)立開發(fā)者如何解決后臺(tái)問題

進(jìn)階：開發(fā)者如何用數(shù)據(jù)分析，實(shí)現(xiàn)收入指數(shù)增長

高級(jí)篇：獨(dú)立開發(fā)者如何利用內(nèi)購賺錢 - 訂閱制