iOS 開發者在 App Store 審核過程中出現過哪些事前不易覺察的錯誤？

01-17

說幾個。

曾經用過一個生僻的6969埠，然後審核人員死活連不上，也許是他們防火牆的原因？折騰了一個多月之後，發現把6969改成8080他們就審核通過了。

有一次被拒是因為提供了一個五天的訂閱功能，被告知不能少於七天。

有一次，採用了伺服器端驗證收據的IAP, 自己測試用的sandbox.itunes.apple.com, 成功了之後改成http://buy.itunes.apple.com之後審核怎麼都不通過。後來還是用sandbox,審核的時候通過了，但是實際使用的時候用不了。原來自己測試和apple審核的時候都要用sandbox, 上線之後自行改成buy. 後來我就改成兩個網址都兼容了，先去sandbox驗證，不行再去buy.

想到了再補充。

－－－－－－－－－－－－－－－

@陶小米，剛剛因為"覺得好用請在AppStore里給予好評，我們會有動力做得更好"和"到AppStore給個好評吧!"被拒!

說個我的：第一次在 App Store 提交應用時，在應用程序說明裡提供了一個優酷視頻鏈接，但忘了視頻錄製的是同一個 App 的 Android 版。然後，順利地被 rejected 了......

好丟人...... = =

我來說說 MAS 被拒的經歷吧，

1，2011年，Mac App Store 剛開始上限，我做了一個查詢保修提醒保修的 iChecker，結果第一次被拒，因為 AppleCare 寫成了 Apple Care。第二次被拒，是因為它認為我窗口動作不對，我說當時Twitter官方客戶端就是那樣的，他說他行不行你別管，反正你不行。第三次被拒，是因為我連線查詢的時候沒有提醒用戶我要訪問互聯網。共三次折騰了一個月。

2，ezText 1，第一次因為使用的三方庫中有一個地方使用了Private Framework被拒。第二次因為強制要求sandbox，結果提交上去說我訪問 Documents/test.txt，我最終也沒找出解決方法。直接把原來的重新打包提交結果就過了，無厘頭。

3，ezText 2，說我為改變實際字元編碼，不過這確實是我的錯，顯示的時候搞錯了。

4，

謝謝問題。我從09年開始到現在做過三十多個APP,被拒無數次，終於可以在這個問題里，做個總結。

幾個典型的問題：

2009年做過美女的app, 因為圖片涉嫌版權問題被拒。這個app最終沒有上app store,破解版放在91了，下載量還不錯。

2010年做Notebook, 提交了app,但是沒有提交IAP. IAP的提交比較坑，不僅要提交app還要在iap頁面提交iap審核。

2012年做iDocs,這是Google Docs（當時還不叫Google Drive）的客戶端，因為名字叫Google Docs被拒，理由這樣的名字容易被用戶認識是Google 官方的客戶端，後來改為- iDocs - Google Drive Client通過了。

另外,iDocs還因為加入了Gmail的註冊鏈接被拒，不能引導用戶到蘋果體系之外付費，我以為是蘋果和谷歌有仇，後來去掉了Gmail註冊鏈接，成功通過。

2011年遠程桌面的程序。圖標用了windows圖標，圖標版權問題，把圖標修改了一個形狀，通過。

2011年iPhoen壁紙，壁紙宣傳畫中用到了蘋果圖標，把全部蘋果圖標換掉後通過。我勒個去，競爭對手全部是用的蘋果的原生圖標。

2011年Quick Word（Mac程序）沒有加入Sandbox被拒（當時蘋果規則改變），之前，不加入sandbox模式是沒有問題的。

2012發布多個類似程序，類似程序不能多次發布，被拒。

還有好多，想不起來了。

最近的一些，idea note發布的icloud沒有調好，被拒。發布和開發沒有用同一個證書，bundle id不一樣，team id也不一樣。

也有一開始能夠通過，升級版不然通過，我們做了一個iPad計算器，下載用戶有幾百萬，小小得意一下，英文叫Caculator++,最初是通過審核，一年之後提交升級版，不讓通過，認為名字容易誤導用戶，與蘋果默認計算器類似，強迫改名。

最近發布的mac遠程桌面，沒有提供測試伺服器給蘋果測試被拒。

還有無數次程序有Bug被拒。以我的概率，提交之後一半的情況會被拒掉。不過，沒有關係，一星期後又可以再被審核一次。

最重要的是，蘋果很公平，大公司個人都是一樣對待，一樣得等，一樣的標準，所以，不管蘋果審核如何麻煩，他們是在維護這個市場，而且，所有人都是公平的，不像很多國內平台，需要維護關係。蘋果這樣的平台，其實讓我們省心很多。

「給個五星評價吧」，結果被無情的拒了，官方回應，你不應該引導用戶評5星

app介紹里的拼寫錯誤。

不說了，太丟人。

