Xcode 4.3: Codesign operation failed (Check that t

Question

After installing Xcode 4.3 I can't validate and distribute application using Organizer. While building, signing and validating in Xcode is OK, the validation in Organizer fails with the message in the title of this question.

First, Xcode 4.3 can download provisioning profiles automatically (there's an option in Organizer), but it downloads only development profiles and ignores distribution profiles as if there are none. OK, I downloaded and installed it manually and it appears in Organizer. Then I set proper Code Signing Identity both for project and for target and use Distribution profile that matches Distribution certificate in my keychain. Then I do Archive (build-sign-verify) and no errors, in the log I see green checkmarks for CodeSign and for Verify steps. Looks good and the archive appears in Organizer.

And that's where all goes wrong, I just select Validate, choose the new version I just prepared in iTunes Connect, choose correct code signing identity, same as was used for Archiving (actually, there are no other choices in my case), it asks for iTunes login/password as usual, and then says

Codesign operation failed

Check that the identity you selected is valid

Ahhh!!! Why!? It had no problems while archiving it, then same code signing doesn't work when trying to submit to AppStore. Well, not even submit, but validate before actually sending it. So this issue is local to my machine. The very same signing and validation that is successful during build, fails in Organizer...

I tried everything, re-installed Xcode, removed/revoked and re-issued all certificates, removed duplicated private and public keys from keychain, put all certificates in one "login" keychain, issued new profiles, installed Application Loader 2.5.1, and so on... still no luck.

Could it be that I have some left-over from previous Xcode installs? Or that I have to update some tools to make Organizer work properly?

Meanwhile, if anyone knows another way to upload binary to AppStore, please share. I couldn't figure out how to do that using Application Loader, when it asks me to choose a bundle to upload, all I have is xcode archive created by Xcode in Archive step. How do I get my hands on iap or whatever file the Application Loader wants from me?

Answer 1

Just confirming that the problem was indeed nested folders with the same name in my app.

In my particular case this was the issue:

• problem: images/packs/1/1/img.png
• solution: images/packs/pack_1/1/img.png

Smooth sailing after that. This happened in Xcode 4.3.3

Answer 2

As @radven and @tomek-cejner mentioned sometimes some extra directories could cause problems. Maybe if named improperly? for me the offenders were different.

Gruntfile.js, karma-e2e.conf.js, karma.conf.js, and the entire node_modules directory.

see: How to build IPA for distribution with TestFlight with XCode 5?

Answer 3

I had same problem as you do, and radven response inspired me:

did you see that ATResources directory contains nothing more than just copy of its parent?

ADDTHIS.db
en.lproj/*
images/*
ATResources/ADDTHIS.db
ATResources/en.lproj/*
ATResources/images/*

As a quick-and-dirty fix I removed the redundant subdirectory. Application builds and seems to work fine, and Xcode is able to sign.

Let me know if I missed any consequence of this fix?

Answer 4

found the solution, it really works for me. hope this will help you guys.

if the issue is because of Addthis, try following

noted that the inside ATResources.bundle you have a folder named ATResources.

ATResources contains exactly the copy items (ADDTHIS.db,en.lproj,images) which is present in ATResources.bundle. so we can simply delete the ATResources folder from ATResources.bundle.

for deleting,, select the files from ATResources.bundle and right click , show in finder -> and remove ATResources folder.

the major issue is because subdirectory in your bundle that has the same name as its parent directory.

:)

Answer 5

Techi50 alluded to this but to be clear - under Xcode 4.3.5 there is a serious bug where code signing will fail if you have subdirectories with the same name as the parent directory. In the Sencha Touch 2 SDK tree, for example, there is

/sdk/src/device/device

argh... hours of trying to code sign with no luck... rename to:

/sdk/src/device/device_epic_fail

(since I don't need those libraries anyway)

and I can code sign.

And one big bug hunt is over. Apple... fix please...

Answer 6

I've determined another cause of this error, which occurred for me in Xcode 4.6.2 (4H1003). I had a subproject building an executable. This executable is a helper tool which is copied into my app's bundle when it builds.

The app has a min deployment target of OS X 10.7 and builds for 64-bit Intel as a result. The helper tool, however, was set to a deployment target of 10.6, and was building for 32-bit/64-bit Intel.

Changing the helper tool to also build for 10.7 and 64-bit Intel only fixed the error. I can reliably recreate the error by changing the helper tool back to 32-bit/64-bit Intel; this is not a 'erm, zap your PRAM' fix.