马甲包项目整理

从16年开始苹果开始加强审核贷款类App的审核力度，由此开始了与苹果斗智斗勇的马甲包项目。

最开始第一版dsq只开发了登录模块，其余为H5页面 正常通过审核。

几个月后突然提交被拒，发送了几个问题，问谁是放贷方，运营的公司是谁等等，回答是我们自己，然后正常通过了审核。那个时候并没有意识到苹果已经收紧了审核尺度，但是多留了个心眼，也为了渠道推广开始申请多个公司开发者账号，也开始提交马甲App（dsq-pro、dsq尊享版、dsq贷款版等多个马甲）。

—对应技术方案也不是很成熟，开多个分支，各种合并代码，开发为了快，导致留下许多遗留问题，并且之前的H5页面慢慢迭代成了原生（为了好的用户体验）。

又过了一阵子这些版本更新的时候分分被拒，市场仅留两个不可更新的App(没有预留热更新和无法继续上架)，这时候发现了两个问题，第一个是更新不了的问题要解决，第二个是这种上包的方式并不是很好通过。

—对应技术方案开始更新，又开始继续开发H5页面的dsq，保证可以不用更新只要马甲包一次上线即可。

又过了没多久突然发现要依赖sdk的时候，还是要原生同步更新，但是已经没办法上这种马甲包了，这个时候开启了套壳App开发，估时长，依赖人力，极大的影响了效率。

—对应技术方案就是后端接口切换App展示，开发了浏览器、资讯、计算器等马甲包，被拒上架均有，不保证每次都可以提交通过，但是极少有通过情况，且通过没多久也被下架。

后续技术这边人力紧张，需求压力大，各种需求与马甲包需求冲突，估时周期很长，组内讨论并与推广沟通后，决定开发几类App,稍微修改页面提交。

—记账、计步、计算器、各种工具这类App在此时诞生不断尝试情况下，大约通过约五款app。

时间不长，马甲包需求量加大组内开会讨论，决定做一个马甲包项目（WesKit）用更少的人力，尽可能少的修改完成一个马甲的上架，后续由于苹果复审和审查变严及公司走合规路线原因，更换账号主体，来回留转，导致均被下架。

—技术方案：把各个项目的主要逻辑抽象出来、把各个项目可组合的项目抽象出来，然后简单组装完成一个马甲流程。UI无法复用问题，通过与设计沟通，把稿设计为透明图片，更改主题颜色，构造成一个新的App，为了不让苹果审核出马甲，又将tab图片所有更换。极大简化了流程，大约上架时间为1人日。

新一轮尝试：因为之前的马甲方案，市面上太多，苹果熟悉了这种套壳上架方式，导致还是很难上架
—技术方案：（WesKit）的新一轮迭代已经开发完成，把以前的模块拆分组装更换为数据组装，和产品沟通过完成了一个通用模板，然后不断更换内部数据，使类型不同，每次打包出来即为一个新类型的App。并采取了三种模式提交，老套壳模式、不放内容二次更新模式、套壳放纯H5流程模式。看是否能校验出苹果的审核尺度，达到马甲包上架。