三步走起 提升 iOS 審核通過率 上篇

<ignore_js_op>  

Bugly 技術干貨系列內容主要涉及移動開發方向，是由 Bugly 邀請騰訊內部各位技術大咖，通過日常工作經驗的總結以及感悟撰寫而成，內容均屬原創，轉載請標明出處。

 

2016年的第一天，各位小伙伴兒們，新年快樂~~~在過去一年里，負責 iOS 應用開發的同學們，想必已被 APP Store 的審核機制折磨心累不止。新的一年，又一輪審核即將來襲，你們做好准備了么？

為了幫助各位 iOS 應用開發的同學免受折磨，騰訊 Bugly 特邀互娛 iOS 預審組的同學通過大量的數據分析，對蘋果的審核機制進行了一番總結，連夜趕稿寫出提升 iOS 審核的通關秘籍（因為內容較多，因此分為上下兩篇），來與大家分享。

經過互娛 iOS 預審組近一年的數據監控，分析過往提審被拒的案例，我們對 iOS 的審核進行了縝密分析，統計出最常見的被拒原因：

 

 

通過以上案例，並結合《蘋果應用商店審核指南》，大體可以將審核工作分為三塊：客戶端資源檢查、應用內容檢查、提審資源檢查，我們將通過這三步來為您揭秘iOS審核的真相。

第一步：客戶端檢查篇

客戶端檢查的主要目的是通過客戶端配置檢查來保證客戶端符合蘋果的開發者規范以及其他更新的要求，包括存儲系統、配置文件、網絡連接（VPN）、icon檢查、私有API檢查，提審前的審核會覆蓋這幾個部分的各個測試點。

1.存儲系統檢查

蘋果官方對用戶數據存儲有嚴格的規范，因此如果要通過審核，首先要了解一下蘋果官方數據存儲指引的相關內容：

被拒條款：2.23

Apps must follow the iOS Data Storage Guidelines or they will be rejected.( 應用啟用iCloud存儲功能后，必須遵守iOS數據存儲指南，否則將被拒。)

被拒案例

被拒原因描述如下：

We found that your app does not follow the iOS Data Storage Guidelines, which is required per theApp Store Review Guidelines.
In particular, we found that on launch and/or content download, your app stores 5.6 MB. To check how much data your app is storing:

• Install and launch your app
• Go to Settings > iCloud > Storage & Backup > Manage Storage
• If necessary, tap “Show all apps”
• Check your app’s storage

The iOS Data Storage Guidelines indicate that only content that the user creates using your app, e.g., documents, new files, edits, etc., should be backed up by iCloud.
Temporary files used by your app should only be stored in the /tmp directory; please remember to delete the files stored in this location when the user exits the app.
Data that can be recreated but must persist for proper functioning of your app - or because customers expect it to be available for offline use - should be marked with the “do not back up” attribute. For NSURL objects, add the NSURLIsExcludedFromBackupKey attribute to prevent the corresponding file from being backed up. For CFURLRef objects, use the corresponding kCFURLIsExcludedFromBackupKey attribute. 

簡評:

應用在啟動時就在Documents下產生了5.6 M的數據，說明不是用戶自行創建並用於備份的，通過修改應用，在document目錄加一個不備份的屬性(NSURLIsExcludedFromBackupKey)后審核通過。再來總結一下iOS5以后的存儲規范：

ü  只有那些用戶生成的文檔和其他數據或者是那些不能被你的應用所重建的數據應當保存在/Documents 目錄內。這些數據文件將會自動的通過iCloud備份。

ü  那些可以重新下載或者重新創建的數據應當保存在/Library/Caches 目錄內。你可以把數據庫緩存文件或者可下載的內容如雜志、報紙、地圖應用的數據等放入緩存目錄里（Caches directory）

ü  臨時需要的數據應該保存在/tmp 目錄內。盡管這些文件不會備份到iCloud里，但記住不再需要它們時立即刪除掉這些文件，這樣它們就不會繼續浪費用戶設備的儲存空間了。

