那些年提交 AppStore 稽核踩過的坑

感謝@雲峰小羅投遞   原文連結

做iOS開發近5年了，每次提交版本時不可謂不小心翼翼，如履薄冰，但是還是難免踩到了一些坑。蘋果的官方文件（AppStore稽核條款）這裡就不羅列了，太冗長繁瑣了，而且大部分是一般app都不會觸碰的到的，今天我主要想以自己的親身經歷，跟大家回顧一下這些年我提交AppStore稽核時踩過的坑，並且針對如何避免給出一些tips供大家參考。大神請忽略，專家請輕拍。

1、未遵守蘋果iOS APP資料儲存指導方針。

如果你的App有離線資料下載功能，尤其需要關注這一點。因為離線資料一般佔用儲存空間比較大，可以被重新下載和重建，但是使用者往往希望系統儲存空間緊時也依然能夠妥妥的存在著，不會被IOS系統自動清理掉。所以不能放在/Library/Caches 目錄下（該目錄在系統空間緊張時可能會被iOS系統清除）。 那就只能放在主目錄/Documents  或 主目錄/Library/自定義資料夾下，這樣才不會被iOS系統自動清理掉。但是這些資料可能會很大，如果放在 主目錄/Documents  或 主目錄/Library/自定義的資料夾下，會被iCoud自動同步，那麼使用者需要為了同步消耗不少流量，蘋果可能會因此拒絕你的應用上架。所以需要在程式中給自定義的目錄設定“do not backup”屬性。

關於資料儲存需要注意的點，總結在下面：

關鍵資料

內容：使用者建立的資料檔案，無法在刪除後自動重新建立

路徑：主目錄/Documents

管理：iOS系統即時遇到儲存空間不足的情況下，也不會清除，同時會備份到iTunes或iCloud中

快取資料

內容：可用於離線環境，可被重複下載重複生成，即使在離線時缺失，應用本身也可以正常執行

路徑：主目錄/Library/Caches

管理：在儲存空間不足的情況下，會清空， 並且不會被自動備份到iTunes和iCloud中

臨時資料

內容：應用執行時，為完成某個內部操作臨時生成的檔案

路徑：主目錄/tmp

管理：隨時可能被iOS系統清除，且不會自動備份到iTunes和iCloud，儘量在檔案不再使用時，應用自己清空，避免對使用者裝置空間的浪費

離線資料

內容：與快取資料類似，可以被重新下載和重建，但是使用者往往希望這些資料即使在儲存緊張時也不會被系統自動刪除

目錄：主目錄/Documents  或 主目錄/Library/自定義的資料夾

管理：與關鍵資料類似，即使在儲存空間不足的情況下也不會被清除，應用自己應該清除已經不再使用的檔案，以免浪費使用者裝置空間 。需要設定”不備份到iCoud” ，否則會稽核不過。

2、未提供測試賬號

如果你的App有部分功能需要登入才能使用，那麼你需要再提交稽核時，勾選演示賬戶，並提供對應資訊，如下圖：

測試賬號填寫

現在很多app為了更方便快捷，防止使用者忘記密碼，都採用手機號+驗證碼的方式，這樣的話就沒有辦法給蘋果提供演示賬戶了，除非賬戶系統後臺做修改提供支援。這種情況，就不需要勾選演示賬戶了，但是要在備註資訊裡跟蘋果好好解釋一下，說我們也是為了提升使用者體驗的，所以對賬戶系統做了改進，使用者有手機就能登入，不需要註冊啥的，如下圖。如果你啥也不說的話，那就乖乖等著被拒吧。

測試賬號說明

3、跟相關硬體配合使用的app，未提供演示視訊。

這裡指的硬體是不需要MFi認證的，通過BLE（低功耗藍芽）或者WiFi連線的硬體。直接在備註裡提供相關功能的演示視訊即可，如下圖。

硬體連線演示視訊

演示視訊需要把完整的連線過程操作以及連線硬體之後跟硬體相關的功能演示都包含在內。從截圖可以看到我的“褲寶”演示視訊我是直接放在優酷上了。所以並不像傳聞中那樣，需要翻牆放到YouTube上，直接放優酷土豆或者百度網盤都行。也不需要用英文，用中文即可。

