3.2.1和5.2.1被拒不需要具備金融許可證上架App Store教程

自從國內上架金融理財貸款P2P類型的App必須要具備金融資質後，現在想要上架到App Store已經很難了，就算你有了資質還不一定能夠。下面就給大家分享一下關於p2p類提審或版本迭代被拒的各種教程。先說說我的故事吧，至於乾貨，看文章最後的總結就好。另外最重要一點，你的XXApp如果被拒超過兩次，那麼你提審app所使用的電腦就不要在這臺機器重新提交你修改或補全資質然後上架這方面的操作。這是2018-04-01本人經過測試發現的問題，這個蘋果審核機制。。。從 2017 年 12 月 06 日起，到 2018 年 4 月 8 日，向蘋果提交審核共計 20 個版本，收到了 11 個 3.1.1 、3 個 4.3 、5 個 2.1 和 2 個 2.3 ，一個開發者帳號基本報廢；最後終於找到了審核問題所在，在 3 月 28 日成功上架 App Store?，完成了這次應用版本更新的使命。2017 年 11 月 20 日，提交了我們應用的正常升級版本（版本 1 ），2 天后，收到蘋果反饋，違反了 3.1.1 ，被告知包含第三方支付。從這天開始，就開始了四個月與蘋果審查人員的漫漫鬥爭路。起初，收到這個回復的時候，我們也是一臉懵逼，這個版本升級並沒有特別的，支付相關的內容，而且我們也是一直老老實實的在使用蘋果內購，並沒有使用過什麼微信和支付寶支付。然後問題丟給開發去排查，開發也是不知從何下手，只能懷疑是第三方 SDK 中含有什麼違規內容，於是便將微信、QQ 等 SDK 全部換成了純淨版，提交審核（版本 2 ），以為會正常通過。2 天后，蘋果反饋結果還是 3.1.1。這就很疑惑了，以前都正常的東西，現在怎麼就突然出現問題了。此時我們團隊在網上逛了各種論壇尋找解決方法的時候，發現 12 月中旬蘋果升級了機器審核算法，很多曾經接過或者懷疑帶有三方支付的 SDK 都被拉進了黑名單，近期有大量應用被蘋果以 3.1.1 打回，其中，也有很多和我們一樣，沒有使用任何第三方支付的代碼，但是也被 3.1.1 打回。看來是蘋果爸爸調整了算法，因為我這邊是專門代上架金融理財彩票類App的，所以我的很多客戶被誤傷了。當然，不管是不是被蘋果誤傷，必須都得找到原因並進行修改。（不然就被客戶罵死了，因為我這邊是包維護的）這時候需要說一下我上架的應用的代碼結構了，我上架的整個應用分為結構較為獨立的幾個部分，大致分為以下幾部分：

·遊戲資源文件：公司內其他合作部門提供的資源，代碼較簡單，排查較容易；·SDK 及引擎：公司內較為通用的內容，公司其他應用內也會使用到；·平臺級代碼：只有我們自己的應用會使用到。根據代碼結構，我們首先懷疑了遊戲資源文件中存在問題，因為遊戲資源文件不是我們部門自己開發寫的代碼，且安卓/ iOS 使用的資源文件較類似，同時，我們對其中的內容也不是很了解。於是我們聯繫相關部門，對遊戲資源文件進行了認真的檢查和修改，將遊戲資源中非蘋果支付的支付寶和微信支付欄位全都去掉，替換遊戲資源文件後提交蘋果審核（版本 3）。然後提交審核幾天後，蘋果反饋 3.1.1 ?此時我就覺得這樣排查沒有明確的排查方向。於是，所以筆者我覺得可以嘗試進行申訴一下試試，因為之前是有通過申訴獲得了有效信息並最終通過審核的經歷。於是我們向蘋果提起了申訴。沒多久，蘋果給回復了，告訴我們應用中有「 YYY SDK 」（一個同行競品的 SDK ，此處具體什麼 SDK 就不進行說明了）

