iOS应用程序提交和testing评估过程
我目前正在为客户开发一个iOS应用程序。 向商店提交评审stream程往往是一个漫长的过程，对我而言是相对较新的。
我的客户希望使用TestFlight进行betatesting，然后通过XCode和Itunes Connect将应用程序提交到app store。
淘苹果的文档我似乎无法得到以下的好主意：
-
如果我想更新商店中的现有应用程序，是否需要再次完成审查过程？
-
如果我的应用程序已通过TestFlight批准进行Beta版testing，那么在将应用程序提交给商店时应该考虑这一点吗？
-
如果我想通过TestFlighttesting一个新版本，我是否需要再次完整地testing版本审查过程？
-
如果应用程序在应用程序商店获得批准，它是否会自动通过testing评估？
（这听起来是违反直觉的，因为你不想在发布到商店之后做一个testing版的testing，但是在一个场景中你可能想要做一个封闭的版本更新testing，而现场版本是在商店上的）
对于2016年中期…
如果我想更新商店中的现有应用程序，是否需要再次完成审查过程？
当然是。
如果我的应用程序已通过TestFlight批准进行Beta版testing，那么在将应用程序提交给商店时应该考虑这一点吗？
不，不幸的是，这绝对没有关系。
（事实上，向商店提交文件是很常见的事情，很明显，许多公司从不以任何方式使用TestFlight。）
如果我想通过TestFlighttesting一个新版本，我是否需要再次完整地testing版本审查过程？
说你有一个应用程序HappyApp：
您第一次提交进行betatesting时，会有延迟： 通常大约一天 。
这是等待“testing版批准”。 所以这就是TestFlight上HappyApp testing版的“build 1”。
每一个FIRST TestFlight构build，肯定都会有一天的延迟：
这似乎是一个人的过程。 （没有人确切地知道，无论如何，它总是在一天左右，截至2016年）。你可以依靠这个延迟，它永远不会更短。
实际的例子。 2016年7月14日至15日。星期五下午4点提交给苹果计算机发布的可在TestFlight上使用的第一个testing版星期四下午7点（又名“testing版批准”）。 21小时。
这正是在这一天的延迟期间的样子：
注意它（现在，最后）明确地说“等待Beta应用程序审查”。
2017年4月…
苹果改变了iTunes连接页面的devise（现在更糟，甚至更令人困惑）。
它不再说“等待testing版应用程序审查” – 它只是说“等待审查”。
结果是一样的，你必须等待大约24小时的第一次审查testing。
在下一步。 因此，在TestFlight 上构buildHappyApp的2,3,4,5 … ：
当你提交每个新版本时，每个新版本只需要很短的延迟（比如15分钟） 。
所有的testing版都是在第一次testing之后，严格地说是延迟了15分钟。 （绝对没有人工处理。）
下一个问题！
这是非常普遍的 – 约八分之一的构build – 构build无法通过 。
如果你已经等了30分钟，而且还没有完成： 把内部编号加1，然后重新推入 。
这是苹果蹩脚的TestFlight系统最常见的问题。 现在我们从未等过30多分钟。 我只是增加构build号码，并再次发送。
对于2+版本，有一个已知的问题 ，它有时会“卡住”。 在这种情况下，添加一个内部版本号并重新发送。
完全没有任何意义，比如说30分钟 – 增加内部编号并重新发送。
那就是这样。
另一个问题！ 我们再回到第一个版本
说你的第一个build筑比“大约一天”要花费更长的时间。 在我看来： 这可能是坏的 ：你必须做一个新的bundleID并重新提交。 （所以，如果是com.company.testing，则创build一个新的com.company.testingb，然后c，d等等。）
这导致了一个有趣的问题： 在开发过程中考虑使用一次性捆绑ID 。 准备提交给商店时，只能更改为真正的捆绑ID。 （所以，我们有捆绑id“com.mycompany.testinga”，b，c，我们用于所有的TestFlight – 后来我们改变为客户的真正的商店bundleID。）
如果应用程序在应用程序商店获得批准，它是否会自动通过testing评估？
愚蠢的是，不。 你必须重新开始。 HappyApp verion 7是在应用程序商店赚钱。 你制作版本8，并放入testing版发送给你的同事。 如上所述，Version8的第一个版本将会得到愚蠢的为期1天的testing版审查。
（这听起来是违反直觉的，因为你不想在发布到商店之后做一个testing版的testing，但是在一个场景中你可能想要做一个封闭的版本更新testing，而现场版本是在商店上的）
关于苹果审批stream程的一切都是愚蠢的。 留下你的常识！ ：/
这篇文章截至2016年夏季。
脚注！ 假设你制作一个全新的应用程序; 所以，新的BundleID，然后在iTunesConnect，你点击“加号”，从字面上做一个新的应用程序，称为“MagicApp”。 我的意思是甚至在你上传第一个版本之前。 事实上：相当烦人的是，需要半个小时才能将“MagicApp”的空存根清单出现在 iTunesConnect 的应用程序列表中 。 （!!）这是很烦人的，因为它没有指出发生了什么事情。 可以付费注销iTunesConnect并重新login。 一旦它出现在列表中作为一个存根，你上传你的第一个版本。 然后，这需要一个好的5-30分钟才出现。 然后 ，继续进行“testing评估”（如上所述需要1天）的过程。
我觉得这个线索对于你的问题缺乏一个清晰而简洁的答案。
按照提问的顺序：
-
是的 – 如果您想要更新App Store中的现有应用程序，则必须再次通过审阅过程。
-
否 – 如果您的应用在审核过程中获得批准，则在正式审核过程中不会考虑这一点。 你仍然需要等待正常的审查时间。
-
这取决于*如果你想用TestFlighttesting一个新的版本， 如果你改变了版本号 ，你将不得不再次等待beta版审查过程。 如果您更改了内部版本号，通常会立即批准。
-
不 ，如果某个版本被批准用于app store，则不会自动批准TestFlight。 更重要的是，一旦您的官方应用程序商店获得批准版本， 您就无法将新版本推送给您的TestFlight用户，其版本号与预先批准的官方App Store应用程序相同 。 如果您想将新版本推送给您的TestFlight用户，您必须更改版本号，并且由于它被视为新的“版本”，因此它将受到更长的Beta版应用程序审阅过程的影响。 更好的解决scheme是删除预先批准的官方应用程序，将新版本推送给您的testing用户，并重新提交您的官方应用程序进行审查。 我知道这很愚蠢，但这是唯一有效的解决scheme。
testing和最终版本的审查过程非常快。 我发现，一旦我通过testing版，最终版本审查过程更快。
您必须获得所有版本的检查，但这是因为您必须提交您打算推送到商店的每个构build的评论。 这是为了确保没有人获得应用程序，然后尝试潜入另一个完全不同的应用程序（可能是恶意的）。
对于新的TestFlight版本，您必须再次提交它以供审核，但是苹果对批准它们非常快速。 一旦获得批准，它会向您发送一封电子邮件，表示已获得批准，并会通过Testflight自动向每个人发送通知，以便新版本可供更新
一旦App获得了App Store的批准，那么所有Beta版更新的用户都可以更新到App Store当前可用的最新版本。
Beta版本和Final版本可能是完全一样的，但是Apple对待它们的方式是不同的，所以你不能通过App Store的批准，但是随后就开始使用TestFlight。 App Store是App Store，Testflight是TestFlight。
11月14日更新
TestFlight的评论时间：
- 首先上传构build ：平均需要36小时。
- 更新 ：从10小时到24小时的平均build设。