iOS APP 上架審核被拒問題匯總(持續(xù)更新)

前言

眾所周知积糯,App 在上架至 App Store 前跌帐,必須通過蘋果神秘的審核團隊的審核。能否在短時間內(nèi)順利通過審核翎冲,對 App 推廣節(jié)奏和策略单刁、以及迭代等影響是非常大的!

1.提交審核的流程

目前應(yīng)用提審的整個流程大體分為五個階段府适,這個登錄過 App Store Connect 后臺或操作過 App 上架的小伙伴應(yīng)該都知道:Prepare For Upload(準備上傳)羔飞、Waiting For Review(等待審核)、 In Review(審核)檐春、Pending Developer Release(等待開發(fā)者發(fā)布)逻淌、Ready For Sale(準備銷售)。

其中 Waiting For Review(等待審核)和 In Review(審核)這兩個階段是不受開發(fā)者控制的疟暖,也就是說卡儒,這兩個階段由審核人員操控田柔。

2.機審和人工審核

蘋果審核大體分為三部分,預(yù)審骨望、機審和人工審核硬爆。包上傳后首先進入的是預(yù)審,會被掃描 API 等擎鸠,沒問題的話才會在 App Store Connect 里出現(xiàn) 然后才可以提交至 Waiting缀磕。

在審核前期,也就是 Waiting For Review(等待審核)階段一般是機審劣光,去年鬧得沸沸揚揚的 4.3 就是通過機器掃描掃代碼袜蚕;

機審不通過則直接被拒,通過后會進入人工審核绢涡,即 In Review(審核)階段牲剃,這個階段主要看的是 App 的元數(shù)據(jù),例如標題雄可、描述凿傅、截圖等,以及檢測 App 的功能使用情況数苫,常遇到的 IPV6 也在此處檢測聪舒。

判斷是進入了機審狀況還是人工審核狀態(tài),除了看時間外文判,還有一個方式,就是去看后臺室梅,如果有美國 IP 登錄戏仓,應(yīng)該就是人審了;如果只有 App 啟動但沒有深度訪問亡鼠,說明在機審呢赏殃,正在掃代碼。

當(dāng)然间涵,利用上述兩種方式也可以來判斷 App 是機審被拒仁热,還是人工審核被拒,然后確定解決側(cè)重點勾哩。

目前機審機制越來越完善了抗蠢,而且也越來越受重視,這個從 2.1 和 4.3 出現(xiàn)的頻率就可以看出來思劳!其實蘋果重視機審也是可以理解迅矛,減少人工成本并增加審核嚴格度,也更傾向于人工智能這個大方向潜叛!不過如果機審機制太完美秽褒,對我們可能不是好事壶硅,過審也許會越來越不容易。

3.審核時間逐漸縮短销斟,但延期審核現(xiàn)象增多

雖然大家一直在吐槽蘋果的審核時間庐椒,但相比于之前,例如 7~8 天階段蚂踊、3~4 天階段约谈,現(xiàn)在已經(jīng)很不錯了。而且通過近三個月的審核數(shù)據(jù)對比悴势,App審核的周期又有了進一步縮短的趨勢窗宇。

蘋果曾在 2017 年 6 月 WWDC 大會上表示,接下來會進一步縮短審核時間特纤。從目前趨勢來看军俊,確實是在進一步縮短。不過現(xiàn)在又出現(xiàn)了一個現(xiàn)象或者說處罰方式——延期審核捧存。

延期審核一般針對的是大量同種類的 App粪躬,比如游戲(斗地主等),還有涉及敏感題材的 App昔穴,比如金融镰官、彩票、VPN 等吗货。特別是對于游戲泳唠,蘋果已經(jīng)摸清了此類 App 開發(fā)者的套路(馬甲包、隱藏支付等)宙搬,但由于一些開發(fā)者隱藏工作做得好笨腥,蘋果又無法拿到確鑿證據(jù),所以只能故意拖延勇垛。如果被延期輕則需要十幾天脖母,重則拖延 1 個月甚至幾個月。