這申訴結果讓我更加迷茫了，這是客戶的競品產品，所以客戶也不會傻到使用競爭對手的 SDK ；於是我們懷疑可能因為是同行競品和我們應用某些代碼結構比較相似，而競品應用使用了第三方支付被蘋果拉黑了，導致我們的應用也沒法過審了。於是，我們認為是被蘋果誤傷了，畢竟第三方支付動到了蘋果的蛋糕，這是蘋果堅決不能容忍的。覺得自己上架的App是被誤傷後，我再次向蘋果提出申訴，並且向蘋果提出了電話溝通的請求，然而蘋果這次更加堅定的回覆「我們確認你的應用中含有第三方支付的方法，回去好好檢查吧」，根本不給我們電話溝通的機會，不得不說還是蘋果爸爸強硬（我很想打si審核團隊），所以這次我也不敢在申訴了，之前幫另個客戶上架的時候，有過多次申訴被蘋果直接將開發者帳號拉黑的經歷，已經不敢輕易惹怒蘋果爸爸了。只能打斷牙齒往裡吞了，默默的回去繼續排查代碼了。我的遊戲資源文件已經基本沒有可以修改的內容了，申訴也沒有效果，然後下一步繼續排查引擎及 SDK ，對引擎及 SDK 內所有充值相關的欄位都進行了替換，所有支付相關的欄位，包括類似 alipay 的欄位都進行了刪除。提交審核後（版本 4 ），蘋果還是反饋 3.1.1?。App的資源文件，引擎及 SDK 都做了修改之後，就只剩下平臺級代碼未做修改，於是再對平臺級代碼中支付相關的欄位名，能替換的替換，能刪除的刪除，處理乾淨之後，提交審核（版本 5 ），然而3天後還是收到了蘋果 3.1.1 的反饋。三個模塊都修改嘗試了，然而都是一樣的結果，我們只能懷疑是修改的不夠徹底，於是將三個模塊都進行了更加徹底的修改，甚至已經犧牲了有些功能不能正常使用，然而提交後（版本 6 ）以後，又TM還是收到了蘋果 3.1.1 的反饋。此時，我的帳號已經提交了很多個版本了，審核速度開始變慢，根據我們代碼結構，引擎及 SDK 這部分其他應用也在使用，於是我們將修改後的引擎及 SDK 集成在其他應用中提交審核，提審過幾個應用後，通過審核了。說明 SDK 相關的內容是沒有問題了，遊戲資源部分基本上是不會存在問題的。此時壓力全部落在了我們身上，使用同樣的 SDK ，其他應用都能夠通過，我們的卻不通過，肯定是因為我們自身代碼出現問題了。在很無奈的情況下，我們再回顧蘋果審核條款，發現這樣一句話似乎會有不一樣的解讀：

