RN+SDK套殼輕鬆解決蘋果稽核被拒3.2.1問題、2.1大禮包問題【最新上架技術】

ios8988發表於2018-09-03

RN就是提供你的sdk生成程式碼跳轉，可做CP，BC各種套殼製作幷包上架安卓和蘋果

進入2018年4月份，對於大多數做網際網路金融行業的同學們來說，更加難熬了，因為產品要上架App Store，更加困難了。對於大部分的互金APP（包括理財、現貸款、貸超等型別的App），蘋果除了要求資質之外，還有可能丟出2.1大禮包。

目前來說，只要遇到2.1大禮包，基本上就是無解了，除非運氣超級好，才有可能最終過審。

而在3.2.1條款裡，蘋果也不再是要求7條了，而是會適當的增加第8條，有時候是要求提供資質的編號，有時候是要求提供軟著。從這個層面來說，之前《iOS稽核被拒1.2到5.2.1到3.2.1的解決方案》、《iOS稽核被拒3.2.1的最佳解決方案》兩篇文章中提到的借用有資質的賬號上架的這種方案，已經被蘋果稽核察覺，並開始針對性的要求賬號使用者證真，這對於沒有資質但是想通過這種方式上架的同學們來說，無異於晴天霹靂，因為這條路正在被封上。

從個人近期上架的操作經驗結合一些同行業的同學們的反饋來看，蘋果稽核對於金融類App的稽核正在趨於更嚴，一些證券公司、銀行、消費金融公司的App也慘遭蘋果稽核拒絕，而後歷經艱難困苦才得以過審。這些正規的金融機構過審App尚且如此困難，更遑論處於監管動盪的互金公司了。

讓我們來看下蘋果稽核3.2.1條款的8條版本：

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 (營業執照，營業範圍證明其是網路借貸資訊中介機構).

Both a copy and the direct link to the government website of your Finance Permit issued from the local finance governing authority (金融許可證).

A copy of the Value Added Telecom Business Operation Permit issued by the local Ministry of Information Industry and Technology (從當地工信部獲得的增值電信業務經營許可證).

Your app’s and service’s Terms & Conditions.

In the case of dispute, what resolution mechanism does your app and service offer?

What is your responsibility in such case? Is such responsibility stated clearly in the Terms & Conditions?

How will the involved parties trace one another?

License numbers for the Business License, Finance Permit, and Value Added Telecom Permit in the Review Notes section.

這個8條的版本，一般在首次被拒提供營業執照、金融許可證、icp證等資料後，蘋果稽核會要求提供第8條條款裡資料編碼，以求驗證提供的資料的準確性。

當然，近期蘋果也不斷的進行大規模的複審，下架了很多沒有金融資質的App，這些App有的是很久前上架的（蘋果稽核還未要求資質之前）、有的是借用資質上去的、有的是碰運氣上去的。這些App的結局沒有任何意外，都上演了被下架的悲劇。

接著說下為什麼上文說到借用有資質的賬號上架的方法，已經逐漸不可行了呢？

因為蘋果稽核對上架成功後的轉讓出的App查的很嚴，一經發現，立馬下架此類App，同時可能會對該蘋果賬號進行封號處理，所以大部分的資質代上，目前已經成了一日遊。另外，蘋果稽核目前對此類資質賬號卡的非常嚴，過審非常艱難，所需時間非常久。

綜合以上，目前金融類App，只要沒有正規資質的，如果想要上架App Store，那套殼會是一種最穩妥的上架方式。

所謂套殼，就是將App偽裝成另一個App，在過審的時候，給蘋果稽核展示偽裝App的內容，等過審後，再切換回真實的App內容。此方法對原生、H5型別開發的App均適用。

目前的金融類App套殼，主要是將App偽裝成天氣類、新聞類的App，當然這種App偽裝的方式弊端諸多，比如說App的分類是一個問題，會影響App後續的ASO優化等，這是做App套殼的主要弊端之一。當然，如果能將App偽裝成財務類應用，則此類問題的影響，會被較大的削減。

