Internal Testflight build not installing hangs at

Question

My client is trying to install a build. Everytime, it hangs at 90%. Sometimes they leave it -- still hanging -- and check the app and see the version numbers as incremented.

This time though, they've left it running there for 5 minutes and still the version hasn't updated.

They removed the app and tried to install again and it's not installing, just hanging. How do I fix this?

Answer 1

I had this same issue and worked with Apple for literally a month going back and forth with there engineers. In my case it was my build number had a 0 after a . which for some reason they have a bug that considers that an 'old' version of your app.

Maybe you are having the same issue:

OK = Build #: 2015.6.29
Not OK = Build #: 2015.06.29

I know it sounds ridiculous but that was the fix for my issue. Not also Apple made mention that I shouldn't start my version number with 0 either, but I can not confirm that.

Answer 2

I ran into this same problem today but only used external testers, so while I suspect the following should apply to internal testers, I can’t confirm. Here is what I found in the documentation:

From App Distribution Guide: Setting the Version Number and Build String

The build string represents an iteration (released or unreleased) of the bundle and is also a two-period-separated list of positive integers, as in 1.2.3. For Mac apps, the user can click the version number in the About window to toggle between the version number and the build string. For details on possible values, see CFBundleVersion in Information Property List Key Reference.

Information Property List Key Reference is in documentation for Core Foundation Keys:

CFBundleVersion (String - iOS, OS X) specifies the build version number of the bundle, which identifies an iteration (released or unreleased) of the bundle. The build version number should be a string comprised of three non-negative, period-separated integers with the first integer being greater than zero. The string should only contain numeric (0-9) and period (.) characters. Leading zeros are truncated from each integer and will be ignored (that is, 1.02.3 is equivalent to 1.2.3). This key is not localizable.

It should have been a tip-off that my new build showed up in TestFlight as 1.1, instead of the 1.01 in my Xcode project.

Answer 3

We got into this situation two different ways. It started off by submitting a build, call it 0.9.1. Everyone was happy and could install.

We then submitted 0.9.2, somehow the provisioning profile became invalid after submitting. The result was that folks would get to 90% then be told that it could not be installed.

After we discovered that the profile had gone invalid, we turned off the switch for TestFlight testing. Users that continued to follow the email link would be presented with 0.9.2 even though the build wasn't available and would get the same 90% experience. For these users, we could instruct them to tap the "Close" at the top left where they would return to the list of apps in TestFlight and there they could tap on 0.9.1 and be good to go.

After this I invited some new testers. All of the new tester receive invites for 0.9.2 even though it is disabled, and there doesn't seem to be a way to help them. We are just going to have to submit a new build.