有小伙伴可能想了解延期審核后怎么辦闲孤?在此說幾點谆级,如果沒有明顯違規(guī),除了打電話讼积,在 App Store Connect 后臺點【聯(lián)系我們】這些方式外肥照,還有一些稍微冒險的方式,申訴或加速審核勤众。如果這兩個方式還不行建峭,又不想等,果斷換賬號重新提包吧决摧!還有個方法是將免費 App 設(shè)置為付費亿蒸,但也只是可以縮短等待時間凑兰,審核的時間也可能會很久,這個不是很好管控边锁。

4.蘋果審核側(cè)重點不斷調(diào)整姑食,且新的被拒理由層出不窮

蘋果審核側(cè)重點不斷調(diào)整,且新的被拒理由層出不窮茅坛。當(dāng)然這里所說的“新的被拒理由”有些是一直存在的音半,只是沒有側(cè)重這方面審核或者說審核沒有升級到這一步而已。

5.問題匯總

今日有空贡蓖,把以往所遇到的問題匯總一下:

Guideline 1.2 - Safety - User Generated Content

Your app enables the display of user-generated content but still does not have the proper precautions in place.

Next Steps

To resolve this issue, please revise your app to implement all of the following precautions:

  • Require that users agree to terms (EULA) and these terms must make it clear that there is no tolerance for objectionable content or abusive users
  • A method for filtering objectionable content
  • A mechanism for users to flag objectionable content
  • A mechanism for users to block abusive users
  • The developer must act on objectionable content reports within 24 hours by removing the content and ejecting the user who provided the offending content

這里談到了關(guān)于用戶發(fā)布內(nèi)容(類似朋友圈曹鸠、 QQ空間、微博)斥铺,需要涉及到的安全機制彻桃,包括:

  • 要求用戶同意條款(EULA),并且這些條款必須明確表示晾蜘,不允許有令人反感的內(nèi)容或濫用的用戶邻眷。
  • 一種過濾有害內(nèi)容的方法
  • 一種用戶標記不良內(nèi)容的機制
  • 用戶阻止濫用用戶的機制
  • 開發(fā)人員必須在24小時內(nèi)通過刪除內(nèi)容并彈出提供有問題內(nèi)容的用戶來處理令人不快的內(nèi)容報告。

根據(jù)這些反饋剔交,以及網(wǎng)絡(luò)收集到的信息肆饶,為了防止非法濫用用戶生成的內(nèi)容,從而給用戶提供虛假信息岖常、盜取用戶的知識產(chǎn)權(quán)驯镊,社交應(yīng)用以及應(yīng)用當(dāng)中包含用戶生成的信息的應(yīng)用必須包括下述功能:

  1. 用戶使用協(xié)議。
    對敏感信息進行說明竭鞍,在登錄頁面加用戶使用協(xié)議板惑,部分 APP 在發(fā)布頁面,有的 APP笼蛛,在制作頁面也會有洒放;
  2. 過濾不良內(nèi)容(色情蛉鹿、裸露滨砍、褻瀆等內(nèi)容)
    后臺對用戶發(fā)布的內(nèi)容進行審核、過濾妖异;
  3. 提供舉報機制
    對用戶發(fā)布的內(nèi)容進行舉報惋戏,讓后臺處理。
  4. 屏蔽/拉黑他膳。
    之前網(wǎng)上有文章講响逢,說要這個功能,有的沒有提到這個棕孙。因為這個需要加新接口舔亭,并且大部分的查詢接口都需要做對應(yīng)的判斷些膨,所以一直希望這個不是必要的,只是在改其他的接口钦铺。
  5. 聯(lián)系方式订雾。
    提供官方聯(lián)系方式,讓用戶可以快速聯(lián)系到開發(fā)商

另外矛洞,被拒后不要去猜測被拒原因洼哎,而是最快的方式就是上訴然后他們會打電話過來詳細說明原因,這樣能夠盡快的解決問題沼本。

Guideline 2.1 - Performance - App Completeness

Your app crashed on iPhone running iOS 13.2 on WiFi when we:

  • Tapped on the recharge button.

We have attached detailed crash logs to help troubleshoot this issue.

Next Steps

To resolve this issue, please revise your app and test it on a device to ensure that it runs as expected.

Resources

For information on how to symbolicate and read a crash log, please review Tech Note TN2151 Understanding and Analyzing Application Crash Reports.

Please see attached screenshot for details.

蘋果支付噩峦,充值按鈕事件崩潰。

