ios 内部测试人员的 TestFight beta 测试 - 构建状态为“正在处理”

TestFight beta testing for internal testers - Build state is "processing"

提问by elbuild

I've been using TestFlight for a while but this is the first time I'm submitting a build for beta testing directly from iTunesConnect since Apple bought TestFlight itself.

我已经使用 TestFlight 一段时间了，但这是我第一次直接从 iTunesConnect 提交 Beta 测试版本，因为 Apple 自己购买了 TestFlight。

I've been experiencing a weird behaviour (or maybe just the Apple's expected behaviour).

我一直在经历一种奇怪的行为（或者可能只是 Apple 的预期行为）。

I've added the user to my team (they've admin role), and I've selected them as part of the TestFlight tester in the dedicated panel. I've uploaded a build, switched the TestFlight Beta Testing on in the Build tab and selected the Internal Testers (just one in the screenshot below) I would like to receive that build.

我已将用户添加到我的团队（他们具有管理员角色），并且我已在专用面板中选择他们作为 TestFlight 测试人员的一部分。我上传了一个构建，在构建选项卡中打开了 TestFlight Beta 测试并选择了内部测试人员（下面的屏幕截图中只有一个）我想接收该构建。

Then...nothing happens, the state is still "Processing" (what?? shouldn't it be immediate?) the tester doesn't receive any invitation and I'm stuck. There's obviously something I'm missing here.

然后……什么也没有发生，状态仍然是“正在处理”（什么？？不应该是立即的吗？）测试人员没有收到任何邀请，我被卡住了。显然我在这里遗漏了一些东西。

Beside, even if one tester has already been invited, the panel still shows "To start testing, invite at least one tester". TestFlight was such a good product once...

此外，即使已经邀请了一名测试员，面板仍然显示“要开始测试，请至少邀请一名测试员”。TestFlight 曾经是一款如此出色的产品...

The two snapshot below show the state of my iTunesConnect panel. Any idea?

下面的两个快照显示了我的 iTunesConnect 面板的状态。任何的想法？

采纳答案by elbuild

It turned out that "Processing" a build, even if it is for internal testing only (i.e. the 25 accounts associated with your team) may take a couple of hours. Even if the binary has already been validated by Xcode and Application loader.

事实证明，“处理”一个构建，即使它仅用于内部测试（即与您的团队关联的 25 个帐户）也可能需要几个小时。即使二进制文件已经通过 Xcode 和Application loader验证。

I'm posting this as an answer since I've found no evidence about how long the "Processing" state is supposed to be. Given the length of some of the reviewing process it could be seconds, minutes, hours or days so it's nice to know that in this case it lasted a couple of hours.

我将此作为答案发布，因为我没有发现有关“处理”状态应该持续多长时间的证据。鉴于某些过程的长度可能是几秒钟、几分钟、几小时或几天，因此很高兴知道在这种情况下它持续了几个小时。

Now my console status is this one.

现在我的控制台状态是这个。

回答by Geoff H

Ok, here's the answer for the March 2015 people. I uploaded a pre-release build yesterday (4th March) via Xcode and the Internal & External Testing statuses are still at 'Processing' more than 36 hourslater. I even tried re-uploading, increasing build numbers etc. No joy. So I called Apple. This is what they told me;

好的，这是 2015 年 3 月人们的答案。我昨天（3 月 4 日）通过 Xcode 上传了一个预发布版本，并且内部和外部测试状态在36多个小时后仍处于“正在处理”状态。我什至尝试重新上传，增加版本号等。没有乐趣。所以我打电话给苹果。这是他们告诉我的；

They have been seeing this problem happening regularly for those who have uploaded pre-release builds on the 4th and 5th of March. They've been investigating whether it's related to uploading via Xcode as opposed to via Application Loader, however they've been seeing the problem happening equally between both methods.

对于那些在 3 月 4 日和 5 日上传预发布版本的人，他们经常看到这个问题。他们一直在调查这是否与通过 Xcode 上传而不是通过 Application Loader 上传有关，但是他们已经看到问题在两种方法之间同样发生。

So they're looking into it & will be trying to solve the problem for my particular case asap.

所以他们正在调查它并将尽快解决我的特定案例的问题。

I think with those who are finding that re-uploading with an increased build number is doing the trick, it's actually a red herring and is perhaps more to do with having re-submitted at a good moment for the system.

我认为对于那些发现以增加的内部版本号重新上传的人来说，这实际上是一个红鲱鱼，也许更多地与在系统的好时机重新提交有关。

I'll keep this thread posted as to how it plays out. In the meantime, if your pre-release has been processing for more than 24 hours and you don't fancy the idea of littering your app's management console with pre-release upload attempts (that can't be deleted), I suggest giving Apple a call to get your upload kicked into action.

我会保持这个线程张贴它是如何发挥作用的。同时，如果您的预发布已处理超过 24 小时，并且您不喜欢将预发布上传尝试（无法删除）乱扔在应用程序的管理控制台的想法，我建议给 Apple呼吁让您的上传生效。

