如文章开头流程图所示，在不考虑 APP 首发的前提下（这是另外的大话题，另文单独介绍），提交一个APP 的新版本事实上有三种方式：
  

对于任何一个开发者而言，提交 APP 新版本时最重要的目标就是尽快通过审核。但俗话常说：欲速则不达。例如以上三种方式，尽管所需时间渐次缩短，但其实利弊之比也渐次凸显，还是需要根据实际情况进行抉择。


正常审核

　　对于绝大多数的开发者而言，走正常审核的路子是最常规也最安全的方式。老老实实做事，虽然短时间看起来会吃点亏，但从长期来看，收获反而可能更大。

　　尤其是一个团队如果能做到严格按产品规划进行周期管理，并且实现高质量的开发和测试，完全可以按照自己的节奏，次次都按计划实现准时发布上架。


加急申请

　　加急申请是苹果官方提供的一种特殊的快速申请通道，安全性上不存在任何问题。在提供合理理由的情况下，可以在2 ~ 3天内就完成提交审核上架的全流程。但为了避免滥用这个特殊通道，苹果官方非明文限定每年每个应用只接受2 ~ 3次申请，一旦用完就再也没有机会了。


付费交易

　　对于某些不计成本只想快速上架新版本的土豪团队而言，付费交易是不二选择。从个人实际感受来说，这种一手交钱一手交货的方式还真是能实现前两者都无法实现的超快速过审。但需要注意的是，这种方式是审核团队成员私下进行的不合法操作，涉及商业犯罪，能持续多久，以及东窗事发之后是否会被追责都不得而知。

　　APP STORE 提审这事，不管选择哪条路都会有本难念的经。下面我就详细讲一讲各种方式提交时可能遇到的问题。至于ITC（iTunes Connect）的官方说明文档，戳这里可以看到，还是那句话：值得好好研究一下。


一、正常审核

　　正常审核，也就是说，填好 iTunes Connect 里的 Metadata，上传了新的 Binary之后，就老老实实等着审核团队的大爷们按照排期临幸吧。


审核状态

　　一般而言，一个 APP 新版本的审核会顺序经历下面的流程状态。

　　上传之后，即进入等待时间为7 ~ 10天Waiting for review，具体的时间根据苹果审核团队当时的工作量情况而定，在这里可以看到近期审核平均耗时。

　　一旦开始被审核，就进入了 In review 状态 ，一般会在一天之内有结果，如果成功过审的话，则变为 Processing for App Store 状态。根据ITC 中的相关设置，此时会自动或者需要手动变为 Ready for sales 状态，然后需要半天左右时间在 App Store 中更新原有缓存可供用户下载。

　　而如果没能成功过审，则会变更为 Rejected 状态，这时就要考虑是申诉重审，还是修改Binary 之后重新提交排队，重新提交的话就又要再经历一个7 ~ 10天的正常审核周期了。

　　Waiting for review：等待审核

　　In review：审核中

　　Rejected：被拒

　　Processing for App Store：准备上架

　　Ready for sales：成功上架


申诉重审

　　虽然决定 App Store 里的各项事务上，苹果的审核和编辑人员一向像神一样说一不二，但他们毕竟也是人，也有犯错的时候。一旦审核过程中真的出现被误判的情况，就要勇敢和及时的申诉。从实际经验来看，申诉成功的概率相对还是非常高的。这里是我负责运营的一个项目的申诉实录，可以看看了解一下。

　　申诉方式其实也比较简单，就是直接在解决中心回复拒信即可，注意申诉期间不要对Binary 做任何操作，否则就只能走重新提交排队的流程了。此外，在申诉时，一定要注意以下的几个问题。

　　实事求是，不要妄图耍小聪明，如果拒信中提到的问题真的是 APP 本身的问题，则老老实实的改掉再提交，不要把问题往审核人员身上推，也不要找什么过往相同的案例，这种做法还没见过成功案例，纯属浪费时间

　　认真看拒信中提到的问题是什么，如果确定是审核人员误判，就详细得解释问题所在以及解决方案。需要摆事实的摆事实，需要上图的上图，总之越详尽越细致越好

　　尽可能用英文回信，这也算是一种和审核人员打交道的必要礼仪。虽然现在中文回信也有通过的案例，但用英文总体感觉效果还是更好一些的，效率也会更高一点