一開始一直沒搞明白 "recharge button" 什么意思抽兆,充電按鈕识补?后來才知道是“充值按鈕”李请,英語很重要导盅。在 iOS 13 下點擊【充值】按鈕崩潰了揍瑟,iOS 12 之前都正常提示,排查原因滤馍,是蘋果《付費應(yīng)用程序協(xié)議》到期底循,需要續(xù)簽。App Store Connect 提示如下:

協(xié)議阁苞,稅務(wù)和銀行業(yè)務(wù).png
《付費應(yīng)用程序協(xié)議》.png

點擊【續(xù)簽】即可

更新《付費應(yīng)用程序協(xié)議》.png

注意:以后要及時更新蘋果協(xié)議!等舔!

Guideline 2.3 - Performance - Accurate Metadata
【2.3 系列 - 準確的元數(shù)據(jù)】

客戶應(yīng)該知道他們在下載或購買您的 App 時會得到什么,所以請確保 App 的描述甚牲、屏幕快照和預(yù)覽能夠準確反映 App 的核心體驗,并記得不斷更新丈钙,以便保持與新版本相應(yīng)的最新狀態(tài)著恩。

被拒原因:

  • 應(yīng)用中包含隱藏功能,試圖隱藏應(yīng)用程序中的功能邀摆,功能或內(nèi)容被認為是令人震驚的行為伍茄;
  • 上架時的 App 預(yù)覽和截屏沒有適配 6.5 英寸 和 5.5 英寸。
  • 應(yīng)用截圖等級不符例获,圖片過于暴露榨汤、血腥等……
  • 應(yīng)用標題怎茫、描述、截圖等與應(yīng)用功能嚴重不符蜜宪。如果是使用了安卓手機的截圖或瀏覽器也會引起拒審圃验;

解決方法:

  • 修改或刪除應(yīng)用中隱藏的功能(去除隱藏功能模塊代碼或?qū)⑿枰[藏功能的代碼及定向跳轉(zhuǎn)鏈接網(wǎng)址做混淆處理缝呕,適當(dāng)增加邏輯復(fù)雜度);
  • 重新更換 App 預(yù)覽和截屏照捡,適配 6.5 英寸 和 5.5 英寸话侧;
  • 調(diào)整應(yīng)用截圖內(nèi)容瞻鹏,或者修正應(yīng)用的上架年齡等級
  • 應(yīng)用標題、功能描述等要與 App 預(yù)覽和截屏相符合薪夕,保證整個 App 功能赫悄、流程看起來是一致的;

提交審核:您的 App 正在使用廣告標識符 (IDFA)姑隅。您必須先提供關(guān)于 IDFA 的使用信息或?qū)⑵鋸?App 中移除倔撞,然后再上傳您的二進制文件痪蝇。

IDFA(identifier for advertising) 主要被用于廣告中區(qū)分設(shè)備的作用。從 2014 年 2 月初開始趁矾,App Store 禁止沒有使用廣告而采集 IDFA 的 App 上架给僵,所以如果 App 本身沒有廣告的話,使用第三方 SDK 要注意檢查是否含有 IDFA 廣告模塊培漏。

解決方案:

  • 如果應(yīng)用本身有集成廣告的話胡本,只需要在提交審核的時候勾選正確的廣告標識符選項即可。
  • 如果應(yīng)用本身未集成廣告珊佣,卻包含 IDFA 的話咒锻。這種情況一般都是集成的第三方 SDK 中包含 IDFA 導(dǎo)致的守屉。

如何查看自己的項目是否采集了 IDFA 呢?

很簡單思灌,打開終端泰偿,cd 到工程目錄,執(zhí)行如下命令(注意:后面包含個點)看下運行結(jié)果

grep -r advertisingIdentifier . 

看下運行結(jié)果

Binary file ./Pods/MOBFoundation_IDFA/MOBFoundation.framework/MOBFoundation matches
Binary file ./Pods/ShareSDK3/ShareSDK/Support/PlatformSDK/SinaWeiboSDK/libWeiboSDK.a matches

看最后一個單詞耗跛,matches(匹配)到了课兄。 罪魁禍首原來是 SinaWeiboSDK/libWeiboSDK.a

具體原因:iOS 9 之后新浪微博分享可使用的前提是加入 ADSupport.framework烟阐,打包提交后一直報您的 App 正在使用廣告標識符 (IDFA)蜒茄。

