Codesign of Dropbox API fails in Xcode 4.6.3: "code object is not signed at all"

Question

I have an OS X app that's distributed through the Mac App Store, and recently updated to Xcode 4.6.3.

When I run my regular build now, I receive:

Command /usr/bin/codesign failed with exit code 1:

/Users/Craig/Library/Developer/Xcode/DerivedData/Mac-dxcgahgplwpbjedqnembegifbowj/Build/Products/Debug/MyApp.app: code object is not signed at all
In subcomponent: /Users/Craig/Library/Developer/Xcode/DerivedData/Mac-dxcgahgplwpbjedqnembegifbowj/Build/Products/Debug/MyApp.app/Contents/Frameworks/DropboxOSX.framework
Command /usr/bin/codesign failed with exit code 1

I can't seem to discern any other changes in my project, so I can't tell if it's an issue related to the 4.6.3 update, or something else.

I have tried restarting Xcode, running a clean build, and cleaning the build folder.

Kurtis

This problem is still happening in XCode 8.2 When I deleted my tests I now get this error : The bundle “XXXX” couldn’t be loaded because its executable couldn’t be located. – Imaginal

Answer 1

I think I may have figured this one out. I've been running Xcode 4.6.3 on OS X Mavericks, under the impression that any build-specific tools were bundled in the Xcode application.

But, it seems codesign is in /usr/bin. Whether it's put there by one of the Xcode installers or comes with a vanilla system install, I'm not sure. But reading through the man page for codesign, I found this nifty option:

--deep  When signing a bundle, specifies that nested code content such as helpers, frameworks, and plug-ins, should be recursively signed
             in turn. Beware that all signing options you specify will apply, in turn, to such nested content.
             When verifying a bundle, specifies that any nested code content will be recursively verified as to its full content. By default,
             verification of nested content is limited to a shallow investigation that may not detect changes to the nested code.
             When displaying a signature, specifies that a list of directly nested code should be written to the display output. This lists only
             code directly nested within the subject; anything nested indirectly will require recursive application of the codesign command.

