拼多多被苹果下架,竟然可以这样解决

11月27日,网友发现在App Store中搜索“拼多多”,只能搜索到“拼多多商家版”,而从拼多多官网扫描下载“拼多多买家版”二维码,跳转至App Store后,则显示App不可用。

虽说iOS的用户在拼多多的总用户群体中占比没那么大,但毕竟是三亿人都在(gan)拼(keng)的App,此事一出,顿时激起千层浪,微博、百度等平台上议论不断,拼多多(被)成功抢占了热搜头条(恭喜拼多多运营人员被吃瓜群众带飞)。

很快,各自媒体相继发文蹭了蹭这个热点,于是这次下架风波的详细原因被大家伙儿丢了出来:目前,判断是与热更新类似的技术,导致拼多多审核版本与上架版本不一致,从而被App Store下架。

热更新,产品涵盖iOS端的朋友们一定对这个词不陌生。毕竟这种方法,能在服务器不关闭的情况下,允许用户打开应用直接下载安装更新代码(即绕过 App Store 审核的在线更新)。而如果通过提交 App Store 审核的方式下发更新,考虑到 Android 和 iOS 同步,可能需要一周甚至更长的审核周期,这无疑会干扰大家伙儿的运营节奏——往大了说就是影响大伙儿赚钱呐。就拿文案来说,文案是影响转化率的关键一环,假如你的产品有个关键功能的文案写的很差、转化率贼低,你是急着赶紧上新版本改呢,还是慢慢悠悠等苹果十天半个月把新版本过审了再改呢?

因此,不少运营、产品、技术同学都对这个方法垂涎欲滴,希望钻钻空子,悄咪咪用热更新把发版这事儿办了。这次热更新下架风波中涉及的拼多多、荔枝FM、搜狗地图等等,便是如此。只可惜还是没绕过苹果的复审,一不留神就被下了架。

难道真的就没办法绕一绕,做到不审核就直接线上修改App控件吗?

验证前置,告别热更新

有。不但有,还是苹果官方给出的方法。

其实,这里涉及到一个产品更新理念的问题。为什么会出现热更新的机制?就是为了解决线上环境常见的改版迭代问题推出的,企图避开苹果审核机制,直接后台控制版本更新,快速解决问题。

但是你想一想,同样都是改版,为什么不把验证前置呢?换句话说,如果我提前就将两个甚至三个、四个、一堆版本大方的展示给你苹果看,然后根据孰优孰劣的数据,将最优秀的版本留下、不好的版本去除,其最终效果,不正是热更新所希望达到的目标吗?

这便是A/B测试、灰度发布的理念了。

针对iOS开发者来说,Apple TestFlight这个官方推出的方法,已经支持iOS App的A/B测试,允许线上更新版本。不过TestFlight的A/B测试是通过多次构建以及增强组实现的,这种实现方式需要多个版本构建,对开发者来讲并不友好,比如,怎样针对属性、版本等同时进行实验便是个已知且尚未解决的难题。

那有没有更好的,即不属于热更新这个禁区,又能实时更新版本,最好还能进行数据监控的工具?

A/B测试+灰度发布的神兵利器

实际上,这种“验证前置”模式下提供的A/B测试和苹果严格限制的热更新不一样,因为主要是对标准属性的更改,在App Store可控范围内,所以A/B测试和灰度发布就不会被苹果封禁。在这方面,Testin A/B测试已经率先支持诸多App,例如36氪、自如、美图、在行、子弹短信等,皆在使用Testin来进行A/B测试和灰度发布。

Testin A/B测试还针对不同模式,提供了不同的A/B测试方式。比如,在可视化模式中,只要你在已过审的App中集成了SDK,那么,就可以在完全不用提交App Store审核的情况下,随时对标准控件属性(如颜色、文案、是否交互、是否隐藏等)进行更改,并实时上线。

不但如此,对于复杂的A/B测试,更可以使用灰度发布功能,先让各部分人群分别看到不同版本,而后通过开关机制,对数据表现最为突出的版本一键全量发布,即可直接让所有用户看到这个新版。关键的是,这也无需审核。

如果拼多多也是通过Testin云测的这种方式来实现线上实验、更新,恐怕这次的下架事件便不会发生了(当然,这样的话,热搜也上不了啦、卖家版下载排名蹿升到前十名的机遇也没啦,拼多多运营人员可要着急了哈哈)。

Testin云测A/B测试现已宣布永久免费,点击下方链接即可使用

快速开始您的第一个A/B测试实验吧