由於我們的應用確實是有一點點隱藏功能開關的，於是我們懷疑蘋果是檢測到了我們的隱藏功能開關，認為我們提交審核的是非完整版的應用，而完整版的應用需要使用第三方支付才能夠解鎖獲得（現在回頭來看，真的是病急亂投醫了）。然後，為了驗證這個問題，我們同時提交了兩個版本，一個版本去除了隱藏功能開關，將隱藏的功能直接刪除掉（版本 7 ），另一個版本只保留隱藏的那一小部分功能，提交審核（版本 8 ）。然而，反饋回來的雙雙都是 3.1.1?。這樣的反饋結果說明，是真的存在什麼第三方支付問題，隱藏功能開關的猜測是不成立的。此時，開發那邊發現我們應用的打包配置工程中有一個地方存在幾千個沒有什麼用的，不知道是誰寫的 schema（打開其他應用的參數），懷疑是這數千個 schema 中的某一個和其他公司的相同了，從而觸發了蘋果的特徵庫，導致我們應用的被 3.1.1 打回。項目組也已經沒有什麼可靠的辦法，既然有可能，就去試一試吧。於是刪除了這部分內容，提交一個包（版本 9 ），然而結果還是 3.1.1 打回（現在回頭來看，這個時候是已經比較接近最終答案了，但是在當時的情況下，是沒法立即確認出問題了）。這時候，我們的上架問題已經很緊迫了，手上新的版本也早已經停止了下來，新的需求也不接了，大佬們也都在關注著這個問題。在排查了兩個多月後，我們還是沒能解決問題，產品，技術上都沒有什麼更好的辦法。然後，經過項目組討論後，我們被迫開啟了應用重構之路。計劃將整個應用重新寫一遍，功能一點一點加上去，一次次去提審，一點點去排除 3.1.1 的問題，直到找到問題原因，解決問題，再上架。雖然這個方案時間成本非常高，但是我們也是別無他法了。幾天後，重寫的最簡單的應用，僅僅包含註冊登錄和最簡單的功能，提交蘋果後（版本 10 ），收到蘋果反饋 4.3?。慶幸，終於不是 3.1.1 了，但是這時候我們還是沒法確定 3.1.1 問題不存在了。為了驗證我們這個包是否是確定通過了蘋果機審的，我們針對 4.3 問題，進行了相應的處理，添加了部分廢棄的代碼，希望能夠通過機審。然而，這個套路並沒有通過蘋果的審核（版本 11 ），然而這個版本還是被?4.3 打回了。雖然第一個包沒有收到 3.1.1 問題，看上去重寫的方案是可行的，但是，我們沒法確定 3.1.1 問題已經解決了，同時我們也不甘心找不到問題一點點的重寫整個代碼。分析之前的結果，我們除了代碼的精簡外，還替換了打包工程，於是我們懷疑我們打包工程是不是存在什麼問題呢。於是，我們使用新寫的，最精簡的代碼，在老的打包工程裡打包提交審核，幾天後，蘋果反饋 3.1.1?，此時，我們好像看到了方向，打包配置工程很可能存在問題。這時，我們在網上看別人的審核攻略的時候，發現了兩個很重要的點：·有資質的公司開發者帳號不能在用來提交這個App了，實在沒法通過蘋果審核，最後更換了打包工程，更換了開發者帳號，重新提交後，通過了審核。——打包工程和開發者帳號都可能會影響審核；·蘋果機審基本上所有掃除來的問題都會直接反饋的（除非同時觸發多個問題，會直接反饋 2.1 大禮包）關於2.1大禮包被拒問題可以參考：https://blog.csdn.net/qq_41917230/article/details/79934326——確定最新的包只有 4.3 ，沒有 3.1.1?分析我們最近提測的包，兩個包都只反饋了一個問題，說明兩個包不同的地方肯定是存在問題的。兩個包是替換了打包工程的，說明我們懷疑的方向是對的。為了驗證打包工程哪裡存在問題，我們對打包工程和代碼的關係進行了分析：打包工程裡面有什麼？打包工程裡面也有代碼內容，雖然這不是我們寫的的代碼，但是這些代碼最終也會被打進包裡，提交到蘋果進行審核。在聽了開發的描述之後，我對打包工程進行了這樣的分析：（這也是我和項目組成員解釋的較多的一個圖)