And then I found this post (https://alpha.app.net/isaiah/post/6774960) from two weeks ago (~June 2013), which mentions (albeit second-handedly):

@isaiah I asked a guy in the labs about it. He said codesign now requires embedded frameworks to be signed separately before code signing the app bundle as a whole.

Manually re-running the codesign command that Xcode normally runs, while adding the --deep flag to the end, signs the application properly.

I'm not yet sure exactly what ramifications this manual signing has, or whether I can tweak the Xcode build to add the --deep flag automatically, but this seems to be the underlying issue. (codesign no longer automatically deeply signs your app bundle.)

Kurtis

Yes - I was able to find the "Other Code Signing Flags" option in the Build Settings of my Xcode project, add --deep to it, and the build now performs successfully. We'll see if this goes through the Mac App Store. – Kurtis

I do not believe that codesign ever did a "deep" signing before. I use codesign all the time, in apps that contain 3rd party libs, and codesign only signs the primary executable (in Context/MacOS/), while the other lib files need separate codesign calls. – Bywaters

@ThomasTempelmann I don't know nearly enough about codesign to understand exactly what has changed. All I know is that between 10.8 and 10.9 (or perhaps Xcode 4 to Xcode 5, I upgraded both at the same time) the behavior did change, and this is what has been working for me to get my apps successfully submitted. – Kurtis

Thx for posting this. I was just beginning to pull my hairs out over this (we have a makefile with manually coded 'codesign' call). – Sealed

For the curious, I’ve been using Xcode 5 on 10.8 for quite a while, but only ran into this problem today when I tried to sign under 10.9. – Sedimentary

@RobMcBroom Strange - I hadn't guessed that codesign behavior would be determined by the system, rather than the build tools. Good to know. – Kurtis

Craig Hockenberry (link in answers below) explains why using deep is wrong – Rubble

@EthicalPaul I've read that article a few times - it is fantastic, and very informative. However! I have an .app that I just released through the Mac App Store, and I checked the Xcode archive for it. While the app passes the codesign --verify, it does fail the spctl. And, when building a PKG from the .xcarchive file and installing, the app does not launch. It crashes with: EXC_CRASH (Code Signature Invalid). But. This archive was submitted to the Mac App Store, and has been successfully released, and is launching fine on users' machines. So what's going on? – Kurtis

Set OTHER_CODE_SIGN_FLAGS to --deep in the projects build settings worked for me. – Glossectomy

Answer 2

As highlighted in other answers, there is a change to the way code signing works. If you've installed any of the Xcode 5 DP's then the new tools will be being used even if you are using Xcode 4.6.X.

All you need to do at this stage (in Xcode 4.6.X) is take the --deep flag suggested above and add it into your code signing flags (Target, Build Settings) see image below.

Lovable

helped me. I guess this means that you are somehow vouching for all the imported libraries that you use. – Impenitent

According to a comment to my answer above, it seems like this might actually be an issue specific to OS 10.9, and not to Xcode 5. – Kurtis

Apple TechNote 2206 states "While the --deep option can be applied to a signing operation, this is not recommended. We recommend that you sign code inside out in individual stages (as Xcode does automatically). Signing with --deep is for emergency repairs and temporary adjustments only." – Crotty

Answer 3

For me, this problem was caused after dragging a folder named "resources" in my project. After changing its name into anything else(like "resourcessss" for example), the error disappeared.

Normalie

This was my problem. Note also that the usual mac filesystem is case-insensitive so if you have a folder or file named, e.g. "Resources" or "RESOURCES" it will also cause this issue. – Consumerism

This solved my problem too. The only thing left to do is remove the Resource folder from application bundle and restart Xcode.app. – Joris

I had a few issues but this answer helped me along. I saw that I had both a blue folder named Resources and a yellow folder named Resources. I also saw that the file it was complaining about was only in one of those folders. I ended up deleting the blue one entirely (the reference, not the files, which were the same). I also renamed it to Res. Not entirely sure this was necessary (I did before deleting the blue folder), because I have another project that has a yellow folder named Resources and have no problems there. – Heaver

This worked for me as well. I wanted to add a keyword to this page. My problem was with nativescript. So not really x-code / pure ios dev. Hopefully this will help someone else as well. – Insignificance

For future readers, if you NEED to include a folder called Resources (like I did) all you have to do is, when adding to project, select Create Groups instead of Create Folder References and this error will not incur. (Just make sure your target memberships are still set for said files after) – Gillman

Answer 4

I had the same problem, but the answer was simple: the code signing identity on my app was set to "-", so simply setting that to "Don't Code Sign" fixed me up.

"-" seems to be the default setting when you carry out some set of actions, although I can't tell you what those are.

Arbitrator

This solution is good for run app on simulator but when we want to make ipa or archive at that time this solution will not work from my side. – Dupre

Answer 5

This might help somone:

I finally figured out the solution by trial and error. In my case I had a folder name that matched the “Product Name” variable under build settings. This also matched the entire project name! So I simply changed one field. I changed the “Build Settings” -> “Product Name” . The value of MySpecialApp was changed to My-SpecialApp. That was simply it! I then logged back into the Apple developer portal and created a new App ID and mobile provisioning profiles for development and distribution and the rest is history. My releases now work when deployed via the Ad Hoc distribution. A final note on this. This is definitely a bug that Apple should either alert the user that they have done something wrong and enable some sort of automated corrective action. - See more at: http://www.chrisdanielson.com/2012/08/29/codesign-ipa-and-the-code-object-is-not-signed-at-all-problem/#sthash.F0nF3BbC.dpuf

Heliograph

Thanks for the reply @VBB, but unfortunately the product name hasn't changed in the past couple years. (And I can't change it now.) – Kurtis

Answer 6

For me it was a corrupted Framework PaddleMAs which: 1. I removed from my Cocoapods File 2. Ran pod install 3. Restarted my Xcode

and it solved the problem. For some reason a corrupted framework will prevent it being signed unfortunately XCode doesn't show this error really clearly and give you a good fix suggestion. Have raised a bug with Apple to fix.

Imaginal