AppStore上架審核過程中常見問題整理
當前位置:點晴教程→知識管理交流
→『 技術文檔交流 』
一 、iOS APP 上架流程簡介 1. 申請開發(fā)者賬號 蘋果的開發(fā)者賬號主要分為個人(Individual)、公司(Company)、企業(yè)(Enterprise)、高校(University)四種類型。一般開發(fā)者申請的都是個人或者公司的,企業(yè)的開發(fā)者賬號開發(fā)應用不能發(fā)布到App Store,只能企業(yè)內部使用。這個申請過程一般可能需要一個星期左右。公司和企業(yè)的需要鄧白氏碼,如果鄧白氏碼未申請,請先申請鄧白氏碼,這個過程需要一到兩個星期。 這里插一句,如果有App代上架需求的,可以找我 2. 創(chuàng)建證書、AppID、生成描述文件 通過 Mac的鑰匙串工具,生成證書請求文件,下載證書,這里需要注意的是下載下來的證書只能在請求該證書的電腦上使用,如果想給其他開發(fā)者使用需要將已經(jīng)導入的證書導出為個人信息交換(.p12)格式供他人使用。AppID 的創(chuàng)建需要用到項目的Bundle ID,之后便可以創(chuàng)建描述文件了。 3. 在開發(fā)者中心的iTunes Connect 中配置 App 相關信息 在開發(fā)者中心里的iTunes Connect 里的 APP 選項中新建 APP 項目并配置相應的信息(需要各個版本的屏幕截圖,運行模擬器,調到最大(command+1),用 command+s截圖,還有就是一個1024*1024的圖標,不能有圓角) 4. 使用 Xcode 打包上傳 App 將 2 步驟中申請好的證書和描述文件正確配置到 Xcode 中,設置好Xcode的一些屬性: 1.在Xcode中選擇iOS Device(這里不能選擇模擬器); 2.如果應用不支持橫屏,請在 General 選項中將 Landscape Left 和 Landscape Right 兩項的勾選去掉; 3.查看版本號和構建版本號; 4.將斷點、全局斷點、僵尸模式等都去掉; 5.設置為 Release 模式。 之后便可選擇 Xcode->Product->Archive打包項目,打包完成后選擇 Upload to App Store上傳。如果不想使用 Xcode上傳的話,也可以選擇 Export導出ipa文件, 需要注意的是在導出時,必須選擇 Save for iOS App Store Deployment。然后通過Application Loader 工具上傳 ipa 文件。 5. 提交審核 以上步驟完成后,返回 iTunes Connect 上查看自己的 App 信息,在構建版本中選擇剛剛上傳的 App 版本,此時有可能顯示正在處理,這時可能需要等幾分鐘再回來查看。選擇好版本后點擊提交以供審核,這時 App 會變成等待審核狀態(tài)。 6. 后續(xù) 后續(xù)就是等待蘋果的審核人員審核應用了,如果一切順利的話,這個過程需要一到兩個工作日便可完成審核,當然前提是你的應用符合蘋果的審核條款。如果審核不通過,請及時根據(jù)反饋信息修改應用,再次提交直到符合要求。審核通過后,如果之前選擇已經(jīng)選擇好自動發(fā)布,便可在 AppStore 上查看和下載應用了。 二 、iOS 上架審核過程常見的坑與解決方法 1. 問題:用戶生成內容(UGC)缺少必要的審核 為了防止非法濫用用戶生成的內容,從而給用戶提供虛假信息、盜取用戶的知識產(chǎn)權,社交應用以及應用當中包含用戶生成的信息的應用必須包括下述功能: 1.過濾不良內容 2.提供舉報機制 3.后臺服務可以提供阻止騷擾用戶的行為 4.提供官方聯(lián)系方式,讓用戶可以快速聯(lián)系到開發(fā)商 解決方案: 維秀直播 App 提供了用戶實時彈幕功能,所以涉及到了 UGC,他們的處理方法是增加關鍵詞過濾,還有通過房管的方式人工審核,處理違規(guī)用戶。 2. 問題:應用中使用了 IDFA 被拒絕 IDFA 主要被用于廣告中區(qū)分設備的作用。AppStore 禁止沒有使用廣告而采集 IDFA 的 App 上架,所以如果 App 本身沒有廣告的話,使用第三方 SDK 要注意檢查是否含有 IDFA 廣告模塊。 解決方案: 如果應用本身有集成廣告的話,只需要在提交審核的時候勾選正確的廣告標識符選項即可。 如果應用本身未集成廣告,卻包含 IDFA的話。這種情況一般都是集成的第三方 SDK中包含IDFA 導致的。首先尋找是否有不包含 IDFA 的SDK 版本,如果沒有的話可以參考 ShareSDK 的解決方法,通過后臺配置在審核期間為應用添加廣告,審核完成過后將廣告展示去掉。 3. 問題:應用不支持 IPv6網(wǎng)絡下使用 2016年6月1號起,蘋果的審核人員會在 IPv6 網(wǎng)絡上審核你的應用,所以如果你的應用程序無法使用 IPv6 協(xié)議,可能會被拒絕。 解決方案: 我上架的卓易奪寶和小帶魚手機現(xiàn)金貸款軟件 App 上架過程中就因為 IPv6 的支持原因被拒。我的解決方案是: 協(xié)調后端人員添加對 IPv6 網(wǎng)絡的支持。 App 端更新相關的第三方 SDK,比如使用ASI 或者 AFN 的版本太低,使用最新的AFN即可解決問題。當然這些做完之后最好在Mac 上面搭建 IPv6網(wǎng)絡供測試人員進行完測試再重新發(fā)布。 4. 問題:第三方登錄、支付、分享未安裝應用,提示下載被拒 這個問題其實被拒的原因有兩種,第一種是未安裝應用沒有任何提示,這種情況下相當于應用有無效的按鈕所以會被拒;第二種是提示下載對應的第三方 App,這也是蘋果所不允許的。 解決方案: 最新的第三方登錄等相關的 SDK 目前已知的(微信,QQ,微博)都已經(jīng)對這種情況做了處理,在未安裝的情況下會調用 web 進行登錄,所以如果測試過程中發(fā)現(xiàn)可以成功在 web 上登錄的話可以不做處理。以前在沒有這種處理機制的情況下需要開發(fā)者調用對應接口,先判斷是否安裝了相應的第三方 APP,如果未安裝,需要隱藏按鈕,這樣便可輕松過審。 5. 問題:虛擬產(chǎn)品未使用應用內支付(IAP)被拒 根據(jù)蘋果官方最新的審核條款:如果你希望通過付費才可以解鎖你的應用當中的一些功能(例如,訂閱內容,游戲貨幣,游戲關卡,獲取優(yōu)質內容,解鎖完整版本),你必須使用應用內付費(IAP)。如果這種情況下,應用使用了其他的第三方支付,應用將被拒絕上架。 解決方案: 審核的時候,把相應的虛擬產(chǎn)品隱藏起來,通過后再放出來,此招有風險,可能會受到警告信,甚至被封號,如果用戶量小就無所謂了,先把App 搞上架! 審核的時候,走 IAP 的支付方式,審核完成后再通過服務器配置動態(tài)切換到支付寶、微信等第三方支付。該法類似于方案1,也存在風險。 學習58同城,讓用戶去網(wǎng)站購買產(chǎn)品,買了產(chǎn)品的賬號到移動端使用功能。 老老實實的使用 IAP 吧。 6. 問題:使用后臺定位被拒 關于位置服務蘋果的審核條款原文如下: 使用位置服務的應用程序必須提供和位置服務直接相關的功能。使用基于位置的API不允許用于提供緊急服務,或者實現(xiàn)自動控制車輛、飛行器以及其他設備(小型的設備例如小型無人機和玩具例外),遠程控制汽車警報系統(tǒng)等。在收集、傳輸和使用用戶的位置數(shù)據(jù)之前,請確保你已經(jīng)取得了用戶的同意。如果應用程序使用了后臺定位服務,務必在應用當中闡明其目的。并且使用后臺定位的話需要提供一個明確的提醒告訴用戶這么做會加快電量消耗。 一般應用在這一塊被拒的原因有以下幾種: 1.應用根本不需要定位功能。 2.應用需要定位功能,但是只需要短暫的獲取少數(shù)的用戶的位置,比如美團,新聞類的應用需要獲得當前用戶的所在城市,卻使用了后臺定位模式。 3.應用確實需要使用后臺定位,比如打車類軟件,但是應用中卻沒有任何界面展示這些定位數(shù)據(jù)。 解決方案: 4.如果你的應用根本不需要定位功能,但是還是在info.plist里面添加了location in theUIBackgroundModes key ,那么在plist文件里面移除UIBackgroundModes key就可以,這中情況較少,新手小白會犯這種錯誤。 5.如果只是簡單獲取位置不需要使用后臺定位,只需要去掉info.plist 的文件中的 UIBackgroundModes 即可。 6.這種情況比較復雜,推薦的做法是通過表格或者軌跡展示出后臺定位的數(shù)據(jù),再提交審核的時候告訴蘋果那個功能需要后臺定位,具體展示后臺定位的數(shù)據(jù)在那個界面,最后需要 Continued use of GPS running in the background can dramatically decrease battery life加到 App 描述里面,可以參考滴滴出行的描述,否則也會被拒絕。 7. 問題:info.plist 權限配置被拒 iOS 10 之后如果需要調用相機,藍牙等設備時,需要在 info.plist 文件中進行相應的配置,否則應用會直接崩潰,在 iOS 10 之前則是無法訪問。另外,如果在 info.plist 中調用了配置了權限在應用中卻沒有使用到也是會被拒的。 解決方案: 一定要注意自己的 App 在使用中用到了哪些權限,不要添加無用的權限,也不要缺少必要的權限。 8. 問題:應用提示更新被拒 應用內不能有任何提示更新應用的字樣,且應用的更新只能通過 AppStore。因為蘋果對于應用的更新有自己的一套策略,所以禁止應用本身提供更新方式,只要應用內出現(xiàn)。 解決方案: 如果不是很必要的話,盡量將應用內涉及到應用更新的部分去掉。如果真的需要使用應用更新,推薦的方法是應用啟動的時候獲取下應用在 AppStore上面的版本號,與自己的版本號進行比較,當自己的版本號小于 AppStore 上面的版本號時,提示更新,否則的話不顯示更新相關的內容。 9. 問題:奪寶(抽獎)類應用被拒 根據(jù)AppStore 審核準則 20.4 的規(guī)定,抽獎卷或抽獎參與權的購買,不論是透過第三方支付渠道或者余額扣款實現(xiàn),都不能夠在 app 內執(zhí)行。 解決方案: 卓易奪寶 App 上架過程中遇到的問題,最后的解決方法是在審核過程中,所有的支付行為都跳轉到 Safari瀏覽器上面進行,審核完成后再使用支付寶等 app 平臺支付。 10. 問題:隱私條款問題被拒 在未獲得用戶事先允許,或未告知用戶信息將被如何,在哪里使用的情況下,應用不可以傳輸用戶數(shù)據(jù)。 解決方案: 《網(wǎng)站服務協(xié)議》《隱私條款》這些都不要少,注冊時候讓用戶可勾選。另外注明需要的用戶信息用來做什么。 11. 問題:未提供測試賬號被拒 如果應用中有需要用到賬號或者其他資源的(例如:一個二維碼)才能使用的一些功能,但未提供給蘋果,可能會被拒絕上架。原因是蘋果審核人員無法測試這些功能。 解決方案: 提供一個有效的測試帳號以及登錄信息,并提供測試功能必要的的硬件和資源(例如,一個測試用的二維碼) 12. 問題:未通過 HTTPS 訪問被拒 App Transport Security(ATS) 是 Apple 為增強 iOS App 網(wǎng)絡通信安全提出的安全功能,適用于iOS App 和 App Extension;在啟用 ATS 之后,它會強制應用通過HTTPS(而不是 HTTP )連接網(wǎng)絡服務。 WWDC 2016上提出,2016年底或2017年初,具體時間未定。App Store上架審核加強對ATS 配置的review,即強制應用必須通過HTTPS連接網(wǎng)絡服務,而不是隨手將NSAllowsArbitraryLoads置為 YES,否則審核不予通過。 解決方案: ATS 的提出,是為了在系統(tǒng)層面保障iOS APP 網(wǎng)絡通信的安全;Apple 只所以加強對ATS 配置的審核,是為了防止開發(fā)者們遇到ATS相關的場景時,只是簡單地將 ATS完全關閉(只要沒有強制性措施,開發(fā)者會這么做);在此基礎上,App審核同樣會遵循原則:App Review will require "reasonable justification" for most ATS exceptions。 Apple 官方給出的可以通過審核的聲明 demo 如下: 1.必須使用第三方提供的服務,但是其沒有支持 HTTPS; 2.必須通過域名連接到設備,但該設備不能支持安全連接; 3.必須展示不同來源的網(wǎng)頁內容,但是不能基于 NSAllowsArbitraryLoadsInWebContent支持的類(UIWebView / WKWebView)實現(xiàn); 4.載入加密的媒體資源并且其中不涉及個人信息。 由于 Apple 官方并沒有給出 ATS 審核的完整說明,ATS 審核時什么才是合適合理的聲明也沒有明確的客觀定義,以上 demo 描述僅能作為參照。 查看原文 該文章在 2023/10/25 14:36:47 編輯過 |
關鍵字查詢
相關文章
正在查詢... |