76

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.

Craig Otis
  • 31,257
  • 32
  • 136
  • 234
  • 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. – UKDataGeek Jan 08 '17 at 18:20

6 Answers6

140

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

Craig Otis
  • 31,257
  • 32
  • 136
  • 234
  • 39
    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. – Craig Otis Jul 01 '13 at 00:40
  • 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. – Thomas Tempelmann Sep 01 '13 at 07:31
  • 1
    @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. – Craig Otis Oct 07 '13 at 15:36
  • Thx for posting this. I was just beginning to pull my hairs out over this (we have a makefile with manually coded 'codesign' call). – Terminality Oct 10 '13 at 14:29
  • 3
    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. – Rob McBroom Oct 16 '13 at 13:29
  • @RobMcBroom Strange - I hadn't guessed that codesign behavior would be determined by the system, rather than the build tools. Good to know. – Craig Otis Oct 16 '13 at 16:39
  • 2
    Craig Hockenberry (link in answers below) explains why using deep is wrong – Paul Bruneau Nov 17 '13 at 20:05
  • @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? – Craig Otis Nov 17 '13 at 20:49
  • Set `OTHER_CODE_SIGN_FLAGS` to `--deep` in the projects build settings worked for me. – Linus Oleander May 05 '17 at 10:41
68

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

rougeExciter
  • 7,435
  • 2
  • 21
  • 17
  • 3
    helped me. I guess this means that you are somehow vouching for all the imported libraries that you use. – Tom Andersen Oct 15 '13 at 21:16
  • 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. – Craig Otis Oct 23 '13 at 14:49
  • 3
    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." – Elise van Looij Mar 02 '15 at 10:41
13

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.

andrei
  • 1,353
  • 15
  • 24
  • 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. – Kevin Jan 16 '17 at 11:40
  • This solved my problem too. The only thing left to do is remove the `Resource` folder from application bundle and restart Xcode.app. – sensation Feb 17 '17 at 18:55
  • 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. – Andy Weinstein May 16 '17 at 08:02
  • 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. – David Brown Oct 18 '17 at 15:11
  • 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) – Albert Renshaw Feb 17 '18 at 10:38
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.

Maury Markowitz
  • 9,082
  • 11
  • 46
  • 98
  • 1
    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. – Bhavsang Jam Dec 07 '17 at 07:15
2

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

GreenAsJade
  • 14,459
  • 11
  • 63
  • 98
Thomas Ayoub
  • 29,063
  • 15
  • 95
  • 142
  • 1
    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.) – Craig Otis Jun 26 '13 at 11:55
0

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.

UKDataGeek
  • 6,338
  • 9
  • 46
  • 63