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

虽说iOS的用户在拼多多的总用户群体中占比没那么大，但毕竟是三亿人都在拼的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云测的这种方式来实现线上实验、更新，恐怕这次的下架事件便不会发生了（当然，这样的话，热搜也上不了啦、卖家版下载排名蹿升到前十名的机遇也没啦，拼多多运营人员可要着急了哈哈）。

创作场景

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