特殊情况

　　App Store 每年的圣诞假期都会停止审核一周左右，这会带来两个后果：

　　假期后审核时间变长，由于要处理积累的审核，一般而言新进入排队状态的审核耗时会延长至2周左右

　　假期期间榜单会冻结，因此如果有可能就努力在假期之前冲击一个好的排名，然后享受一个幸福的假期吧


二、加急申请

　　加急申请是ITC 官方为开发者提供的一条快速通道，通过这种方式，可以实现2 ~ 3天快速过审的目标。选择这种方式，需要提供一个合理的理由，目前官方支持以下三种：

　　Critical Bug Fix：严重 Bug，这种理由是通过率最高的，可能是因为审核者觉得有 Bug 没有审出来，他们自己也有责任吧。以这种理由进行申请的时候，需要 APP 里真的有个严重Bug，还需要写清楚 Bug 重现的操作流程

　　Time-Sensitive Event：限时事件，一般而言在节假日使用这个理由通过的概率会比较高，可以说自己已经排了多少的推广资源，活动按时进行可以新增多少的用户，如果不尽量说的高大上点，通过的概率很低

　　Other：其他理由，额，暂时还没有想到过可以说的清楚有信心能被接受的理由……

　　尽管加急申请的通过率的确不低，但千万不能当做常规方式使用，一年2 次的机会，还是留着用在刀刃上吧，否则真的到了关键时刻不被搭理，那就真的欲哭无泪了。

　　加急申请的方式也很简单，登陆ITC 账号之后，通过这个入口进入申请页面，然后按照页面上的输入项填写即可。这里有一篇介绍文章可以参考。


三、付费交易

　　不得不说，中国的确是一个神奇的国度，居然有人连黑箱一般的 App Store审核人员都能搞定……

　　从实际使用效果来看，还真能像商家承诺的那样，在24小时之内就搞定全部的审核流程。虽然收费不菲，老用户也得8K/次，但相比正常审核需要花费的1 ~ 2周的时间，不得不说，这钱花的那是相当的物超所值啊。

如文章开头流程图所示，在不考虑 APP 首发的前提下（这是另外的大话题，另文单独介绍），提交一个APP 的新版本事实上有三种方式：
  

对于任何一个开发者而言，提交 APP 新版本时最重要的目标就是尽快通过审核。但俗话常说：欲速则不达。例如以上三种方式，尽管所需时间渐次缩短，但其实利弊之比也渐次凸显，还是需要根据实际情况进行抉择。


正常审核

　　对于绝大多数的开发者而言，走正常审核的路子是最常规也最安全的方式。老老实实做事，虽然短时间看起来会吃点亏，但从长期来看，收获反而可能更大。

　　尤其是一个团队如果能做到严格按产品规划进行周期管理，并且实现高质量的开发和测试，完全可以按照自己的节奏，次次都按计划实现准时发布上架。


加急申请

　　加急申请是苹果官方提供的一种特殊的快速申请通道，安全性上不存在任何问题。在提供合理理由的情况下，可以在2 ~ 3天内就完成提交审核上架的全流程。但为了避免滥用这个特殊通道，苹果官方非明文限定每年每个应用只接受2 ~ 3次申请，一旦用完就再也没有机会了。


付费交易

　　对于某些不计成本只想快速上架新版本的土豪团队而言，付费交易是不二选择。从个人实际感受来说，这种一手交钱一手交货的方式还真是能实现前两者都无法实现的超快速过审。但需要注意的是，这种方式是审核团队成员私下进行的不合法操作，涉及商业犯罪，能持续多久，以及东窗事发之后是否会被追责都不得而知。

　　APP STORE 提审这事，不管选择哪条路都会有本难念的经。下面我就详细讲一讲各种方式提交时可能遇到的问题。至于ITC（iTunes Connect）的官方说明文档，戳这里可以看到，还是那句话：值得好好研究一下。


一、正常审核

　　正常审核，也就是说，填好 iTunes Connect 里的 Metadata，上传了新的 Binary之后，就老老实实等着审核团队的大爷们按照排期临幸吧。


审核状态

　　一般而言，一个 APP 新版本的审核会顺序经历下面的流程状态。

