先点个题，两小步一大步，是我在做 iOS 产品更新时，会先提交两次次要功能的版本更新，再根据情况提交一次主功能产品更新，也可以把这种做法叫两次一主。
进一步细化到产品进度管理层面，就是给产品规划一个中等工作量的主要功能更新时，需要将它切分出两个小工作量的阶段步骤用于前期更新，最后在第三步一次性完成整个功能。
我这么做不是出于拍脑袋想当然，而是从过去提交产品更新踩各种坑，遇到各类问题后提炼出来的习惯。
第一类问题，是出了审核问题后自查困难。
当产品做了一次所谓的“重大更新”，代码、资源和元数据都做了全方位改动后，如果苹果反手来一个 2.3.1 或者 4.3 之类的错误，就会让你手足无措。
因为一次性提交了太多代码，2.3.1 的隐藏错误没办法查找，4.3 的资源错误也很难定位，这就会非常麻烦。
因此，如果把一个主要更新的代码和资源拆碎，分散到多次更新中，就比较容易在某个更新里发现问题，更容易定位到具体是哪个代码和资源犯了规。
第二类问题，是无法在理想时机发布重要更新。
关于这个问题，我需要先介绍苹果的一个审核玄学。这条玄学是：当一个产品在周期内提交两个更新被快速审核通过，那么第三次更新也有极大概率会遇到宽松的待遇。
为什么我说它是玄学，因为这个规律不会被苹果官方认证，但是在我的大量实践中却发现它大概率奏效，而每次我把这个思路介绍给其他开发者，他们经过实践后也大部分认同我的观点。因此，对待这个玄学我们可以抱着像对待中医的态度一样：不管它为什么，只管它是不是经常有效，是的话信了再说。
而正常的大版本更新显然无法充分利用以上玄学。因为当发布一个大版本更新时，必须面对不太确定的苹果审核吉凶周期。例如，当某些时候苹果审核比较凶残的时候（某些不确定的苹果内部业绩压力，某些时刻苹果打算严打某个品类，诸如此类）。很可能产品的大版本会遭遇极其严格的审核而败下阵来。
但鉴于大版本相比小版本对于产品的重要性，我们非常不愿意冒这种风险，所以希望在提交大版本时，产品在审核权重中要保持相对优势，因此，如果先提交两个拆分好的小版本，那么这两个小版本就相当于英雄无敌3中的“探路英雄”，带很少兵先把路探了，把风险问题夯实。
如果这两个小版本出了问题（遇到了审核恶意），那么就针对两个小版本解决问题，危机不会波及到大版本的内容中。一旦小版本解决了，那么就可以重新再出两个小版本继续探测。类比到英雄无敌3，就相当于两个探路英雄探路过程死掉了，这时候知道那条路有什么情况，可以再派出两个英雄去找别的路了。
最终，我们要保证提交的两个小版本连续顺利过审，那么就可以认为自己处于一个相对的安全周期，这时候再谨慎地推出我们的大版本，把握会大很多。
附：移动开发者联盟入群指引