Android平台做灰度再合适不过了。
找单一渠道投放特别版本出去是一个思路。另一个是做升级平台的改造，允许针对部分用户推送升级通知甚至版本强制升级。

无论哪种方法都需要做好版本管理工作，分配特别的版本号以示区别。

当然，既然是做灰度，数据监控（常规数据、新特性数据、主要业务数据）还是要做到位，该打的数据桩要打。

自己做产品时也有类似的需求，下边是我的方案:)

基本的逻辑是两个版本的代码都打到app包里，然后在app端植入测试框架，用来控制显示哪个版本。

测试框架负责与服务器端api通信，由服务器端控制app上A/B版本的分布，可以实现指定的一组用户看到A版本，其它用户看到B版本。

服务端会有相应的报表来显示A/B版本的数量和效果对比。

最后可以由服务端的后台来控制，全部用户在线切换到A或者B版本~

所以这个也可以用来做灰度发布 :)

另外由于打进去两个版本的代码，app的包体积会大一点(这和功能变化多少有关)

    iOS：官方的测试平台有Testflight，已经被苹果收购，但是整个内测用户邀请的方法流程还是没有打通，邀请用户成本比较高，是通过添加用户邮箱的方式，收到邀请邮件后还需要用户按步骤下载tf，下载应用等，没有一套教学视频普通用户还是难以接受。但非常适合在新产品发布前使用一些运营手段去建立这个用户群。用户一旦完成第一次操作，以后更新就像appstore一样简单。对开发者来说，操作也是和appstore一样的。比较方便。
且一个公司有多款产品的话，使用这个成本也会稍低一些，不过最大的问题还是灰度的用户量，和后期用户的消亡管理和扩充

还有一个是如果有打不同的iOS渠道包（除了appstore还有其他越狱渠道）或者其他tag的话，也可以通过升级配置来指定灰度发布。