原文出處:
前往 Medium.com 檢視
這篇副標題是-A tale of three months of Apple Review Rejections, 這位作者第一次將他開發的App上架到Apple Store歷經了三個月(開發3個月, 審核又花了三個月), 這中間被Apple拒絕了多次, 看完這篇文章後覺的很有趣, 摘錄一下這位作者分享他被Apple退件的經驗, 也許您以後也會遇到同樣的問題也許可以省下不少寶貴的時間.
簡單描述一下作者的App叫做Stream for Twitter , 只要輸入任何你有興趣的關鍵字, Stream就會跟隨並即時顯示最新的tweet.
第一次被Apple拒絕
作者認為他的App很功能很簡單, 但是還是被拒絕上架, 結果發現Apple的App審核團隊甚至也沒有測試他的App, 原來作者在App的描述放了競爭對手的關鍵字(作者用這關鍵字作範例), iOS vs Android
根據 App Store審核指導方針 3.1 指出
Apps or metadata that mentions the name of any other mobile platform will be rejected
在App中或是衍伸資訊(metadata)提及其它的移動平台App都會被拒絕.
作者承認這確實他自己的錯, 還好不用改寫程式碼, 只要修改App的描述就可以了.
第二次被Apple拒絕
這次App審核團隊引述了 App Store審核指導方針 14.3
14.3 Apps that display user generated content must include a method for filtering objectionable material, a mechanism for users to flag offensive content, and the ability to block abusive users from the service
如果App有顯示用戶產生的內容(Apple 這邊應該使指用戶產生內容並分享給其他用戶), 必須提供一種機制可以讓使用者可以過濾令人反感的題材, 一種機制給使用者檢舉淫穢的內容並且從服務端有能力去阻擋粗魯的用戶.
作者覺得有點莫名其妙, 事實上他的App並沒有讓使用者去產生任何內容, 他的App內容都是從Twitter來的. 作者寫了一封信去跟Apple解釋, Apple 回了作者一封信
While we undersand your app pulling content directly from Twitter, since this content is user generated, it would still be appropriate to implement a flagging mechanism in your app.
Therefore, your app will not be posted to the App Store at this time
這次作者學到一件事, 如果App有顯示內容給用戶, 就要實現舉發/監督/阻絕機制, 即使這些內容不是自己的App產生的.
還好Twitter API有提供這樣的機制, 是作者需要的
- A Report/Flag mechanism
- A Filter for sensible content
第三次被拒絕
在等待被Apple審核的時間, 作者持續增加新的功能, 他加入了in-App purchase的功能, 而這次被拒絕就是因為這個功能. 作者加入的in-App purchase是屬於 none-consumable, 也就是一次性消費, 購買後永久持有, 如果是訂閱服務就不是了. 通常none-consumable購買, 使用者可以重複下載, 例如重新安裝App. 這次作者被拒絕的理由就是他沒有提供讓使用者恢復購買(Restore)功能,程式如果偵測使用者已經購買過, 必須提供一個Restore button讓使用者可以恢復購買.
大概作者被Apple拒絕了很多次, 審核的人有點同情他於是建議作者提出Expedited Review Request 加快審核申請表單.
不過並不是提出快速審核申請, Apple就真的會優先處理, 作者說Apple還是寫一封信回他目前無法為他的App做快速審核.
第四次被拒絕
這次作者覺得他應該會很快通過審核, 但是他提出申請後, App審核團隊因為要測試他的App所以需要特別的Twitter授權, 經過作者解釋只要一般的Twitter帳號就可以了, 這次總算被接受了.
但是這次作者改變了心意想要改變App的名稱, 於是必須再提出申請.
第五次被拒絕
這次作者猜這次的審核工程師應該是新來的菜鳥, 他使用iPad做測試並告訴他無法使用Twitter認證螢幕, 這個認證螢幕在Stream第一次使用時會啟動.
這個問題並不是很清楚, 因為審核者給他的screenshot不是很確實的裁切, 和含糊的訊息. 經過幾次溝通, 作者並將他在iPad如何使用Stream的過程錄製下來寄給審核者看, 最後終於通過了, 這次作者學到的一課-不要以為每一個App審核團隊的人都知道他們自己在做什麼
結論
作者開發了這個App花了3個月的時間, 又經過3個月的時間和Apple的App審核團隊斡旋, 最後才真的讓App上架, 他真的學到不少, 他建議如果您也要開發App並準備上架到App Store, 他有幾個建議
- 先讀過 App Store 審核指引 , 其實這份指引不會很長, 不會花你太多時間, 這會省下不少被拒絕的時間.
- 每次上傳新的版本, 使用App審核資訊欄位告訴審核者讓他們知道這次的版本相較上次的版本變更/修正/更新了什麼.
- 如果在被拒絕後上傳新的版本使用Notes欄位指出你做了什麼改善用於克服上次被拒絕的原因.
- 要禮貌: 當審核者拒絕你的App, 要先謝謝他們並很禮貌的問他們更多的資訊, 或是讓他們知道你將要提出新的上架申請修正問題. 作者這樣做, 所以App審核者總是很熱意的幫助他遇到的問題.
- 要有耐心. 釋出一個App也許是個負擔, Apple 有非常高的標準這也是Apple Store跟他的競爭者不一樣的地方.
小編的心得:
小編寫的App不夠多,運氣真好提出後其實一個月內就可以通過審核, 過去在社團聽過很多開發者在傳要上架到Apple Store要經過非常漫長的審核, 看了這篇文章的經驗分享, 才知道原來真的有很多細節要注意. 如果您有耐心看到這裡, 祝您App每次釋出都會很快通關!