蘋果在官網給出了截至2016年6月份應用被拒絕的十大條款（其中63%以上的應用被拒絕都是因為這10個條款），看似簡單的條款，仍然出現很多提審被拒，其實，開發者對審核條款理解和把控不夠系統，是導致提審被拒的主因。

那麼，看似讓人眼花繚亂的審核條款，我們有沒有什麼辦法準確和系統的去把握呢？對此，騰訊預審團隊從2014年便開始嘗試一系列的探索和積累：

1. 分析《蘋果應用商店審核指南》的條款，結合過往提審被拒的案例，進行系統的測試設計，並輸出成可落地的測試用例；

2. 在以上步驟的基礎上，進行自動化分析，抽離出可自動化的模塊（開發對應的自動掃描工具）；

3. 將剩餘的部分用例，組建專項的測試人員來進行驗收；

4. App每次版本提審，通過以上測試驗收後，才會正式提交給蘋果審核；

【騰訊預審的探秘】

根據以上工作思路，騰訊預審團隊對審核對象進行模塊的劃分，主要包含ipa包、提審資源以及應用內容和功能3大模塊（一共整合了150+個測試點及測試用例，其中自動化掃描項70+個）：

? ipa包的檢查

主要是確保ipa中info.plist、包/文件大小、icon規格、私有API、第三方SDK、64位等內容符合蘋果要求，此部分的驗收，騰訊預審團隊已開發出自動化工具，通過自動掃描來完成；

? 提審資源的檢查

主要是確保提交的應用截圖、視頻、AppIcon、應用描述等資源是符合蘋果要求的，其中資源規格屬性的驗收，預審團隊已開發出自動化工具，通過自動掃描來完成；但資源的內容、文案等部分內容的驗收，還需要人工來審查；

? 應用內容和功能的檢查

確保應用的內容滿足蘋果審核審核指南中安全、性能、設計、法律等章節的條款，通常需要覆蓋安裝、登錄、IAP支付、公告、活動、郵件、icloud文件存儲、美國VPN網路連通性、IPv6網路連通性等應用場景內容和功能，此部分的驗收，全需要人工來審查；

除此之外，預審團隊通過實時跟進蘋果審核動態，依此來不斷的更新和完善驗收方案，持續保障產品的提審通過率，得到越來越多產品的認可，截止到今年7月，服務App產品已累計100+個，每月完成的轉測次數120+次。在2016上半年的提審數據統計可見，儘管有IPv6、提審圖片/視頻等政策變更的衝擊，提審通過率仍舊保持在85%以上，體現了預審方案的工作成效：

各模塊被拒的佔比，詳情如下圖：

在以上被拒的數據統計中，可以發現，更多的是在遊戲功能、內容和提審材料的內容，而ipa包和提審資源規格部分被拒的次數佔比很少，自動化工具帶來的質量和保障也得以體現。

【預審測試內容解讀】

1、Ipa包的檢查

Ipa包檢查項主要包含以下幾方面，如info.plist、私有API、第三方SDK、64位、icon文件等等，其中幾個重要掃描規則我們將逐一進行介紹：

1.1 Info.plist檢查

Info.plist是一種結構化的文本文件，通常所說的「屬性列表」,iOS的app都使用Info.plist文件來存儲元信息，用來實現決定bundle所顯示的icon，當前app支持打開的文檔類型，服務聲明等等。關於此部分掃描規則，來源於《Information Property List Key Reference》，包含如下方面的內容：

1.2 Icon檢查

蘋果官方對iPhone、iPad、iPod等應用程序的icon有明確的要求：要求ipa包中必須包含180x180，120x120，76x76，152x152，167x167尺寸的PNG格式的icon（詳見下表），並且不同尺寸的icon內容要一致，關於此部分的掃描規則，來源於《iOS Human Interface Guidelines》：

關於App icon的檢查，採用自動化方法實現自動解壓ipa包，並逐一核實icon圖標是否存在並滿足要求，對於不滿足要求的ipa包，給出告警提示：

1.3 私有API檢查

私有API和non-public API，是蘋果明令禁止的條款，每次預審都會重點跟進這部分的掃描結果。關於這塊自動化的思路，在之前分享的一些文章中也曾提過了，主要是採用一些反編譯工具，對ipa的可執行文件進行反編譯解析，獲取頭文件中庫、方法和類的集合，再去逐一比對私有庫和non-public庫，如有命中則給出告警提示：

1.4 文件大小檢查

此部分掃描內容，主要包含ipa包的大小、可執行文件的正文段大小和包中每個文件的大小三個方面：

掃描如有不滿足項，則給出告警提示：

提審資源的驗收規則，來源於《iTunes Connect Developer Guide》和《App Store Review Guidelines》，預審主要覆蓋以下幾個方面內容：

【經典案例】

【案例1】《項目A》x.17.5版本，提審圖片不能真實反應App的內容，導致被拒。

