Uploading a build signed by an Xcode Bot to testflight rejected for get-task-allow error

Question

When attempting to upload a signed .ipa file created by an Xcode Bot to TestFlight, I've been getting the standard

"Invalid IPA: The get-task-allow values in the embedded.mobileprovision and your binary don't match. Are you sure you created the IPA with the same type of certificate as the one you used to compile it?"

warning. The problem is that there is no entitlements file for this application, and I am absolutely positive that the app is being signed with the appropriate cert.

• My Bot's using a build scheme which is set to use my Ad-Hoc build configuration when archiving.
• My Ad-Hoc build configuration is a duplicate of my Release configuration except...
• The Code Signing identity is explicitly set to the distribution certificate for this application's account.

When I unzip the .ipa and then run codesign -d -vvvv /path/to/The.app, it confirms that the app was signed using the appropriate distribution certificate. I'm also able to use Craig Hockenberry's super-useful quicklook plugin to confirm that the embedded.mobileprovision is the appropriate Ad-Hoc provisioning profile.

The super-weird/frustrating part - if I download the .xcarchive the Bot has created and then sign it by double-clicking, then going through the traditional Distribute... button within the organizer, it uploads to TestFlight without a hitch.

I ran the same codesign check against the version that uploaded successfully, and with the exception of the CDHash and the date the .ipa was created, the results are identical.

Apple's documentation on code signing (scroll down to "Code Directory Hash") seems to indicate the mismatched hashes might mean something's gone wrong:

Because the code directory changes whenever the program changes in a nontrivial way, this test can be used to unambiguously identify one specific version of a program.

Anybody have the faintest idea what this might be? The archive I'm using to generate the .ipa that works is the downloaded straight from the same build products folder as the .ipa that doesn't work, so if my understanding of that documentation is correct, the hashes should be identical. Or am I misunderstanding that documentation and something else has gone wrong?

Update 12/30: One other thing I realized after a friend suggested trying it: The build product coming directly from the Xcode Bot installs directly on my phone (which is on the Provisioning Profile in question) through the Xcode Organizer without issue. Per their request, I've emailed the builds to TestFlight and they're seeing if there's any problem they can find on their end.

Update 2, 12/30: I'll note that this script from Matt Vlasach does work, but it actually re-signs the app from the Archive with a cert and provisioning profile - in theory, one shouldn't need to add this step if the cert and provisioning profile are the same as the ones specified in your build scheme, one should just be able to upload the .ipa build product directly. Matt doesn't go into details about why he added this step in his post - anyone with any thoughts on that?

Update 3, 1/2: The mystery deepens: If I take the build product directly from the Xcode Bot and upload it using TestFlight's desktop app, it uploads fine, installs on my phone (which is on the provisioning profile) fine, and opens and works just fine after it's installed. I've sent TestFlight's support team a bunch of logs on this per their request, they're going to take a look at wtfbbq is going on and I'll report back when I hear back from them.

Answer 1

Woo!

On Jan 24, 2014 at 04:39PM PST TestFlight Support wrote:

Hi Ellen,

Our team deployed a fix for this issue.

Please let us know if you experience any trouble.

I confirmed this morning that my builds which would previously get rejected on a get-task-allow issue are now uploading happily. If you are still having issues and you've tried all the above steps, I'd strongly recommend reaching out to TestFlight support directly, they're very helpful.

Answer 2

I recently got this issue and was building over the commandline. I realised that the xcodebuild command will pick provisioning profiles and signatures willynilly. Then if you signed the compiled folder with xcrun and PackageApplication it may sign it with a different sig or provisioning profile.

To fix it, specify the signature and provisioning profile which xcodebuild should use.

This is what it was previously, excluding the subsequent call to xcrun to sign and package the app. xcodebuild -sdk iphoneos -configuration Release

This is what was required xcodebuild -sdk iphoneos -configuration Release CODE_SIGN_IDENTITY= PROVISIONING_PROFILE=

Without it you can get anything from signing identity not found to mismatched signatures if it finds some other certificate entirely.