之前的传言终成现实，6.12后包含热更新的App将会被强制下架，大家都为包含12306在内的一众App的命运感到无（xi）比（wen）担(le)忧(jian)。我们之前也有篇文章专门分析过此事，文中也介绍了相应的应对方案。详情请移步http://www.appadhoc.com/blog/...
%e5%be%ae%e4%bf%a1%e5%9b%be%e7%89%87_20170608102640
同时，随着iOS11的发布，App Store整体风格上更加接近于新版的Apple Music和Apple News。当你初次打开AppStore之后首先你会看到Today Tab。Today Tab主要用来展示苹果官方推荐的App，为了用户提供更好的体验，让优质的开发者获得更多的下载安装。最后还有一个细节不知道大家有没有了解——苹果App Store官方宣布支持“自动更新的分阶段发布”。
我们来看看苹果App Store官方宣布的“自动更新的分阶段发布”能够提供什么功能，以下是官方文档的介绍：现在，您可以在iTunes Connect 中启用“自动更新的分阶段发布”，实现分阶段发布iOS App更新。利用分阶段发布您的版本更新将在7天内衣递增的比例想一打开自动更新的用户发布。
以下是关于“自动更新的分阶段发布”的相关文档
我们仔细研究了文档以后发现这次的所谓的“自动更新的分阶段发布”就是某种程度上的灰度发布。如果发现版本更新存在问题，可随时暂停分阶段发布。分阶段发布累计最多可暂停 30 天，暂停次数不限。这样做可以加速产品的发布进程，同时降低新版本发现致命BUG的影响。在运营层面，经常很多产品好不容易混到了苹果的推荐位，每天带量几万到十几万，总榜分类榜都借助推荐位维持一个较高的榜位。但是，产品更新的时候一个类似闪退的BUG，导致苹果不得不把产品从推荐位拉下来，以后再上推荐位变得极难，损失巨大。今后这个情况可以得到一定程度的缓解。看上去确实很美，不过仔细一想好像又觉得是不是差了些什么：
— 只能选择老用户更新时的灰度，也就是说新用户安装的都是新版，一旦有bug就是100%命中！
— 在群户群体的选择上是随机的，抽到的用户不能代表全局用户特征，统计误差也许很大、也许很小，谁知道呢？碰运气！
— App Store灰度发布的新版本一旦出现问题是无法回滚的，在修复版开发完成重新发布审核上架之前，已经更新的用户只能继续用bug版本！
— 只能针对大版本的做灰度，而无法针对功能模块甚至代码片段做灰度。
那么，一个更加完善的“分阶段发布”应该是什么样的呢？
— 应该是支持定向受众的，可以根据具体的场景选择在全体用户中灰度发布还是仅针对新用户或者仅针对0以下用户或者iPad用户等，还支持自定义用户标签（比如“付费用户”、“VIP用户”），更可以进行组合筛选，比只能选择老客户有更大的自由度，适合更加复杂多变的具体业务场景；
— 应该是能够科学分流保证代表性的。在用户分组过程中采取多维度动态均衡的专利技术保障选择的样本（比如10%的新用户）和总体样本（所有新用户）在iOS类型、oOS版本、浏览器类型、浏览器版本、系统语言、设备类型、设备名称、屏幕宽度、屏幕高度、应用版本、SDK版本等多重维度下都保持一致，绝不碰运气；
— 应该是可回滚可控制的。一旦出现BUG等互联网产品灾难，可以关掉灰度中的新版，所有用户回旧版。甚至可以不着急修复，先分析原因以便下次迭代优化。App Store只是可以让BUG影响面积减小，却无法把受影响的这部分用户从BUG中解救出来，治标不治本；
— 应该是支持不同模块的灰度，并且可以在一次App发版中包含一系列多个小的灰度发布，甚至和具体指标挂钩，比如：提升性能对服务器压力有多大；比如新功能对用户周留存是否有提升等。然后根据这些小的灰度发布的结果来决定发布哪些功能，回滚哪些功能，而且这些都不用发布新版。
其实Google Play早就提供类似灰度发布的功能，但是却始终没什么人用。除了国内的特殊情况之外，广大的国外开发者产品经理还是基于上述的原因选择其他的方案。各位国内开发者怎么办呢？不用急，广告时间到！
术业有专攻，吆喝科技的灰度发布同时支持Web、Android、iOS和服务端，用最专业的灰度发布技术为新功能、新技术、新设计、新策略保驾护航。如果你对灰度发布感兴趣，可以去读一下吆喝科技官网博客关于灰度发布的博客文章，一定会有更加深入的了解。http://www.appadhoc.com/blog/...灰度发布/
