Since I upgraded to ‘El Capitan’ I can no longer sign my apps.
The command: codesign -f -s “MY_IDENTIFIER” APPLICATION_PATH
returns this error: xcrun: error: unable to exec Xcode native xcrun (Not a directory).
and: the codesign_allocate helper tool cannot be found or used
I installed very last Xcode and the command lines tools. I have searched this forum and the web but I don’t see any working solution…
Anybody else?
What about this link here: http://stackoverflow.com/questions/11977648/xcrun-error-failed-to-exec-real-xcrun-no-such-file-or-directory ?
This is not the error I get. Mine is ‘xcrun: error: unable to exec Xcode native xcrun (Not a directory)’ and not ‘xcrun: Error: failed to exec real xcrun. (No such file or directory)’… Anyway all that is from 2012, and OS 10.8 … not a single command listed in that page work for me. As I said I found nothing in the web about the error I get.
Sounded at least similar. Have you verified that xcrun is available on your machine? Something like “xcrun --find clang”
I rather buy Sam Rowlands App Wrapper and benefit from his constant attention to the vagaries of Apple as it pertains to code signature. I do not have time to waste with command line signature…
AppWrapper is using the codesign command under the hood.
I finally found the problem, the following line executed in the Terminal fixes the problem:
sudo xcode-select -switch /Applications/Xcode.app/Contents/Developer/
First time I need to run that command to make things work after updating Xcode and installing components… :-/ … weird…
App Wrapper makes available two code signing methods : --deep, and Ohanaware’s. If one does not work, the other will. And in case of need, Sam is never far away.
Once again, it is all a matter of how much time one has to spend keeping current with Apple whims…
I use my own Xojo build script, that script does everything, editing plist, changing privileges, deleting unwanted stuff, adding custom files, signing, creating package for the app store… etc… I am happy with just clicking on the ‘Build’ button and getting a build and a ready to upload package for the app store. Right now after a build I don’t have to do anything else… on the other hand I am in charge of maintaining my script.
Honestly, using the commandline or script is not very easy when you need codesigning with entitlements and etc…
Appwrapper is by fat the easiest, fastest and never fail approach. Imo every Xojo dev (for OSX) should have/use Appwrapper.
Indeed it is, if you want an app code signed, you have to use Apple’s Code sign tool… How you use it is quite a different matter.
Apple is phasing out the --deep option already (although they always considered it temporary in the first place).
Indeed, only about 7,000 miles 
These can be done from App Wrapper also (except the adding files part as this can be done via a Xojo build script). It also utilizes Xojo Build Scripts so you can Sandbox your debug apps and then send the app over to App Wrapper when building the application.
I totally respect that, if you ever change your mind or are curious I’m here (mostly).
Cyberspace has warped space 
sams in taiwan
now if I could drive there it’d be just a tiny bit further than driving across canada
Just one last thing if you’re handling this process yourself, you need to be aware of an issue with Xojo 2015r2.x and UTIs. Norman’s already said it will be solved in 2015r3, but in the mean time you should read the following article.
http://ohanaware.com/support/index.php?article=how-not-to-break-preview.html
it already is fixed in r3 (you could test that Sam - hint hint hint)
ha ha… I intend too later today… Have a whole bunch of things to do today.
Apple have now closed my bug report. Earlier on they were talking about enabling Preview to continue to open PDF files if a developer makes this mistake. Now they’ve decided that it’s the developers responsibility to ensure they don’t make this mistake.
I’m disappointed because it’s actually a fairly easy mistake to make and it shouldn’t break PDF functionality for the system; not to mention that it’s incredibly hard for an end user to figure out which application has caused this (hence why I created Preview Reset).
That we could accidentally steal that capability quite so easily is worrisome
It’s not just stealing it from Preview, it breaks PDF system wide, so Quicklook no longer works and apps that used to be able to open PDFs (via CGImage or NSImage) no longer work either. Fairly serious IMHO, I’ve received several e-mails from customers where they’ve spent hours on the phone with Apple tech support trying to figure this issue out.
Preview doesn’t specify any importable UTIs (and only a couple of exportable), instead their doc types use a key I’ve never seen before “LSIsAppleDefaultForType”. I can only presume it’s designed to allow other apps to take over, but at the very least if an application does, Preview should still be able to open PDFs (which it can’t once broken).