iOS加急審覈之2015年總結

　　就在今天到公司的一會，查看了一下郵件，收到Apple的回覆，今年的第六次加急審覈經過了。

　　而後，想一想明天就是西方的聖誕節假期了，從22日到29日的這段時間，Apple會暫時關閉iTunesconnect，忽然以爲這一年過的挺快的，就以爲頗有必要將這一年的一些體會寫下來，算是不太正式的總結吧，也給同行業的開發者一些借鑑。

　　總結的主題，固然主要集中在iOS的app審覈方面。

　　首先，談談Apple的審覈機制。

　　衆所周知，Apple的審覈是一個漫長的過程，並且有着極爲嚴格的審覈機制。若是開發人員不仔細研究Apple的審覈機制的話，一旦被拒，那麼審覈的週期可能又會是正常的兩倍，甚至更多，我所知道的，有人花了兩個多月的時間才最終經過Apple的審覈。因此，爲了保證項目的正常發版，看看Apple的最新系統的人機交互指南是頗有必要的。只有熟知其中的審覈機制，纔能有計劃有重點的進行開發。不少人都在抱怨，iOS的app的審覈時間過長，並且太過於嚴格。相比於iOS，Android的審覈的速度可謂快的不是一星半點，Android通常來講，兩個小時就能夠經過審覈，一旦經過審覈，就只剩下推上各大應用市場的工做了。可是，我要說，正是iOS嚴格的審覈機制，才能保證iOS絕佳的用戶體驗和低級app的泛濫。這也是爲何iOS的市場比Android更能得到用戶好感的一個方面吧。

　　固然，用戶是不能直接體會到iOS審覈漫長嚴格的審覈機制的，更多的是開發者們的抱怨，更深層的，那就是公司的需求不斷的更新，這也是致使Apple的審覈機制飽受詬病的緣由之一。那麼，下面咱們來詳細剖析一下蘋果的審覈機制。

　　因爲Apple的審覈團隊和審覈標準的封閉性，這裏所說的是基於我我的開發中的經驗之談，跟實際狀況可能有所出入，只做爲借鑑。

　　審覈時長：Apple的正常審覈流程，從開發者提交應用到iTunesconnect上審覈開始，到最終的上線，正常的時間在7天左右，固然預留10天左右的時間最爲充分，

　　審覈時間段：有人說，Apple的審覈不會在週六週日進行，也有人持不一樣意見。但據我我的提交這麼屢次數的經驗，我只能說，我在週六週日都有經過Apple審覈的經歷。因此，個人經驗告訴我，正常7天的審覈時間包括工做日和週六週日。

　　審覈地點：對於這個問題，有人認爲Apple的審覈團隊在中國有審覈團隊，對於這個觀點，我我的不敢苟同。經過郵件和審覈的時間點進行分析，我更傾向於認爲，Apple的審覈團隊固然在總部，不會在其餘地區設置分支審覈機構。

　　審覈人員：對於app的審覈，我我的認爲是機器審覈和人工審覈相結合的方式。至於人員的組成，其中中國區的審覈，是有專門的懂中文的人員負責，其餘各個國家和地區的狀況應與此同。

　　下面，談談你們更感興趣的話題，加急審覈。

　　針對我我的的經歷，因爲今年伊始，就進入了一家電商公司，相比與以前的公司，所加的需求比較多，前先後後，今年的加急一會兒用到了六次。

　　Apple給開發者加急的選擇的初衷，是爲了解決app中有影響用戶體驗的bug出現，爲了儘快更好解決bug，提升用戶的體驗。正是因爲Apple的審覈嚴格，因此，加急更多的是一種附加選項，可是這樣的初衷卻在不少狀況下被開發者（雖然不少時候是無奈的）濫用。因此做爲Apple的忠實開發者，但願你們不要濫用這個方法，雖然不少的時候是受到公司的壓力。下面，我仍是簡單談談加急的內容。

　　加急的次數：正如上面個人經歷，通常來講，正常的次數，一年有限的3次以內，除特殊的狀況外，超過次數，Apple仍是會容忍部分必需要加急的請求經過，但願不要亂用，由於每一次加急Apple都有記錄，審覈人員是能看的到這些的，至於嚴重的後果，只有大家本身親身體會了。

　　加急的緣由：通常來講，是由於有重大的bug，例如閃退崩潰，其餘較小的緣由，通常在正常審覈中都能發現，若是正常的審覈被拒，Apple會給你回覆郵件，指出當前測到的問題，你改正後再次提交版本就能夠。可是通常指出的只是測到的bug，其餘的最好自查幾遍再提交。

　　加急過程當中被拒：若是你的app提交加急了，並且被Apple經過了，若是Apple在測的過程當中測到bug，那麼會把你的app打回來，讓你修改，一樣會指出你的bug問題，雖然加急過程當中測到bug被拒，可是當你從新提交修改後的構建版本時，依然是處於審覈團隊的加急隊列中，這個加急狀態會直到你的app加急經過。

　　加急的時機：跟加急的緣由差很少，通常是有重大bug，開發者會提交加急請求，可是在app的首發時，是不能加急的，由於你沒有用戶，那麼就不存在任何的用戶反饋問題和重大的bug問題，你就只能老老實實的走正常審覈流程。

　　說一下，我我的寫了這麼屢次的加急審覈文章的經驗。

　　提交加急審覈的地址，既能夠從iTunesconnect中進入，也能夠直接百度加急通道網址進入，具體網址是：https://developer.apple.com/appstore/contact/appreviewteam/index.html，加急通道跟應用提交是不衝突的兩個通道，你提交app審覈後，而後進入加急通道進行加急申請填寫。

　　加急的語言：根據我上面的審覈團隊成員分析，你就能夠知道，加急的語言能夠是純英文，也能夠是中文的，固然也能夠是英文一遍，而後附下中文翻譯。

　　加急申請內容的填寫：根據提示填寫對用的內容便可，固然你在描述你的app中存在的bug時，必定要把具體的操做重現同樣的陳述一下，步驟必定要清楚明白，不要有歧義，必定要寫好。還有，最重要的是要誠懇，確實有這樣bug的問題發生。若是加急請求被拒，那麼app自動進入正常的審覈流程。

　　加急的時間：三次加急之內，通常當天提交申請，次日就能經過，若是加急次數越多，之後的每一次加急經過時間，都會比較久，我曾經有三天才經過加急。

　　網上有淘寶店以及一些公司提供了加急審覈的收費服務，通常來講，費用都很高，可是若是是有信譽的提供者，是能夠作到加急的，我另一個部門的同事，他們聯繫過這樣的公司，首發一萬，更新六千，一般狀況下，三個小時就能夠上線。因此，付費加急的方法也是存在的。至因而經過什麼渠道，這個還不甚瞭解，但能夠推測，大概是使用了申請加入內測人員的相關方法。至於選擇什麼樣的加急服務商，你們本身有效甄別，避免上當。

　　明天就是iTunesconnect關閉的第一天，今天的總結算是對2015的一個總結，很感激Apple提供的一個加急通道，雖然正常的加急確實漫長，應該有所改進，可是有這樣的一個通道在，也是一種幸運，望你們在提交前多作計劃，多作內測，避免濫用加急審覈。在聖誕節來臨之際，祝Apple的審覈人員聖誕節快樂，雖然咱們不放假，可是祝願他們玩的開心，最後也祝各位聖誕節快樂，注意身體，修煉技術，且行且珍惜！