先回顧下,4.3問題被拒郵件是怎樣的
4. 3 Design: Spam
Guideline 4.3 - Design
This app duplicates the content and functionality of other apps submitted by you or another developer to the App Store, which is considered a form of spam.
Apps that simply duplicate content or functionality create clutter, diminish the overall experience for the end user, and reduce the ability of developers to market their apps.
The next submission of this app may require a longer review time, and this app will not be eligible for an expedited review until this issue is resolved.
Next Steps
- Review the Design section of the App Store Review Guidelines.
- Ensure your app is compliant with all sections of the App Store Review Guidelines and the Terms & Conditions of the Apple Developer Program.
- Once your app is fully compliant, resubmit your app for review.
Submitting apps designed to mislead or harm customers or evade the review process may result in the termination of your Apple Developer Program account. Review the Terms & Conditions of the Apple Developer Program to learn more about our policies regarding termination.
If you believe your app is compliant with the App Store Review Guidelines, you may submit an appeal. Alternatively, you may provide additional details about your app by replying directly to this message.
簡單解釋,就是被蘋果認為該App重復使用自身產品或者模仿其他開發者的應用的內容或功能提交到appstore市場審核,appstore市場不接受類似的產品,如果沒有合理的解釋,再送延遲審核,拖你一頭半個月,如發現目的為了逃避評審,直接封號。
對此,不僅考慮為什么會出現4.3問題,蘋果是怎樣判斷的。在解答這個問題,我們先說說目前市場上是怎樣處理4.3問題的,只有清楚別人的做法,才能逆推出一些玩法來。
從4.3問題出現到目前為止,處理4.3問題方法從時間上,從復雜程度上,經歷了如下的過程,當時最后的結果就是老子不玩了。
-
UI不變,代碼不變,新開發者賬戶送審
-
UI不變,代碼混淆,新開發者賬戶送審
-
UI套殼,代碼不變,新開發者賬戶送審,蘋果審核看到固定頁面
-
UI套殼、代碼混淆,新開發者賬戶送審,蘋果審核看到固定頁面
-
UI套殼、代碼混淆,全新類名、函數名,新開發者賬戶送審,蘋果審核看到固定頁面
-
UI全新、代碼重構,全新類名、函數名,新開發者賬戶送審,打包設備、全新IP送審,等同全新產品
注:代碼混淆就是加垃圾代碼,垃圾代碼調用一個獨立頁面,用戶端沒有入口
目前4.3問題最常用的處理方法是第4種。號稱市面上能處理4.3問題而使用加固軟件,底層處理方式可能就是加垃圾代碼。在18年直播行業,曾經一段時間使用網易加固工具來避免4.3問題。
縱觀蘋果4.3問題被拒郵件內容,總體的可以概括為以下三種4.3問題猜想,第三種更多是我個人猜想:
一、代碼層次的4.3問題
二、設計層次的4.3問題
三、設備、IP、開發者賬戶、聯系人、銀行卡綁定等信息關聯上的4.3問題
為什么會得出以上的猜想?眾所周知,蘋果審核會分兩個部分:機審與人審。機審與人審被拒的郵件內容會出現個別的差異化。
一般而言,代碼層次的4.3問題,被拒的郵件回復是沒有任何截圖,其次我們通過后台查詢審核時間期間是否有非公司IP或非白名單設備登陸過沒有,可能查詢不到任何記錄。
而設計層次上的4.3問題,被拒的郵件有不少比例會附上截圖,一般多為首頁。因為啟動過,所以能查詢到審核人員的設備、IP,瀏覽哪些頁面等等信息。曾經試過,收到被拒郵件被附上與某某APP的相似信息。
再而設備、IP等信息被關聯拉黑出現的4.3問題的被拒郵件內容更偏向代碼層次的模版,無任何記錄,就是被拒了。
注:怎樣查詢異常IP/設備,做了數據埋點追蹤,再而送審的版本,除了公司內部的人能登陸,其他人是不可能登陸送審包的
遇到以上三種4.3問題,我們應該怎樣處理。在說怎樣處理前,我們先詳細說說三種4.3問題是怎樣的
一、代碼層次的4.3問題
兩個產品代碼層次上相似度過高,超過70%(數據我猜的,一般作垃圾代碼新增判斷標准是超過30%)。
無論是與線上的產品代碼相似,還是與曾經送審未通過產品代碼相似,出現這種情況有以下幾個可能性:
-
已上架或送審被拒的AB產品代碼相似,比較容易存在在綜合功能產品分拆小功能產品上,或模版化的產品上
-
開發使用開源代碼或者接口,導致代碼上相似
-
添加垃圾代碼混淆,垃圾代碼占比過大造成的代碼相似
二、設計層次的4.3問題
這類4.3問題,是人為導致的。嚴格來說,這App已經通過機審了,不料其他設計上雷同,如itc后台的icon圖標/送審截圖/應用名后綴版本,又如整體App設計類同,首頁一模一樣等;很容易造成審核人員直接認為克隆包存在。這也許就是為什么4.3問題被拒郵件內容會有首頁截圖的緣由。
可能問題又來了,對於蘋果審核人員,日均過審幾百上千的產品,如何做到識別設計上的雷同。單純說是對某App有印象的解釋,很難讓人滿意信服。對此,有兩個疑惑需要解答的:
-
審核人員怎樣得知與某App相似的,並且截圖
-
審核人員的后台是怎樣的
為什么會有以上疑惑,或許與我打雜職業生涯有關,我做過很多亂七八糟的東西,經歷很多崗位。
-
如SEO的偽原創文章(類同大學論文檢測),原理都是基於一個后台,通過技術上比稿,從而得到兩者或幾者之間相似度。在偽原創文章檢測后台上比稿,不僅能給出文章總體相似度,還可以給出與那些文章相似度的比例;
-
視頻圖片內容網站的監黃系統,經歷三點識別,漏肉比例識別,其他技術識別后,得出大概比例,經過監黃比例做分層預警系統,最后才到人審核;
-
百度、谷歌圖片識別系統
是不是有一種和蘋果審核極度相似的錯覺,作為萬億的蘋果公司,技術上完全是可以做到的。況且,IOS開發還是封閉型生態圈的,多款產品比較更簡單。基於這些,也引出我第三個4.3問題的個人猜想;
三、設備、IP、開發者賬戶、聯系人、綁定銀行卡等信息關聯上的4.3問題
-
在16年直播時候,有人的賬號被封號,有共同的點。同樣的套殼直播產品,結果掛在某個被認證身份證下多個賬號,或者同個銀行信息下多個賬號,一律被封號,而其他非這些信息的卻神奇避免了。如果從代碼相似度上解釋,給不出合理的解釋,那幾個幸存者是怎么一回事;
-
不少開發者開發一款新的App,但是送審時候莫名其妙的遇到了4.3問題。明明是新產品,代碼上毫無關系,UI也是全新的,再而市面上也沒有同類的產品,但是竟然遇到4.3問題。
對於情況,我想到的可能性有這些:
-
開發人員使用別人開源代碼,不幸這部分開源代碼被蘋果機審標注為克隆包代碼;
-
開發人員使用別人開源代碼,在自己的產品中代碼占比過高,再而代碼被多人開發者使用,被認為克隆包;
-
自身開發者就是克隆包玩家,產生過多的克隆包,導致自己的設備、IP、開發者賬戶、聯系人、銀行卡等信息成為蘋果黑名單,被蘋果審核認為只要是這些信息的開發者所開發的產品均一律被認為克隆包
截止目前為止,大部分4.3被拒信息指明,第3種可能性是存在的,避免這些信息也有助於過馬甲包,游戲行業的人早有體會。
基於以上種種猜想,針對各種情況,我們目前應該怎樣處理各種4.3問題
一、代碼層次的4.3問題
-
整理以往所有送審的開發者賬號,整理出類似克隆吧產品的賬號,下架已上架產品,處理未通過審核產品,統一更新一個版本,上傳一個空殼包,並且在所有App應用名命名為作廢包+時間點;
-
代碼上的相似處理
1⃣️已有代碼的混淆(改類名,改函數名)
2⃣️添加垃圾代碼,使垃圾代碼調用某一個功能,這功能集中某個頁面,用戶端不可見
-
垃圾代碼的相似處理
避免與目前自己其他產品克隆包添加的垃圾代碼一樣
二、設計層次的4.3問題
-
設計一套全新UI,色調、交互精打細磨
-
交互上盡可能使用蘋果最新功能的交互,適配蘋果最新的產品
-
itc后台的送審icon、應用截圖重新設計,與目前在線產品有明顯的差異性
-
應用名起名,使用全新名字,而不是某產品后綴名字,如省唄極速版
三、設備、IP、開發者賬戶、聯系人、銀行卡綁定等信息關聯上的4.3問題
-
開發者賬號避免處理
1⃣️同一款類似的產品不放在一個送審賬號上
2⃣️同一個開發者賬號盡可能不關聯幾個馬甲包產品
-
打包電腦設備處理
如有條件最好不要用同樣的MAC打包,如無條件,盡可能不超過5個克隆包
-
上傳包IP處理
上傳克隆包IP,盡量避免與其他克隆包的IP相同
-
聯系人、收款銀行卡信息處理
過多克隆包,盡量避免同一銀行卡信息、聯系人關聯
-
技術網站、隱私協議用獨立域名處理
如果有條件,盡可能使用一個獨立的域名,技術網站盡可能復雜點,有產品信息,有聯系信息,有公司信息等等。
以往,做馬甲包時候,經常使用類似上線了的工具搭建官網。
-
App內關於產品能直接訪問技術網站官網,在官網上能找到隱私協議等,雖然不知道會不會影響,作假作全套
以下是臆想中蘋果審核后台,純屬是臆想,沒有雷同。設計比較隨意,沒有經過嚴謹考慮。圖片有點長,如果有興趣,可以后台回復“蘋果是大爺”獲取圖片。