iTunes Connect Upload Helpline:

iTunes Connect 上传帮助热线：

Inside US: [phone]From Outside: [phone]

美国境内：[phone]外部：[phone]

UPDATE 6th March:So, my original build finally came out of Processing. This took exactly 38 hours! I don't think this was Apple fixing it, it looks to me that this was it finally sorting itself out.

3 月 6 日更新：所以，我的原始版本终于从 Processing 中出来了。这整整花了38 小时！我不认为这是 Apple 修复它，在我看来，它终于自己解决了。

Before this I also tried uploading new incremented builds via Application Loader instead and also while logged-out of iTunes Connect, as per some of the suggestions below, but this didn't make a damned bit of difference for me. Which brings me to the fairly certain conclusion that it just works because you're submitting at a good moment (or perhaps may even be related your geographical location (I'm London)) and no other hokus pokus!

在此之前，我还尝试通过 Application Loader 上传新的增量构建，并且在注销 iTunes Connect 时，根据下面的一些建议，但这对我来说并没有什么不同。这让我得出一个相当肯定的结论，它只是有效，因为您提交的时机很好（或者甚至可能与您的地理位置有关（我是伦敦）），而没有其他 hokus pokus！

The original Testflight rather rudely puts Apple to shame here. They really need to sort this out.

最初的 Testflight 相当粗鲁地让 Apple 感到羞耻。他们真的需要解决这个问题。

回答by Neti Pengkhuan

Normally you should never see the status 'Processing'. Once the build status is set to Processing, it will never be changed; at least in my case. (See image below)

通常，您永远不会看到“正在处理”状态。一旦构建状态设置为Processing，它就永远不会改变；至少在我的情况下。（见下图）

The solution is to "keep trying." Try either increasing build number or version number, and keep submit to the iTunes Connect.

解决方案是“继续尝试”。尝试增加内部版本号或版本号，并继续提交到 iTunes Connect。

I got it work in the third attemptwith no processing time.

我在第三次尝试中让它工作，没有处理时间。

回答by Tommie C.

I found the following message from Apple ([email protected]) delivered to my Junk Mail folder. In the build settings for my app I set "Enable Bitcode" to No. I also changed the optimization level of the release build to None. After that my build was accepted and uploaded to the app store. The invite button became available for internal users at that point. Later I was able to get the app installed via TestFlight.

我发现以下来自 Apple ([email protected]) 的邮件已发送到我的垃圾邮件文件夹。在我的应用程序的构建设置中，我将“启用位码”设置为否。我还将发布版本的优化级别更改为无。之后我的构建被接受并上传到应用商店。此时邀请按钮可供内部用户使用。后来我能够通过 TestFlight 安装该应用程序。

Dear developer,

We have discovered one or more issues with your recent delivery for "XXXYourAppName". To process your delivery, the following issues must be corrected:

Invalid Executable - The executable 'xxx.app/Frameworks/libswiftCoreMedia.dylib' contains bitcode.

Invalid Executable - The executable xxx.app/Frameworks/libswiftFoundation.dylib' contains bitcode.

Invalid Executable - The executable 'xxx.app/Frameworks/libswiftDarwin.dylib' contains bitcode.

Invalid Executable - The executable 'xxx.app/Frameworks/libswiftCoreLocation.dylib' contains bitcode.

Invalid Executable - The executable 'xxx.app/Frameworks/libswiftCoreData.dylib' contains bitcode.

Invalid Executable - The executable 'xxx.app/Frameworks/libswiftCoreImage.dylib' contains bitcode.

Invalid Executable - The executable 'xxx.app/Frameworks/libswiftDispatch.dylib' contains bitcode.

Invalid Executable - The executable 'xxx.app/Frameworks/libswiftCore.dylib' contains bitcode.

Invalid Executable - The executable 'xxx.app/Frameworks/libswiftAVFoundation.dylib' contains bitcode.

Invalid Executable - The executable 'xxx.app/Frameworks/libswiftCoreGraphics.dylib' contains bitcode.

Invalid Executable - The executable 'xxx.app/Frameworks/libswiftObjectiveC.dylib' contains bitcode.

Invalid Executable - The executable 'xxx.app/Frameworks/libswiftCoreAudio.dylib' contains bitcode.

Invalid Executable - The executable 'xxx.app/Frameworks/libswiftUIKit.dylib' contains bitcode.

Invalid Executable - The executable 'xxx.app/Frameworks/libswiftSecurity.dylib' contains bitcode.

Once these issues have been corrected, you can then redeliver the corrected binary.

Regards,

The App Store team

亲爱的开发者，

我们发现您最近为“XXXYourAppName”发送的一个或多个问题。要处理您的交货，必须更正以下问题：

无效的可执行文件 - 可执行文件“xxx.app/Frameworks/libswiftCoreMedia.dylib”包含位码。

无效的可执行文件 - 可执行文件 xxx.app/Frameworks/libswiftFoundation.dylib' 包含位码。

无效的可执行文件 - 可执行文件“xxx.app/Frameworks/libswiftDarwin.dylib”包含位代码。

无效的可执行文件 - 可执行文件“xxx.app/Frameworks/libswiftCoreLocation.dylib”包含位码。

无效的可执行文件 - 可执行文件“xxx.app/Frameworks/libswiftCoreData.dylib”包含位码。

无效的可执行文件 - 可执行文件“xxx.app/Frameworks/libswiftCoreImage.dylib”包含位码。

无效的可执行文件 - 可执行文件“xxx.app/Frameworks/libswiftDispatch.dylib”包含位码。

无效的可执行文件 - 可执行文件“xxx.app/Frameworks/libswiftCore.dylib”包含位码。

无效的可执行文件 - 可执行文件“xxx.app/Frameworks/libswiftAVFoundation.dylib”包含位码。

无效的可执行文件 - 可执行文件“xxx.app/Frameworks/libswiftCoreGraphics.dylib”包含位码。

无效的可执行文件 - 可执行文件“xxx.app/Frameworks/libswiftObjectiveC.dylib”包含位码。

无效的可执行文件 - 可执行文件“xxx.app/Frameworks/libswiftCoreAudio.dylib”包含位码。

无效的可执行文件 - 可执行文件“xxx.app/Frameworks/libswiftUIKit.dylib”包含位码。

无效的可执行文件 - 可执行文件“xxx.app/Frameworks/libswiftSecurity.dylib”包含位码。

更正这些问题后，您就可以重新交付更正后的二进制文件。

问候，

应用商店团队

回答by Giuseppe Iacobucci

i was struggling with the same issues as a lot of people say.

正如很多人所说，我正在努力解决同样的问题。

Infact this morning i upload a second Build for my app and state "Processing" will not go out in hours and hours. I upload the second Bundle of the app to Itunes using xcode Archive/Uploader.

事实上，今天早上我为我的应用程序上传了第二个 Build 并声明“处理”不会在数小时内消失。我使用 xcode Archive/Uploader 将应用程序的第二个 Bundle 上传到 Itunes。

When i go out for lunch, i was thinking on "how Apple takes a lot of time to process a second build", instead of first immediatly set as Active.

当我出去吃午饭时，我在想“Apple 如何花费大量时间来处理第二个构建”，而不是首先立即设置为 Active。

Now i'm happy man, when i come back i decide to re-upload a third Bundle but using Application Loader instead of Xcode. This do the Magic how the screenshot figure:

现在我很高兴，当我回来时，我决定重新上传第三个 Bundle，但使用 Application Loader 而不是 Xcode。这个做魔术怎么截图图：

Immagine that the second build still in processing right now!!! Amazing Apple!!!!

想象一下，第二个构建现在仍在处理中！！！了不起的苹果！！！！

So use Application Loader and don't loose important time! Hope i help,

所以使用Application Loader，不要浪费重要的时间！希望我能帮上忙

回答by Fabio Napodano

this seems to happen from time to time and there is basically nothing the user can do about other than waiting. I have tried all of the above suggestions to no avail, then all of a sudden all the processing builds made it to the enabled state.

这似乎不时发生，除了等待之外，用户基本上无能为力。我已经尝试了上述所有建议都无济于事，然后突然所有处理构建都变为启用状态。

as of now (October 9th, 2015), it still takes up to one hour to process, but yesterday the situation was way worse, taking many hours.

截至目前（2015 年 10 月 9 日），它仍然需要长达一小时的时间来处理，但昨天情况更糟，需要很多小时。

回答by pj4533

I have been using TestFlight quite a bit, with no problems. Then this happened to me yesterday (stuck in processing). Perhaps some internal problem on apples side?

我一直在使用 TestFlight，没有任何问题。然后这昨天发生在我身上（卡在处理中）。也许苹果方面存在一些内部问题？

回答by Zach

I found that if I have ITC open while I upload the build, that it never leaves the processing stage. Making sure ITC is not logged in until I receive the notification on my phone seemed to work.

我发现如果我在上传构建时打开 ITC，它永远不会离开处理阶段。确保 ITC 未登录，直到我在手机上收到通知似乎工作正常。

回答by Abhishek Bommakanti

This was happening to me too in one of my builds. All my previous builds before that build were instantaneous. So I just created a new build (no code changes) and ignored the erroneous one. Once I turned on TestFlight testing on the new build, I got the notifications on my devices almost instantly.

在我的一个版本中，这也发生在我身上。我之前的所有构建都是即时的。所以我只是创建了一个新的构建（没有代码更改）并忽略了错误的构建。在新版本上打开 TestFlight 测试后，我几乎立即在我的设备上收到了通知。

回答by Ehmad Zubair

What did the trick for me was to change the VERSION number of the build, rather than just changing the build number. I'm not sure but turns out, my every 5th build for a version has that long processing queue issue.

对我来说，诀窍是更改版本的版本号，而不仅仅是更改版本号。我不确定，但事实证明，我的每个版本的第 5 个版本都有很长的处理队列问题。