平臺級代碼分為是哪個模塊的話，我們最簡單的部分看做是代碼模塊 3 ，這部分必須要用的工程配置看做是 C ；於是，我們之前提交的版本便可以這樣進行分析：3+a+b+c=3.1.13+C=4.3而打包工程 C 和 c 可以看做是一樣的內容，於是我們得出結論，打包工程 a 和 b 部分存在違反了 3.1.1 的內容。所以我在分析這個問題的同時，我和我們的上架團隊還是在嘗試在新的打包配置工程+最簡單代碼的版本上嘗試通過機器審核，在對應用界面做了部分修改後（改的簡直慘不忍肚），最後在提交審核（版本 12 ），終於通過了機審，人工審核未通過，此時我們已經不奢望通過人工審核了，我們的標準已經調整到通過機審就是天大好消息了。這個版本通過機審後，我們也堅定的相信，我們這個版本是不存在 3.1.1 問題了。再回到打包配置工程的問題上來，我們需要驗證 a ，b 是不是真的存在問題，於是我們提交了去掉了 a 和 b 的版本（版本 13 ）：3+c=2.3+2.1（機審通過）這樣的結果，確定了打包配置工程中的a，b部分存在問題了，但是代碼 1 ，2 部分還未確定，於是我們又提交了增加代碼模塊 1 ，2 的版本（版本 14 ）：1+2+3+c=2.1（機審通過）至此，我們?3.1.1 的問題原因終於找到了。而這時，開發根據定位的問題，將可能懷疑的對象和之前蘋果反饋給我們的「 YYY SDK 」進行了比較（反編譯），發現原來我們打包工程配置中包含一個 SDK 命名和「 YYY SDK 」的文件命名一樣，而友商的「 YYY SDK 」中這個文件確實包含各種第三方支付方式。接下來問題便簡單多了，直接在我們主帳號下，刪除了部分打包工程配置的一部分內容後，3 月 26 日提交審核，3 月 28 日審核通過，3 月 29 日正式上架。這持續了 4 個月的上架審核過程，也暫時的告一段落了。慶幸在 4 月份完成了上架，因為再晚一點，還必須要完美適配 iPhone X 才能上架。雖然上架了，但是還是耽誤了客戶的很多時間，但還好得到了理解最後，將我的整個App上架過程中的一些收穫免費分享給大家：必看乾貨1、蘋果 2017 年 11 月中旬升級了機器審核算法，機器審核更加嚴格；2018 年 1 月份再次升級審核規則，一次觸發到多條問題的時候，會被 2.1 大禮包打回。（在這裡我要再次提醒的是用來上架的電腦 上架被拒兩次後就不要在使用同一臺電腦進行提交了）2、蘋果有自己的特徵代碼庫，只要和這個特徵代碼庫存中代碼撞車了，均會被認為是違反了相應的條款，不管這部分代碼是否真的是違規了。3、3.1.1 如何解決：·去掉第三方支付相關內容，如果有需要，可採取下發文件的形式實現網頁支付·重點檢查第三方 SDK ，是否都是純淨版本·版本較老的，已經停止使用的 SDK 或其他代碼，及時更新或者刪除·相關 SDK 停止使用之後，及時刪除工程配置中的內容，以免留下隱患4、4.3 如何解決：·修改應用界面，icon·添加廢棄代碼·改名字·修改素材及 UI 色調等·修改功能界面等，可改功能可做小開關·如果多次不過審，請更換開發者帳號，解決問題之後，再正式提交其他經驗·一個帳號多次提交審核不通過的時候，速度會變慢，可以嘗試更換其他開發者帳號提交審核；·成功上架的應用，才會被納入特徵庫，才會被用來比對代碼相似度（在一個帳號下上架的應用，在另外的帳號進行提審，會觸發 4.3 ）；·機器審核的時候，所有問題會一次全部反饋，如果機審沒有反饋某一條問題，說明機器審核的時候不存在該問題；·人工審核的時候，會按照一定的順序進行檢測，出現一個問題的時候就會停止審核，修改這個問題後，下次才會進行其他問題的審核；· 3.1.1 審核方式：預先對一些帶有第三方支付的SDK採集技術特徵，然後機器掃描是否介入了這個SDK。

3.2.1被拒回復郵件Guideline 3.2.1 - Business - Other Business Model Issues - AcceptableThe seller and company names associated with your app do not reflect a financial institution(s) in the app or its metadata, as required by Guideline 3.2.1(viii) of the App Store Review Guidelines.直接上被拒回復，3.2.1一般有兩種情況第一種：Guideline 3.2.1 - Business - Other Business Model Issues - AcceptableThe seller and company names associated with your app do not reflect the financial institute name in the app or its metadata, as required by Guideline 3.2.1(viii) of the?App Store Review Guidelines.Next StepsYour app must be published under a seller name and company name that reflects the financial institution name. If you have developed this app on behalf of a client, please advise your client to add you to the development team of their Apple Developer account.Please note that submitting documentation showing permission to publish this app on behalf of the financial institution will not resolve this issue. This app must be submitted under the financial institution’s own Apple Developer account.Once created, you cannot change your seller name or company name in iTunes Connect. For assistance with changing your company name or seller name, you will need to contact iTunes Connect through the?Contact Uspage. Select Getting Started from the first dropdown menu, then select General iTunes Connect Inquiry to contact the appropriate iTunes Connect team.如果你的開發者帳號確實具有金融資質，並且被3.2.1的解決辦法：接下來的解決方案就是到 guo家企業信息公示系統 找到你們公司的經營範圍，並且截圖圈出經營範圍，在被拒回復下發給蘋果App Store的審核團隊，並且附加上內容：我們XX公司是一家金融公司，以下截圖是guo家企業信息公示系統的截圖，你們也可以到guo家企業信息公示系統查詢我們公司的經營範圍含有資質並符合上架金融App的資質，這是網址：http://www.gsxt.gov.cn/index.html，我們公司全稱:（你們公司名字）請繼續審核，非常感謝（下面是給蘋果的截圖，相關隱私信息我進行了打碼，你們提交的時候不用打碼。）