　　上传之后，即进入等待时间为7 ~ 10天Waiting for review，具体的时间根据苹果审核团队当时的工作量情况而定，在这里可以看到近期审核平均耗时。

　　一旦开始被审核，就进入了 In review 状态 ，一般会在一天之内有结果，如果成功过审的话，则变为 Processing for App Store 状态。根据ITC 中的相关设置，此时会自动或者需要手动变为 Ready for sales 状态，然后需要半天左右时间在 App Store 中更新原有缓存可供用户下载。

　　而如果没能成功过审，则会变更为 Rejected 状态，这时就要考虑是申诉重审，还是修改Binary 之后重新提交排队，重新提交的话就又要再经历一个7 ~ 10天的正常审核周期了。

　　Waiting for review：等待审核

　　In review：审核中

　　Rejected：被拒

　　Processing for App Store：准备上架

　　Ready for sales：成功上架


申诉重审

　　虽然决定 App Store 里的各项事务上，苹果的审核和编辑人员一向像神一样说一不二，但他们毕竟也是人，也有犯错的时候。一旦审核过程中真的出现被误判的情况，就要勇敢和及时的申诉。从实际经验来看，申诉成功的概率相对还是非常高的。这里是我负责运营的一个项目的申诉实录，可以看看了解一下。

　　申诉方式其实也比较简单，就是直接在解决中心回复拒信即可，注意申诉期间不要对Binary 做任何操作，否则就只能走重新提交排队的流程了。此外，在申诉时，一定要注意以下的几个问题。

　　实事求是，不要妄图耍小聪明，如果拒信中提到的问题真的是 APP 本身的问题，则老老实实的改掉再提交，不要把问题往审核人员身上推，也不要找什么过往相同的案例，这种做法还没见过成功案例，纯属浪费时间

　　认真看拒信中提到的问题是什么，如果确定是审核人员误判，就详细得解释问题所在以及解决方案。需要摆事实的摆事实，需要上图的上图，总之越详尽越细致越好

　　尽可能用英文回信，这也算是一种和审核人员打交道的必要礼仪。虽然现在中文回信也有通过的案例，但用英文总体感觉效果还是更好一些的，效率也会更高一点


特殊情况

　　App Store 每年的圣诞假期都会停止审核一周左右，这会带来两个后果：

　　假期后审核时间变长，由于要处理积累的审核，一般而言新进入排队状态的审核耗时会延长至2周左右

　　假期期间榜单会冻结，因此如果有可能就努力在假期之前冲击一个好的排名，然后享受一个幸福的假期吧


二、加急申请

　　加急申请是ITC 官方为开发者提供的一条快速通道，通过这种方式，可以实现2 ~ 3天快速过审的目标。选择这种方式，需要提供一个合理的理由，目前官方支持以下三种：

　　Critical Bug Fix：严重 Bug，这种理由是通过率最高的，可能是因为审核者觉得有 Bug 没有审出来，他们自己也有责任吧。以这种理由进行申请的时候，需要 APP 里真的有个严重Bug，还需要写清楚 Bug 重现的操作流程

　　Time-Sensitive Event：限时事件，一般而言在节假日使用这个理由通过的概率会比较高，可以说自己已经排了多少的推广资源，活动按时进行可以新增多少的用户，如果不尽量说的高大上点，通过的概率很低

　　Other：其他理由，额，暂时还没有想到过可以说的清楚有信心能被接受的理由……

　　尽管加急申请的通过率的确不低，但千万不能当做常规方式使用，一年2 次的机会，还是留着用在刀刃上吧，否则真的到了关键时刻不被搭理，那就真的欲哭无泪了。

　　加急申请的方式也很简单，登陆ITC 账号之后，通过这个入口进入申请页面，然后按照页面上的输入项填写即可。这里有一篇介绍文章可以参考。


三、付费交易

　　不得不说，中国的确是一个神奇的国度，居然有人连黑箱一般的 App Store审核人员都能搞定……

　　从实际使用效果来看，还真能像商家承诺的那样，在24小时之内就搞定全部的审核流程。虽然收费不菲，老用户也得8K/次，但相比正常审核需要花费的1 ~ 2周的时间，不得不说，这钱花的那是相当的物超所值啊。