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