行業資訊
產品推廣
營銷課堂
常見問題
營銷峰會
行業專題
立冬初至，但對很多ASOer來說，寒冬卻從未離開。11月了，蘋果依舊沒有對CP們網開一面。為了防止各位CP提前脫發，蟬蟬特地帶來了【App審核被拒指南】。
2.1 Performance: App Completeness（App 完成度）
建議：
（1）審核被拒出現“2.1大禮包”是蘋果審核團隊針對大范圍App的一種“盲拒”，盡管郵件內容多且提到開發者賬號可能被封，但性質并不算嚴重。
（2）先重新審查App確認是否存在明顯違規，盡量去掉可能存在風險的功能。
（3）在開發者后臺回復蘋果郵件，郵件內容措詞應禮貌，行文有條理，如果有存在明顯違規，直接告訴蘋果已經改好。沒有存在明顯違規的話可以針對蘋果郵件內容列出的條款逐條進行回復。
（4）等待審核結果，一般來說，“2.1大禮包”被拒回復郵件后等待審核的時間都不會太長。
2.3 Performance: Accurate Metadata（準確的元數據）
建議：
（1）2.3元數據被拒經常遇到的主要有以下這些原因
a、App名稱不合規：侵犯其他品牌的品牌詞；堆砌關鍵詞；含有與APP沒有任何關系的詞；字符數過多等
b、屏幕截圖不合規：沒有實際反映App的真實功能
c、應用圖標不合規：品牌侵權
（2）只遇到2.3元數據被拒絕，還是比較容易解決的，一般是蘋果審核后發現無其他嚴重性的問題，才會只給出2.3元數據拒絕。應仔細閱讀蘋果的郵件，并按要求更改不符合要求的功能和材料，改完后回復郵件，一般幾天內就能重新審核。
（3）如果遇到郵件中對存在問題指向不是很明確的，可以給蘋果回復郵件請求有針對性的指出問題所在，方便進行修改。
3.1.1 Business: Payments - In-App Purchase （App 內購買項目）
建議：
（1）對于使用第三方支付的問題，目前來說的話用提審時隱藏，過審后再打開的H5頁面跳轉的方式過審率會比使用SDK高些，鑒于現在蘋果審核越來越嚴格，建議每一次審核所用的H5跳轉接口的代碼應重寫。使用第三方支付存在一定風險，App上架后被發現還是會被下架，開發者應慎重選擇。
（2）如果審核在支付問題方面多次被拒，建議老老實實去掉第三方支付，走IPA的支付方式，相關代碼應清理干凈，不然容易在審核的時候被誤判。
4.2 Design: Minimum Functionality （最低功能要求）
建議：
（1）大多數情況下4.2被拒是App功能過于簡單或者蘋果審核人員對App的核心功能存在誤解，認為其不具有實用價值，不適合出現在 App Store 中。
（2）App功能過于簡單的話，應進行相應的修改，可以應付性添加一些垃圾功能或獨立開發一些新功能增加產品的亮點。不要使用商業化模板創建的應用，避免資訊聚合，鏈接聚合，直接嵌套網頁的 App。
（3）如果認為自己App的功能不存在問題，是蘋果誤解了你的應用，可以直接回復郵件申訴，詳細陳述該應用與App Store上其他應用的區別，增加了哪些核心功能，做了哪些細節性優化，能解決用戶的哪些需求點。
4.3 Design: Spam（重復 App）
建議：
（1）對于4.3馬甲包的問題，可能存在機審和人工審核被拒兩種情況，目前比較普遍的做法是換個賬號重新上包，并對包體和后臺設置的資料進行一定程度的修改，包體修改主要包括添加垃圾代碼和更改應用的UI風格同時添加一些假頁面。后臺設置包括修改名稱，屏幕快照，應用描述，上架地區等。
（2）對于如何添加垃圾代碼，可以讓技術人員去評估可行的方案和實施。修改應用的UI風格主要包括Icon和一些主要頁面，有條件的可以盡量多做一些改動。
（3）針對現在蘋果機審的能力越來越強，馬甲包要過審也是難上加難，目前市場上比較多的做法是準備多個賬號修改包體堆包提審，存在一定的過審概率，不過成本需要自己把控。
5.1.1 Legal: Privacy - Data Collection and Storage （數據收集和存儲）
建議：
（1）用戶隱私保護一直是蘋果公司所注重的，近來對App在數據收集和存儲方面的審核也愈加嚴格，App應只請求訪問與其核心功能相關的數據。
（2）對郵件中指出的涉及用戶隱私的相關部分進行更改，在使用相關權限采集用戶數據信息的時候給予用戶提示，征求用戶的許可。有存在“強登錄”功能的要修改為提示登錄的版本。
（3）可以在郵件中告知蘋果采集和存儲用戶數據信息的目的。如醫療類App獲取地域相關權限是為了根據地區更好地給用戶提供服務。
以上就是蟬蟬根據近期的app審核被拒原因整理的過包指南啦。
營銷產品
旗下平臺
聯系我們
關注天擎天拓