4、跟相關硬體配合使用的app，未提供PPID.(Product Plan ID )

如果你的App是需要跟通過MFi認證的硬體進行互動，即使用了EA框架（ExternalAccessory.framework），配置了協議字串（Supported external accessory protocols），那麼你需要在備註資訊裡提供PPID。

ppid說明

很多時候，我們的App可以同時適配很多型號的硬體，每個型號的硬體對應的PPID不一樣。如果AppStore提交稽核通過之後，又新增了一款型號硬體支援怎麼辦呢？是否需要單獨發一個版本，把對應的PPID增加上去了？ 答案是不需要，因為App支援的PPID列表資訊是放在備註資訊裡面的，往列表中新增PPID並不需要修改到二進位制檔案資訊，蘋果在這裡也比較人性化，可以在不提交新版本的情況下增加PPID資訊。

5、使用了後臺定位服務，但是沒有具體說明原因

之前使用後臺定位功能的app都是隻需要在在Info.plist中配置 Required background modes -App registers for location updates 即可.但是從2016年的某個時候開始蘋果突然要求如果App要使用定位功能，除了程式裡做配置，還需要在介面上顯式告訴使用者你的後臺定位是用來幹啥的，否則你就會收到類似下面的郵件。

1.1 – Apps using background location services must provide a reason that clarifies the purpose of the use, using mechanisms described in the Human Interface Guidelines.

要修改也可以簡單，根據你的app需要在info.plist中配置，NSLocationAlwaysUsageDescription或者NSLocationWhenInUseUsageDescription欄位說明。如下圖

定位目的說明

6、上傳的螢幕快照跟App具體使用截圖相差太遠

AppStore提供的螢幕快照功能是為了使用者在未下載時可以直觀的瞭解這個App的功能、介面大概是什麼樣的。所以蘋果也允許開發者對螢幕截圖做一些加工美化，並不一定要是原始截圖。但是這裡有個限度，就是不能相差太遠，具體尺度蘋果沒有給出量化標準。  公司專案中有個大版本上線了一個比較大的新功能，為了突出宣傳這個功能，設計師就重新設計了一套非常Q版的功能演示截圖。結果上傳後被蘋果告知，螢幕快照不符合App本身的功能。

以上這些是本人在AppStore稽核時親自踩過的一些坑，當然還有很多坑，我和我的團隊注意到了所以努力避免了，但是個人認為也是非常需要注意的，我簡單列在下面供大家參考。

使用未公開的API被發現

使用和系統接近的圖示

介面太醜 或者互動太過複雜

不穩定，容易崩潰

跟應用市場上其他App太過雷同

App內有檢測更新

出現第三方作業系統的名字或圖示

測試不充分，某些App宣告支援的作業系統版本有相容性問題

tips

我們說了這麼多踩過的坑，或者差點踩過的坑，無非就是想在以後App開發中儘可能的避免。這裡介紹本人的一些經驗總結，供大家參考。

1、預防在先

對產品經理規劃的功能，首先需要判斷是否在技術上可以實現，或者說在不使用非公開API的前提下實現。因為很多時候，即使你通過函式名動態拼接等技術手段在提交稽核時躲過API掃描，但是也難免被蘋果從功能上發現或者被競爭對手舉報。然後對互動設計和UI效果圖需要有自己的判斷，介面不能太醜，互動不能太複雜，不能使用跟系統太過雷同的Icon。

2、發版前過checklist

每個專案都需要沉澱發版前的checklist，把之前踩過的坑進行備忘，也可以通過網路資訊等手段瞭解最近時間被拒的一些主要原因，把可能跟自己APP相關的部分進行備註，然後在發版前逐條檢查一遍。

3、預提交AppStore稽核

