Testflight external user download gets stuck at 90% - ios8

Question

When downloading a beta build of my app, distributed via the Testflight external tester method, the download apparently stops at about 90%. In reality the download has completed and the app is ready to go.
This is very confusing for my testers.
The only suggested fix I've found to date, is to include the app info.plist in the distribution even though Xcode complains that it is not necessary. In any case including it had no effect.

Answer 1

We have the same issue with our beta users. TestFlight app will stop at 90% of the filled circle. To avoid confusion between builds we have included version information in the settings page of our app to enable users to view the version number. This way they can confirm they have the latest build. The code below will create a string with the version number and build.
+(NSString *) getVersionAndBuild
{
NSString *version = [[[NSBundle mainBundle] infoDictionary] objectForKey:#"CFBundleShortVersionString"];
NSString *build = [[[NSBundle mainBundle] infoDictionary] objectForKey:(NSString *)kCFBundleVersionKey];
return [NSString stringWithFormat:#"Version %# -- Build %#", version, build];
}

Answer 2

I met similar problem days ago. We got answer from Apple is we need take any leading 0s out from version number. Currently, before they fix TestFlight bug, we need change version number from 1.6.02 to 1.6.2

Answer 3

I’d like to confirm this is still an issue as of today, as my external testers experienced exact same thing.
Everyone downloaded build 1 without problem. Then I submitted build 1.01 and testers told me installation in TestFlight app on their devices would not complete, stuck at 90%.
I had the foresight to make a spare email address and invite myself as an external tester, so I was able to verify exact same issue. However, all of us found we could just exit TestFlight and my new build had replaced the old build on the device and functioned correctly as new build.
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.
Since then, I’ve run across several posts mentioning the leading zero problem. Better late than never, I actually dug into the documentation, and found this:
From App Distribution Guide: Setting the Version Number and Build String
The version number is a two-period-separated list of positive integers, as in 4.5.2. The first integer represents a major revision, the second a minor revision, and the third a maintenance release. The version number is shown in the store and that version should match the version number you enter later in iTunes Connect. For details on possible values, see CFBundleShortVersionString in Information Property List Key Reference .
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.
I only used external testers for my app, so I’m not able to confirm this be the same issue for internal testers as in this post: Internal Testflight build not installing hangs at 90%