第二種3.2.1被拒問題和解決辦法1.Both a copy and the direct link to the government website of your Business License that verifies the authorization from the Internet Loan Information Agency?(營業執照，營業範圍證明其是網絡借貸信息中介結構).2.A copy of your Finance Permit issued from the local finance governing authority (金融許可證).3.A copy of the Value Added Telecom Business Operation Permit issued by the local Ministry of Information Industry and Technology (從當地工信部獲得的增值電信業務經營許可證).這種一般都是P2P, 1.2.3提供相應的文件即可，相比第一種這個比較號處理，剩下的問題根據你們app的具體情況和問題回答就行了。營業執照.金融許可證.增值電信業務經營許可證是最重要的部分，後面的只要回答了就行，沒有那麼的重要，不用考慮太多，按照字面意思回答就行。

Guideline 5.2.1 - Legal - Intellectual PropertyThe seller and company names associated with your app do not reflect the name of the responsible institution in the app or its metadata, as required by Guideline 5.2.1 of the App Store Review Guidelines.Next StepsYour app must be published under a seller name and company name that reflects the name of the responsible institution. If you have developed this app on behalf of a client, please advise your client to add you to the development team of their Apple Developer account.Once created, you cannot change your seller name or company name in iTunes Connect. For assistance with changing your company name or seller name, you will need to contact iTunes Connect through the Contact Us page. Select Getting Started from the first dropdown menu, then select General iTunes Connect Inquiry to contact the appropriate iTunes Connect team.大致意思（也就是你們公司的開發者帳號類型性質是不能發布這種app,比如：理財類的app必須要金融理財類的帳號下面發布，醫療類的app同樣也必須要在醫療機構（醫院）資質的開發者帳號下發布，借貸或P2P類型的App必須在經營範圍有放貸資質和P2P相關的公司開發者帳號來提交發布．彩票類必須要相應有發行彩票機構的公司開發者帳號來進行上架。只要解決這些問題就可以上架了For assistance with changing your company name or seller name, you will need to contact iTunes Connect through the Contact Us page. Select Getting Started from the first dropdown menu, then select General iTunes Connect Inquiry to contact the appropriate iTunes Connect team.而這句話的意思是就是教你如何去更改名字．如果你的公司從一個沒資質的公司改成有資質的公司，那就需要改開發者的名字．列如：你要發布借貸類app, 可能你現在的公司名字叫做某某科技公司，如果你把這個公司改成了一個小額貸款公司，公司名字也進行了更換，那麼你就需要在iTunes Connect裡面把你的公司名字進行變更．並且提供和公司名符合的資質如果你App或者馬甲包之前在沒有資質的帳號提交過, 被拒之後才用的有資質的帳號提交, 如果沒資質的帳號不作處理就用有資質的帳號直接提交, 有資質的帳號基本都會報4.3. 所以需要在沒資質的帳號做一下處理, ios端新建一個應用, 直接用之前提交過的bundle Id打包，logo用一個純白或者純黑的圖片, 將這個新建的應用提交到應用市場, 構建版本中將之前被拒的包移除, 用這個新的應用頂替之前被拒的包, app名字改成 「作廢-此應用不再提交」 後面再隨便加一個數次, 因為這個名字別人已經用過了, app描述跟app名字一樣, 剩下的信息全部刪除.點擊保存即可，不用提交審核。如果大家要上架金融機構, 類似於貸款類的app一定要用公司開發者帳號.(這個是必要的，現在什麼馬甲包都沒有用)順便提醒一下各位開發者們警惕找上架IOS馬甲包的中介空手套白狼的騙子。如果接單那麼請通過第三方擔保平臺擔保，別被他們所謂的多少K的報酬，給那麼高是因為弄好了也不會給你錢，也別想著加控制開關。上架和製作馬甲包也花時間和經歷，到時候他們已經達到目的了，就算到時候你可以刪掉或者什麼的，虧的也是自己。。。當然這只是提醒如果有哪裡不明白可以評論留言，我看到會第一時間回覆你的，也可以發郵件到我的聯繫郵箱：[e-mail]