2019年iOS Appstore 審核全梳理-2.1、4.3、3.2.1

在過去一年中相信各位開發者都經歷了蘋果的“摧殘”,目前蘋果熟知國內馬甲包的套路,導致在這一年中蘋果對馬甲包的打擊力度呈現幾何式增長,開發者在上架的過程中普遍遇到的問題主要有:

希望有更多的朋友一起針對蘋果ios審核上架處理分享,qq群:? 611641785,歡迎一起交流? ,后期會慢慢分享更多的干貨?

1.打擊力度大


蘋果對馬甲包打擊力度增加,導致現在遇到的主要問題是:


■上架難,4.3已經成為頭號殺手

■復審嚴,下架頻,下架應用比上架還多



2.各環節過審技巧


注:蘋果主要的審核流程


?2.1 開發者環節

主要為蘋果的后續審核做好規避,主要分為兩點


2.1.1:代碼的修改,主要是為了方便做馬甲包修改

2.1.2:運營上的細節處理,主要是為了規避4.3處理方式可分為3點:

(i) ip切換

保證ip不重復,在沒有vpn的情況下,用手機熱點飛行模式五分鐘即可.

(ii) 保證設備更換

若無法更換設備,那么證書參數要處理到位,基礎證書每次都要清空處理(注回復公眾號后臺“證書”即可獲得哦)

(iv) 元數據填寫

切勿復制應用介紹和測試賬號,不得重復/


2.2? 代碼審查環節(機審):就是等待審核環節

主要審核內容:對“文件名,類名,函數名,方法名”等進行比對;而不是對全局每一個二進制文件的代碼進行比對。小貼士:如果應用首次提交,在這個環節的時間如果超過72小時,建議撤回哦,否則有封號風險。


2.3? 人機AI交互環節:

這個環節是ai機器人配合人工體驗應用的環節。(正在審核環節)——時間大概在幾十分鐘到幾個小時之間,若超過72小時建議放棄,否則依然有封號風險。



2.3.1 蘋果審核主要分為:

(i)?代碼問題——機審。

(ii)?內容違規問題——需審核人員來做判斷。

(iii)?出現人機交互審查的原因:機器記憶力和工作效率是人不可比擬的,但是人的主觀判斷意識又是機器沒有的。

(iv)?人審4.3是不可能的,4.3條款是指重復應用,而不是相似應用,嚴謹高效的蘋果審核環節,一旦給到你4.3,那一定是他有了十足的把握才被4.3打回,這是單靠人審做不到的絕對。2.3.2這個環節死的最多的不是應用類,而是游戲類——游戲類素材太多,替換成本太高。

出現人機交互審查的原因:機器記憶力和工作效率是人不可比擬的,但是人的主觀判斷意識又是機器沒有的。


3.被拒環節的解決方式

被拒環節:這個環節我們已經得到了蘋果審核反饋,如果是過審,那是皆大歡喜。但是一把過的概率極低,在被蘋果拒審后我們要根據駁回原因做必要的修改,這個是大家遇到的常態。如果被拒時收到蘋果的截圖,我告訴你也是一件好事,這種情況大概率這個應用是可以過審的,因為蘋果還是想告訴你如何修改,其實是在幫助你過審。以下我提出幾個觀點:



3.1 觀點一:兩次裝機審核

(i)?第一次代碼審查裝機截圖——首屏圖,每次必改。

(ii)?第二次人工體驗+ai同步定時多次截圖——做審核服,且每次隨機呈現。


小建議:大家在應用上一定要做好監測工作,這樣才能更好的掌握蘋果的審查動向,記住二次激活,不一定代表一定過了機審。極少情況會出現只有一次裝機就被拒的,這種情況就是開發者代碼上處理的重大失誤了。



注:兩次裝機反饋圖



3.2 觀點二:被拒后,不一定要重新提審


(i) 元數據拒絕

例如2.3.7問題(截圖無法反應應用程序問題)——修改五圖,添加手機模型即可。

(ii) 二進制拒絕

例如2.1的ipv6問題,拍攝登陸視頻即可.拍攝視頻也有小技巧哦(可私信小七妹妹領取視頻)。

注:遇到被拒情況不要著急重新提審,仔細審視后再進行操作。能通過回復解決的盡量不要去提交審核,減少蘋果審查代碼的次數。


3.3 觀點三:2.1大禮包不一定是壞事

(i) 2.1大禮包的問題

表示代碼里存在一些共性的點,但蘋果又無法準確定位。所以被2.1打回。

(ii) 回復2.1問題

回復態度一定要端正,回復的要素要全面,可以把大禮包的所有問題都逐一解答,剩下的全靠命運的安排咯,大概30%的通過率。

(iii) 特殊條款

近期出現特殊條款——聲稱你涉嫌違規,要調查你的賬戶,基本與封號沒有區別。

注:可能跟貿易戰有關哦!

3.4 觀點四:只是4.3的前兆

(i)?2.3.1涉及代碼混淆,蘋果發現這個問題的同時又無法判定你是否為重復應用提交而給出一個警告。