ü  使用“do not back up”屬性指定不需要iCloud備份的文件（比如需要離線環境使用的文件；該屬性能在任何目錄下生效）。由於這些文件占用設備空間，所以應用需要有一套定期監控與清理這些文件的機制。

應對措施

本例中該應用未啟用iCloud備份，如果啟用了iCloud備份，則可以通過把較大的數據（模板類、聯網下載的數據等）存到/Library/Caches目錄，則同樣可以解決問題。

2.配置文件（Info.plist）檢查

每個 APP 都使用Info.plist文件來存儲以上的元信息，就是通常所說的 “屬性列表”。IOS用Info.plist來決定bundle所顯示的icon，當前app支持打開的文檔類型，等等其它的信息。正如以上所提到的，Info.plist本身是一種結構化的文本文件，它包含了一些重要的配置信息。關於此部分的檢查，我們通常關注如下方面的內容：

被拒條款

Multitasking Apps may only use background services for their intended purposes: VoIP, audio playback, location, task completion, local notifications, etc.（多任務應用只允許在后台運行如下相應的服務：VoIP，音頻播放，地理位置，任務記錄，本地提醒等。）

被拒案例

被拒原因描述：

We found that your app uses a background mode but does not include functionality that requires that mode to run persistently. This behavior is not in compliance with the App Store Review Guidelines.

We noticed your app declares support for VoIP in the UIBackgroundModes key in your Info.plist but does not provide any Voice over IP services.

We recognize that VoIP can provide “keep alive” functionality that many app features would like to use. However, using VoIP in this manner is not the intended purpose of VoIP, which, as indicated in the iOS Application Programming Guide, is that: “A Voice over Internet Protocol (VoIP) application allows the user to make phone calls using an Internet connection instead of the device’s cellular service.”

It would be appropriate to add VoIP features or remove the “VoIP” setting from the UIBackgroundModes key.

簡評:

應用為了實現后台保持在線的功能，在 Info.plist 中定義的 UIBackgroundModes，間接聲明了支持 VoiP 功能，實際應用被蘋果認為並未按照 Voip 的定義去實現，導致被拒；從 Info.plist 移除了 UIBackgroundModes（VoIP）和相關代碼后審核通過。總結，應用首次提交審核時，有爭議的功能盡量先砍掉，先保證盡快上架。

3.網絡連接（VPN）

大多數App的審核服務器是部署在中國，然而蘋果的iOS審核團隊卻又是在美國，他們進行審核時，使用的是美國網絡，跨洲際的網絡連接，難免會出現時延大、抖動、丟包等網絡問題，因此被拒。

應對措施

為了提前驗證App后台服務器基於此場景下的反應，預審團隊采用美國VPN方式來模擬蘋果審核團隊的訪問網絡環境。

4.Icon檢查

蘋果官方對iPhone、iPad、iPod等應用程序的icon有明確的要求：要求ipa包中必須包含180x180，120x120，76x76，152x152尺寸的PNG格式的icon（詳見下表），並且不同尺寸的icon內容要一致。

5.私有API檢查

私有API是指放在PrivateFrameworks框架中的API，未公開的API是指雖然放在Frameworks框架中，但是卻沒有在蘋果的官方文檔中有使用說明、代碼介紹等記錄的API。

之前 APP Store 便下架了包括《爸爸去哪兒2》、《找你妹》在內的256款APP，原因是調用私有API，很明顯，蘋果明確不允許App使用這類API。

被拒條款：2.5

Apps that use non-public APIs will be rejected.（使用非公開API的應用會被拒。）

被拒案例

被拒原因描述如下：

We found that your app uses one or more non-public APIs, which is not in compliance with the App Store Review Guidelines. The use of non-public APIs is not permissible because it can lead to a poor user experience should these APIs change.
We found the following non-public API/s in your app:
descriptionWithCalendarFormat:
If you have defined methods in your source code with the same names as the above-mentioned APIs, we suggest altering your method names so that they no longer collide with Apple’s private APIs to avoid your application being flagged in future submissions.
Additionally, one or more of the above-mentioned APIs may reside in a static library included with your application. If you do not have access to the library’s source, you may be able to search the compiled binary using “strings” or “otool” command line tools. The “strings” tool can output a list of the methods that the library calls and “otool -ov” will output the Objective-C class structures and their defined methods. These techniques can help you narrow down where the problematic code resides.
We appreciate that you may have made the precautions in your code for using non-public APIs, however, there is no way to accurately or completely predict how an API may be modified and what effects those modifications may have. For this reason, we do not permit the use of non-public APIs in App Store apps.