從目前個人的經驗來看，App套殼，主要需要規避4.3、4.2、3.2（f）等問題，如果不能很好的處理這些問題，則套殼分分鐘出問題，而處理這裡面的問題，則需要有豐富的套殼經驗，不然就會輕易陷入此類惡性迴圈的問題中。

以上，就是個人關於處理3.2.1、2.1大禮包的一些新的想法，與各位同學分享，有其他好建議的同學，一同探討。

下面告訴大傢什麼是RN套殼

RN(React-Native)-通俗的說就是跨平臺開發吧，一套程式碼可以在安卓和ios上執行，針對ios而言其本質是對ios原生控制元件的一次封裝，然後通過js呼叫相關函式，檢視等。

1.檢視

移動端常用的檢視RN中都有相關的元件（在RN中移動端開發的檢視對應元件）對應。這裡RN基礎的東西不做相關贅述。大家有興趣學習RN的可以在RN中文網上學習。裡面相關的基礎的東西敘述相當清楚，只要一步一步按照上面的來，問題不大。

2.這裡重點說一下我遇到的棘手的問題，開發需要和H5進行通訊，網上查詢了很多資料，感覺實用的比較少，下面說一下自己這邊的開發。

原理簡述：RN和h5中相互互動是通過兩個方法：一個是onMessage（接收訊息）,一個是postMessage（傳送訊息），通過設定監聽（分別是圖1中的2和圖2中的2）來進行通訊。

首先，你需要有一個Html檔案，這個是你互動所必須的物件

html程式碼截圖：（1.傳送資料到RN,RN中設定了監聽就可以獲取到資料，要呼叫獲取的資料直接e.nativeEvent.data就可以拿到傳過來的資料；2.接收RN傳過來的資料，這個注意一點，經測試必須要同時寫上傳送方法好像才能進行通訊，才能接收RN傳過來的資料，測試不寫就收不到，這裡希望高手看到的話可以指點一二。3.Html 的標籤語言，呼叫對應的方法，實現介面互動）

4.2 最低功能要求

4.3 重複 App/馬甲包

主要說的是應用簡單及重複的問題

解決辦法

不願意換包換賬號的情況：

1.修改定價/釋出地區/產品分類

2.升級版本號重新提交

3.換 bundle id，換一個包重新稽核

願意換包換賬號：

4.更改開發者賬號，修改 icon、素材等

5.可以做開關，修改審前頁面

6.新增垃圾程式碼或者註釋塊

以上是老的辦法。

下面另外的親自最新測試方案

1、定期換電腦提包.

2、換電腦的序列號.

3、換圖示,換啟動圖.

4、換VPN環境.

5、定期換域名.有條件的，最好電腦不要超過三個包

開發者計劃許可協議 1.2被拒問題

金融理財應用

1.若是個人開發者賬號提交，嘗試換成公司開發者賬號提交，在 App 中儘量體現和公司相關的內容、品牌等；

2.將敏感資訊（例如 App 中出現的銀行名稱等）和功能刪除或隱藏；

3如果被拒原因中所指出的商標等確實是自家公司的，可以把相關資訊和證明資料等反饋給蘋果稽核人員；

4.（如果開發者賬號的郵箱用的是個人郵箱或技術支援網址和公司無關）將開發者郵箱改為公司郵箱，並將技術支援網址改為能體現公司的網址。

其他應用

1.刪除被拒理由中明確指出的，或者自身覺得敏感的資訊（例如應用名稱、關鍵詞或描述中出現的其他應用的品牌詞）或功能；

2.提審期間將敏感資訊和功能（優惠卷等）隱藏；

3.在 App 以及後設資料中多體現和公司相關的內容、品牌等；

4.如果被拒原因中指出的品牌詞、商標等確實是自家公司的，可以把資訊以及證明資料等反饋給稽核人員。