(ii)?解決2.3.1問題——讓垃圾代碼不垃圾。


a.?蘋果主要是審核代碼中的某些字節。

b.?往代碼中注入一定比例的冗余代碼。

c.?垃圾代碼中包含“文件名,類名,函數名,方法名”等,起作用的是這些東西。


(iii)?加垃圾代碼失效的原因:上包太肆無忌憚被蘋果爸爸發現并優化了審核機制。

(iv)?蘋果不可能做全局對比,所以添加垃圾代碼時更要注意一些特殊類名的規律性存在,例如:.cpp.和.h文件.不騙過自己怎么騙過蘋果。



3.5 觀點五:3.2.1只是紙老虎

(i)?3.2.1主要出現在金融上,而且明確告知了業務模式是可接受,所以只要提交資料即可。

(ii)?千萬不要套殼,套殼有風險。

(iii)?提交資質有講究。

(iv)?蘋果到現在依舊是區分不開p2p和貸款。

(v)?理財萬能包的出現,同時更新有講究需謹慎。

(iv)?5月初蘋果金融類上架禁令開始,在線理財原生包變得更加重要,但屯包有風險。

(vi)?最壞的可能:蘋果永久禁止收錄,那后續只能選擇套殼,有殼也比沒包強。


3.6 觀點六:4.3只出現在機審,且并非不可戰勝

(i)?人審沒有4.3,只有4.1。所謂遇到人審4.3的其實都是在人機交互環節被機器截圖發現的,是因為審核服沒有做到位。在沒有截圖的情況下如何鑒別4.3:具體情況分析,但唯一不變的就是審查動向的監測。

以游戲為例避免4.3:

a.?做一個獨立的的提審服務器——小部分游戲地圖

b.?修改場景圖,人物圖,道具樣式等各種圖片元素

c.?每個元素放在幾十個文件中,隨機抓取排列組合應對 ? 蘋果審核

d.?弊端:工作量大,但磨刀不誤砍柴工,必須做


(ii)?蘋果目前,將來都不會去做全源碼對比,因為效率低下。

(iii)?蘋果允許第三方調用,且隨著應用增加,諸多功能代碼的相識度很高,蘋果不能只依靠部分代碼相似來下定論——4.3只出現在機審的原因。

(iv)?規避4.3除了之前提到的換設備,切ip,導證書等運營細節以外,代碼規范很重要。——添加垃圾代碼的同時也要更改原本代碼的“文件名,類名,函數名,方法名”等。

小建議:蘋果一定是記錄存儲每次提審的代碼,那存儲的時間是多久呢,我認為是90填,大家可以去看蘋果后臺的tf測試項目,版本的有效期是90天,所以建議開發者們在提審出結果后,不要怕麻煩,一定把版本設置過期。

(v)?開發者需要改變角度將代碼修改流程化,同時運用各種語言工具,讓4.3成為過去/


3.7 觀點七:最可怕的霸王條款——other

這個時候就體現了蘋果的霸權主義了,基本就是封你賬戶了,你基本沒有反抗的機會,除非你有bat級別的公關團隊。

偶然遇到賬號無故封禁情況,大家主觀想法是信用卡賬號支付問題,其實不然,蘋果的信用卡信息保管很嚴謹.


總結


讓應用變成一個新的應用的方式有很多,本期教大家的是蘋果審核的原理,關于如何實現快速讓一個應用變成一個爹媽都不認識的新應用,這是核心機密,就不做展開了,如果是技術可以往我說的方向去試試,相信會有收獲。


希望有更多的朋友一起針對蘋果ios審核上架處理分享,qq群:? 611641785,歡迎一起交流? ,后期會慢慢分享更多的干貨?

?著作權歸作者所有,轉載或內容合作請聯系作者
平臺聲明:文章內容(如有圖片或視頻亦包括在內)由作者上傳并發布,文章內容僅代表作者本人觀點,簡書系信息發布平臺,僅提供信息存儲服務。
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 228,333評論 6 531
  • 序言:濱河連續發生了三起死亡事件,死亡現場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發現死者居然都...
    沈念sama閱讀 98,491評論 3 416
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 176,263評論 0 374
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,946評論 1 309
  • 正文 為了忘掉前任,我火速辦了婚禮,結果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,708評論 6 410
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發上,一...
    開封第一講書人閱讀 55,186評論 1 324
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 43,255評論 3 441
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側響起,我...
    開封第一講書人閱讀 42,409評論 0 288
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當地人在樹林里發現了一具尸體,經...
    沈念sama閱讀 48,939評論 1 335
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內容為張勛視角 年9月15日...
    茶點故事閱讀 40,774評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發現自己被綠了。 大學時的朋友給我發了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,976評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,518評論 5 359
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質發生泄漏。R本人自食惡果不足惜,卻給世界環境...
    茶點故事閱讀 44,209評論 3 347
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,641評論 0 26
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,872評論 1 286
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,650評論 3 391
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,958評論 2 373

推薦閱讀更多精彩內容