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

XcodeMacosDropboxCode SigningMac App-Store

Xcode Problem Overview


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.

Xcode Solutions


Solution 1 - Xcode

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.)

Solution 2 - Xcode

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.

Specifying Deep Signing of Embedded Frameworks

Solution 3 - Xcode

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.

Solution 4 - Xcode

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.

Solution 5 - Xcode

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.

Solution 6 - Xcode

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.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionCraig OtisView Question on Stackoverflow
Solution 1 - XcodeCraig OtisView Answer on Stackoverflow
Solution 2 - XcoderougeExciterView Answer on Stackoverflow
Solution 3 - XcodeandreiView Answer on Stackoverflow
Solution 4 - XcodeMaury MarkowitzView Answer on Stackoverflow
Solution 5 - XcodeThomas AyoubView Answer on Stackoverflow
Solution 6 - XcodeUKDataGeekView Answer on Stackoverflow