找到原因就好解決了餐屎。

具體解決方法呢腹缩?
很簡單藏鹊,承認使用 IDFA,然后勾選相應(yīng)的選項楚殿。 如圖所示:

廣告標識符 (IDFA).png

當(dāng)然竿痰,你也可以根據(jù)命令行做出調(diào)整影涉。例如蟹倾,上方命令行顯示SinaWeiboSDK/libWeiboSDK.a抖坪,你可以將其移除滑黔,移除完后也是可以分享成功的岔留。(此時你可重新執(zhí)行命令行献联,看是否還存在 IDFA,如果沒 match 到了进胯,直接提交即可胁镐。)
另一種途徑: 下載官方最新x-code诸衔,重新打包提交審核笨农。(沒試過谒亦,據(jù)說有人成功過)份招。

總結(jié)一下 ShareSDK 的解決方法:

1锁摔、 如果你的應(yīng)用里只是集成了廣告鄙漏,不追蹤廣告帶來的激活行為怔蚌,那么選擇 1 和 4巩步;
2、如果您的應(yīng)用沒有廣告桦踊,而又獲取了 IDFA椅野。我們建議開發(fā)者朋友選擇 2 和 4。這種做法蘋果官方?jīng)]有明確說明,但目前為止還沒有收到開發(fā)者選擇 2 和 4 被拒的反饋竟闪。

歡迎大家批評指正离福!O(∩_∩)O~

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市炼蛤,隨后出現(xiàn)的幾起案子妖爷,更是在濱河造成了極大的恐慌,老刑警劉巖理朋,帶你破解...
    沈念sama閱讀 216,544評論 6 501
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件絮识,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機国拇,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,430評論 3 392
  • 文/潘曉璐 我一進店門土思,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人冲甘,你說我怎么就攤上這事√找梗” “怎么了黔夭?”我有些...
    開封第一講書人閱讀 162,764評論 0 353
  • 文/不壞的土叔 我叫張陵婚惫,是天一觀的道長鹰祸。 經(jīng)常有香客問我粗井,道長餐济,這世上最難降的妖魔是什么醉冤? 我笑而不...
    開封第一講書人閱讀 58,193評論 1 292
  • 正文 為了忘掉前任螺捐,我火速辦了婚禮定血,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘铝条。我一直安慰自己,他們只是感情好,可當(dāng)我...
    茶點故事閱讀 67,216評論 6 388
  • 文/花漫 我一把揭開白布绰上。 她就那樣靜靜地躺著鉴腻,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 51,182評論 1 299
  • 那天,我揣著相機與錄音,去河邊找鬼玻孟。 笑死,一個胖子當(dāng)著我的面吹牛匣掸,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播铛嘱,決...
    沈念sama閱讀 40,063評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼帖烘,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 38,917評論 0 274
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎竣况,沒想到半個月后克婶,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 45,329評論 1 310
  • 正文 獨居荒郊野嶺守林人離奇死亡丹泉,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,543評論 2 332
  • 正文 我和宋清朗相戀三年情萤,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 39,722評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡肪获,死狀恐怖寒锚,靈堂內(nèi)的尸體忽然破棺而出雌桑,到底是詐尸還是另有隱情邪驮,我是刑警寧澤型酥,帶...
    沈念sama閱讀 35,425評論 5 343
  • 正文 年R本政府宣布,位于F島的核電站弛饭,受9級特大地震影響冕末,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜侣颂,卻給世界環(huán)境...
    茶點故事閱讀 41,019評論 3 326
  • 文/蒙蒙 一档桃、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧憔晒,春花似錦藻肄、人聲如沸蔑舞。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,671評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽攻询。三九已至,卻和暖如春州弟,著一層夾襖步出監(jiān)牢的瞬間钧栖,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 32,825評論 1 269
  • 我被黑心中介騙來泰國打工婆翔, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留拯杠,地道東北人。 一個月前我還...
    沈念sama閱讀 47,729評論 2 368
  • 正文 我出身青樓啃奴,卻偏偏與公主長得像潭陪,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子最蕾,可洞房花燭夜當(dāng)晚...
    茶點故事閱讀 44,614評論 2 353

推薦閱讀更多精彩內(nèi)容