如果也預防了，發版前也過了checklist，但是有時候還是難免百密一疏有所遺漏，特別是新功能較多的版本。這裡我要重點推薦的就是預提交AppStore稽核。專案的版本都是有發版週期的，一般在發版前一週左右App版本基本穩定，只是還需要修改一些bug並回歸測試。這個時候完全可以先提交一個版本到AppStore去稽核，反正版本號是用不完的，只要不佔用產品經理定的版本號就行。預提交稽核有什麼好處呢？

(1)可以幫助暴露潛在的問題。

這個版本可能開發了一些新功能，然後有些地方可能沒有考慮到稽核相關的風險。如果等待專案都要結束正式發版時才暴露出來，就追悔莫及了。

(2)在迫不得已的情況下，可以試探一下蘋果的界限。

蘋果稽核條款其實很多時候是沒有一個量化標準的，比如螢幕快照不能跟App具體使用時的截圖相差太遠，拿到UI設計師給到螢幕快照時，我們有時候也沒有辦法確定到底是否真的符合蘋果的規範，但是沒有關係，我們先提交一個版本試一試就知道了；還有再比如前段時間，蘋果要求6月1號以後提交的App都要支援IPV6-Only的網路。但是由於歷史原因，專案中有個功能用的是第三方的SDK，他們沒有辦法在我們發版前提供新的支援IPV6的版本。然後我看網上也有人分享說蘋果對這個要求並不是非常嚴格，只需要在iOS9下主要功能能支援IPV6就行了。當然作為專案負責人，肯定也不能說直接把這個功能砍掉不要了，亦或輕信網友所言忽視風險。怎麼辦呢？趕緊先預提交一個版本試一下再做決定。結果是確實可以通過稽核，所以最終版本沒有砍掉這個功能，保證了產品的完整性上線了。

4、關於AppStore加急稽核

如果經過前面的努力，你還是被拒了，或者App的釋出要趕上某個時間運營節點，但是由於各種原因導致預留給App稽核的時間太少了。這個時候你需要使用到蘋果的加急稽核通道。

你在百度裡搜尋iOS加急稽核，你會發現有很多宣稱可以幫你快速稽核的人，24小時通過稽核，稽核通過後付款，不通過不要錢。如果你不知道蘋果有官方的加急稽核功能，你就很容易被這些空手套白狼的人所騙，而且收費都是5000RMB起步。那我真的很想對你說，找我吧，給你友情價打5折。

蘋果的加急稽核如何使用呢？ 在iTunesconnect頁面，點選右上角的“?”圖示，在彈出選單中選擇“聯絡我們”，

聯絡我們

然後在Contact Us頁面，選擇“App Review” —> “App Store Review” —>” Request Expedited Review”,

加急稽核選項

最後在表格裡填寫相關資訊，其中最重要的寫你需要加急稽核的原因。一般是寫要趕某個重大節日運營節點，或者緊急修復某個嚴重的閃退問題，然後註明閃退現象復現的詳細步驟，就可以了。

關於具體加急稽核有沒有次數限制，次數是跟App相關還是跟開發賬號相關，蘋果並沒有官方的說明。但是可以肯定的是，網上傳聞一年只有兩次加急稽核的機會是不正確的。不過為了讓好鋼用在刀刃上，還是慎用這個功能，以防到時真的有需要加急稽核時卻得不到響應。

從今年上半年開始，app稽核時間大大縮短了，一般都不需要用到這個功能了。百度CarLife 最近幾個版本都是3天就通過稽核了，尤其是最新的支援EAP連線的版本V2.1.0，一個晚上就稽核通過了。

毛主席告訴我們“與天奮鬥，其樂無窮！與地奮鬥，其樂無窮！與人奮鬥，其樂無窮！”，但是作為iOS開發者，跟蘋果奮鬥，還是小心謹慎為好。最後提一句， 如果你知道你的app存在某個稽核風險，但是通過了蘋果稽核，那麼不要存在僥倖心理，請儘快修改。因為畢竟蘋果是人工稽核，這個版本過了可能是稽核人員心情好，並不代表下個版本稽核時心情也這麼好。

其實想想最近的廣電總局手遊審查新政，對AppStore的稽核規則也就沒有啥可以抱怨的了。