簡評：

這個條款被拒的描述文字比較多。先來看看蘋果API的分類：

1) Published API（公開的API）：又稱 Documented API（文檔中記錄的API）。是蘋果通過 Cocoa Touch 向全世界第三方開發者公開的所有 API 。

2) UnPublished API（未公開API）：又稱 Undocumented API（文檔中未記錄的API），是指雖然放在Frameworks框架中，但是卻沒有在蘋果的官方文檔中有使用說明、代碼介紹等記錄的API。按蘋果的說法，未公開的API是還不夠成熟，可能還會變動的API，等完全成型了后會變成公開的API，但是目前不對其提供承諾，就是系統版本升級后可能會失效。

3) Private API（私有API）：指的是SDK下的 PrivateFrameWorks框架下的API，真實存在於 Cocoa Touch 中。私有API是蘋果明確規定不能使用的API，當然在越獄渠道沒這個限制，比如91渠道。

被拒文字中的non-public APIs，后兩種分類都算。源碼中如果恰好定義了方法與非公開的API重名，也會導致被拒；比較常見的是，使用的第三方靜態庫中，包含了非公開的API，那么可以通過strings或otool命令來查找相關的API：

strings LibName.a | descriptionWithCalendarFormat 

或

strings AppName.app | descriptionWithCalendarFormat 

其中.app是編譯結束后Build目錄下的文件。

使用otool –ov LibName.a 輸出Object-C類結構以及定義的方法。

應對措施

采用自動化工具掃描來實現，實現原理如下：

1、獲取未公開庫：基於iOS的SDK，dump出全庫，全庫減去私有庫和公開庫后，得到未公開庫（non-public API）；

2、獲取頭文件方法和成員的列表：使用Otool等工具，對ipa的可執行文件進行反編譯解析，獲取頭文件中方法和成員的列表；

3、與未公開庫、私有庫進行匹配：將列表中的方法和成員，分別與私有庫和未公開庫進行匹配，如未有匹配成功項，則掃描通過，如有匹配成功項，則掃描不通過（給出告警和API名稱）。

6.硬件與版本差異

iOS 2007年作為手機系統發布至今，已經陸續套用到iPod touch、iPad以及Apple TV等產品上，並更新了多個版本。而蘋果的硬件也在不停地推陳出新，外部市場上也已經有比較多的產品硬件版本，面對如此之多的硬件及系統版本，怎么去保證提審版本的質量，是一直困惑測試和產品團隊的大難題。

被拒案例

對應措施

1、與蘋果關注同樣的驗收版本：推測蘋果審核團隊設備驗收選型也會遵循原則：驗收最新發布的兩個系統版本，兩個硬件版本。保證游戲可以在市場占有率最高的兩個系統版本及硬件配置上可以流暢運行。

2、關注beta版本：蘋果在新版本上線前會發布beta版本做少量測試，此時需要跟進beta版本，可以提前發現問題，避免突然版本發布造成措手不及。

總結：

1、實際上存儲系統的檢查是一套規范，遵循同系列理念，比如用戶本地存儲空間與蘋果iCloud服務器存儲的合理使用，節約空間；

 

2、Info.plist文件檢查實際上是xml文件的鍵值檢查，並且值檢查關系是並列的。通過存儲文件、plist用例的檢查，基本避免了因該類原因被拒的情況；

 

3、通過自動化工具掃描是否調用了私有API， 蘋果除了對提審版本掃描還會不定期對線上的版本進行掃描，所以別想着通過雲控開關或者代碼下發來繞開私有API。同樣需要注意的是，不調用私有API，但跟私有API函數重名也會被apple認為違反了私有API規定。