【應對措施】圖片中盡量避免提供與應用無關的內容，要表現出應用的真實內容，尤其是遊戲類應用的截圖，需體現遊戲場景、畫風、特色玩法等。針對此問題，產品修改並通過蘋果審核的圖片如下：

【案例2】《項目B》x.1.10版本，視頻中出現手機設備、並且存在遊戲中沒有的內容，宣傳成分太多，因此被拒。

【應對措施】在蘋果真機設備上錄製應用的真實內容，盡量避免加入廣告、特效等宣傳成分的內容。

3、應用內容和功能的檢查

蘋果針對應用內容和功能的審核，往往會比較嚴格，如果其中一點不滿足條款便會拒絕版本，因此，大家需要熟記每個審核要點，同時也盡量要遍歷應用功能。功能遍歷時要注意重要機型和固件的適配，盡量是最新的iPhone和Pad（如應用不支持Pad，可以忽略），固件也盡量是最新的版本。對於特殊時間段，比如在秋季新系統發布前，要提前摸底beta版本兼容性，避免新系統發布時出現不可預知的兼容性問題，阻塞版本的提審節奏。

現在蘋果要求App兼容IPv6網路（2016年6月1號以後上架/更新的App，必須兼容IPv6），提審前需確保應用在IPv6網路下可正常登錄（IPv6網路可按照蘋果官網提供指導進行部署）。除此之外，美國VPN網路也不能忽視。因為蘋果的審核團隊在美國，他們進行審核時，使用的是美國網路，跨洲際的網路連接，難免會出現時延大、抖動、丟包等網路問題，為了提前驗證App後台伺服器基於此場景下的反應，美國VPN來模擬蘋果審核團隊的訪問App，可以提前爆露一些問題。

預審對這部分的驗收，主要是包含以下兩個模塊：

文字內容的檢查

主要檢查應用中的公告、活動、提示，遊戲類的郵件、新手指引、劇情對白等，同時還覆蓋應用中鏈接的官網、論壇等網頁內容，確保文字內容是滿足蘋果審核的相關條款；

應用內容的檢查

主要覆蓋應用中的圖片、動畫、視頻、遊戲的角色造型/PVE/PVP等場景界面，確保以上內容滿足蘋果審核的相關條款；

這裡推薦一款——自動化掃描工具
為了提高騰訊內部產品在蘋果審核的通過率，騰訊專門成立了蘋果審核測試團隊，打造出iOS預審工具這款產品。經過1年半的內部運營，騰訊內部應用的iOS審核通過率從平均35%提升到90%+。

現將騰訊內部產品的過審經驗，以線上工具的形式共享給各位。在WeTest騰訊質量開放平台上可以在線使用。點擊鏈接： iOS預審 - 騰訊WeTest 即可立即體驗！

事無巨細，主要的工作思路是圍繞《蘋果應用商店審核指南》來開展驗收工作，並且實時跟進蘋果審核政策的動態，來確保預審的方向和質量。詳細內容可見專欄文章iOS審核總被拒？騰訊教你提升iOS審核通過率！ - 負荷的文章 - 知乎專欄

提供IAP購買時，要同時提供恢復購買按鈕

近期蘋果審核頻繁被拒，忍不住拿幾年前的問題吐槽

應用存在第三方支付，被拒

圖片裸露，被拒

應用評級內容不符合，被拒

ASO過度，被拒

適用人群選擇不合適，被拒

存在熱更新功能，被拒

第一次：開啟關卡使用虛擬貨幣被拒，要求改成直接花錢

第二次：內購道具沒有restore功能被拒

試過做一個列表寫些即將上線的城市，被拒了。明明寫著即將上線的城市，郵件說是提供了虛假的地區無法操作。

還有最近一次同步到iCould的數據文件超過2.5M，被據了。添加不同步屬性後過了。

在宣傳圖片里出現任何與Apple、Jobs相關的內容，早晚被拒

應用內含有裸露的圖片，而等級設置又不匹配的話也會被rejected。

做了一款與網站進行資料庫同步的app，因為網站的一些產品介紹里寫了測試資料的字樣....被拒絕了

第一次，預覽效果帶有蘋果系統自帶的app圖標，被告知不可使用蘋果圖標。被拒。

第二次，我們把預覽改成自己公司其他產品線的app圖標來豐富效果，被告知不可使用非本app的圖標。被拒。

最後只好把預覽砍了，就通過了，在後面版本升級的時候加上了，也就沒事了...

提交過一個app，說明信息的截圖裡有一張是幫助信息，裡面關於iOS還是iPhone的大小寫拼錯了，結果就被拒了。

p.s.之前提交到平面雜誌上的俺的一封論文，公司綜合部在審的時候，不讓我貼蘋果的icon，說蘋果這塊卡的特嚴，貼了要找我們麻煩。。

IOS9發布幾天後，提交App,然後順利被拒，理由是所用的字體在IOS9上變成亂碼。解決方式是：換字體適配IOS9，提交，成功！