目前来说，只要遇到21大礼包，基本上就是无解了，除非运气超级好，才有可能最终过审。
而在321条款里，苹果也不再是要求7条了，而是会适当的增加第8条，有时候是要求提供资质的编号，有时候是要求提供软著。从这个层面来说，之前《iOS审核被拒12到521到321的解决方案》、《iOS审核被拒321的最佳解决方案》两篇文章中提到的借用有资质的账号上架的这种方案，已经被苹果审核察觉，并开始针对性的要求账号使用者证真，这对于没有资质但是想通过这种方式上架的同学们来说，无异于晴天霹雳，因为这条路正在被封上。
从个人近期上架的 *** 作经验结合一些同行业的同学们的反馈来看，苹果审核对于金融类App的审核正在趋于更严，一些证券公司、银行、消费金融公司的App也惨遭苹果审核拒绝，而后历经艰难困苦才得以过审。这些正规的金融机构过审App尚且如此困难，更遑论处于监管动荡的互金公司了。
让我们来看下苹果审核321条款的8条版本：
这个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套壳，主要需要规避43、42、32（f）等问题，如果不能很好的处理这些问题，则套壳分分钟出问题，而处理这里面的问题，则需要有丰富的套壳经验，不然就会轻易陷入此类恶性循环的问题中。
以上，就是个人关于处理321、21大礼包的一些新的想法，与各位同学分享，有其他好建议的同学，可以私信我，一同探讨。
APP是怎么被开发出来的？有以下三种开发方式，下面就给大家简单的解释一下这三者有何不同，应该怎么选择。
一、开发方式
1、原生app开发
原生app就是利用手机本地 *** 作系统开发的手机app，目前手机系统主要分为安卓和苹果iOS两种，双方都有各自的编程开发语言及工具，原生app开发就是利用官方的开发工具进行分别开发。可以实现的功能多，性能优，但是需要人力投入多、周期长、成本高。
2、webapp开发
webapp开发主要是利用h5网页的模式开发app，相当于一个网站，然后加了一个app的壳。不需要开发安卓和iOS双版本的app，随意开发速度快，周期短。但是app内大部分内容都需要重新加载，所以加载速度慢、容易卡。而且因为是基于网页的，所以功能有限。
3、app混合开发
就是将原生app和webapp进行融合，部分核心板块利用原生模式开发，非核心内容通过web方式实现，但是这种开发模式现在技术不成熟，缺少相应的人才。
二、功能方面
1、原生app：相当于电脑上软件，可以调用很多的硬件设备，比如麦克风、短信、GPS、蓝牙等等。
2、webapp：相当于电脑上的网页。多用于页面展示类app。功能有限，只能进行简单的交互。
3、app混合开发：介入两种之间。
三、加载速度
1、原生app：app应用所有的UI元素、数据内容、逻辑框架均安装在手机终端上。访问的时候，不需要重新下载加载应用页面框架，所以加载速度快，不容易卡死。
2、webapp：每打开一个页面，都需重新加载页面的所有元素，访问速度受限于手机性能、网速等，加载速度慢，容易卡死。
四、安装
1、原生app：用户需要到各大应用商店下载安装并更新。安装包对比web版比较大。
2、webapp：通过移动设备上的浏览器访问，软件更新只需要更新服务器就够了，用户不需要重新下载安装app。
以上就是“APP是怎么被开发出来的？”的具体解答，希望能帮助到您
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）