RN+SDK套壳轻松解决苹果审核被拒3.2.1问题、2.1大礼包问题【最新上架技术】

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.如果被拒原因中指出的品牌词、商标等确实是自家公司的，可以把信息以及证明资料等反馈给审核人员。