XCode8 signing

Here's my understanding of the current situation:

— Normally, choose automatic signing. (In some cases, you might choose manual signing because this is an older project, and you already have a non-standard workflow for signing it that you don't want to revamp.)

— With automatic signing, your built app is signed with your developer identity, which identifies you personally and is not a secure mechanism (because it's not independently verifiable by a third party). However, it's still useful, because at least the code is signed. If you hand out the built app to a tester, it's somewhat protected against accidental corruption in transit. AFAICT, you get this signing for both debug and release builds.

— When you want to distribute your app — whether it's a beta version or a final release — you need to go through the Archive step. That does a final rebuild in release mode. Then, you select the archive and use Export to pull out the actual distributable. At that point, you're asked how to (re-)sign the app. For non-app-store distribution, you should choose the "developer ID" option. That will use your developer ID identity (which is not the same as your developer identity, sheesh!) Your developer ID is verifiable through Apple, so it is a secure means of code signing for distribution.

Ideally:

— With your app signed only by a developer identity, which is not secure, you should only share build products with people "in your organization". This is normally going to be a debug configuration, but you can make it a release configuration by changing the build scheme (run step).

— To share your app with people "outside your organization", you should archive and export the build with your developer ID identity. This is normally going to be a release configuration, but you can make it a debug configuration by changing the build scheme (archive step).

If you want to do anything else, you're going to have to choose manual signing — in particular, if you really want no signing. However, I can't see any advantage of not signing the distributed app. If nothing else, signing it with your developer ID identity allows receipients to run it without worrying about their GateKeeper settings.

Thanks Quincey, because I'm now totally lost with this signing process.

So, excuse for the very long post :

It works fine in XCode 7, on 2 different Mac, but when I transfered the App to XCode8 on another Mac, I never succeeded to compile : I get codeSign Error at the end.

I tried to do as you explain :

- Automatically sign

- I'm requested to give a Team which I did

- No provisionning required

- Signing certificate is Mac Developer.

Here I have a first question : when I look at signing certificates in XCode Preferences, I have several MacOS Development certificates.

- 2 are valid and named MacBookPro de Claude (me): created today when I selecteted + at the bottom of signing certificates window.

- 3 are untitled, either revoked or not in keyChain.

I also have several Developer ID Application

Could this be the cause of the problem ? Should I delete all but one ? How to know which to keep ?

If I delete on MacBookPro, I understand it will be deleted on my account. Is there a risk to "damage" compilation on other machines ?

When I compile, I get an error : CodeSign Error:

CodeSign /Users/XXXXXXme/Library/Developer/Xcode/DerivedData/The_AppName-hknqslligudgdhdhpwvfhpbtcilk/Build/Products/Debug/The\ AppName.app

cd "/Users/XXXXXXme/Developpements XCode/The AppName/zzzzzzz »

export CODESIGN_ALLOCATE=/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate

Signing Identity: "Mac Developer: my Name (ZZZZZZZ) »

/usr/bin/codesign --force --sign ZZZZZZZZZZZZZZZZZZZZZ --timestamp=none /Users/XXXXXXme/Library/Developer/Xcode/DerivedData/The_AppName-UUUUUUUUUUUUUUUUUUUUUUUU/Build/Products/Debug/The\ AppName.app

/Users/XXXXXXme/Library/Developer/Xcode/DerivedData/The_AppName-UUUUUUUUUUUUUUUUUUUUUUU/Build/Products/Debug/The AppName.app: resource fork, Finder information, or similar detritus not allowed

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

---------

I have tried to compile another app, and it compiles fine

So a second question: could this be caused by remaining derived data when I converted from Swift2 to Swift 3 ?

when I first converted the source (signing was set on "No signing" at that time), I got the following message :

Check dependencies

The AppName has conflicting provisioning settings. The AppName is automatically signed for development, but a conflicting code signing identity Developer ID Application has been manually specified. Set the code signing identity value to "Mac Developer" in the build settings editor, or switch to manual signing in the project editor.

-----------

If you want to do anything else, you're going to have to choose manual signing

Yes, I would like to try this, but how can I set to no signing ? The option seem to have disappeared in XCode target setting (General Tab) : is it accessible elsewhere ?

Found it : have to change in Tagets / Build Settings, Project / Build Settings and Target / General !

Question 3 : in fact, signing is defined both in Targets and project Build Settings as well as in target/General: how do they relate to each other ?

>Question 3 : in fact, signing is defined both in Targets and project Build Settings as well as in target/General: how do they relate to each other ?

Target level settings override Project level. Use the former to segregate when using multiple targets as needed.

Best to make changes only at the Target level and leave Project level alone unless you know specifically what that change involves, etc.

It can get messy when you turn on automatic signing for an existing project. Automatic signing requires the build settings be set to something "neutral", otherwise it thinks you're trying to override the automatic signing. In your case, you got the exactly correct message telling you what to do: go to the build settings for your app target, and choose "Mac Developer", which is the first of 3 choices in the "Automatic" section of the popup menu for the setting. Also do this for any embedded framework targets.

Also, if you've added any custom phases to the build that invoke codesign explicitly, delete those build phases.

>> The AppName.app: resource fork, Finder information, or similar detritus not allowed

Is it possible that at some point you looked at the app bundle's package contents in the Finder? That might have added a .DS_Store file to one of the internal folders. If that's what it is, an Option+Clean Build Folder should solve it.

>> I have several MacOS Development certificates … Is there a risk to "damage" compilation on other machines ?

My experience is that trying to figure this out from what Xcode shows is frustrating and likely to be unsuccessful. Keep in mind that there are basically three classes of certificates:

1. Mac App Store, which is used for the final signing of an app distributed through MAS.

2. Developer ID, which is used for the final signing of an app distributed outside MAS.

Both #1 and #2 are certificates that a customer's Mac can verify with Apple servers when the customer installs the app. That means both must exist permanently.

3. Developer <you>, which is used for signing during Xcode development.

So, #1 is permanently associated your developer program account, and Xcode won't attempt to delete it.

#2 is also permanent, except that it's set to expire in 5 years. You only need — and only should have — one of these at a time, but Apple lets you create several (6, the last time this came up) at once, in case you lose the private keys for one. This kind of certificate cannot be revoked (except for major security violations), so you have to be careful to keep a backup of the private keys.

#3 can be thrown away at any time, and replaced by a new one. You can use different ones on different machines. It doesn't matter because it's not secure.

I would imagine Xcode might create a developer ID certificate for you (#2) if you don't have one, but other than that, the only certificates it should mess with are #3, and it doesn't really matter much what it does with those. Similarly, it shouldn't be necessary for you to do anything manually. If you do delete one manually, and Xcode had chosen to use it for development-time building, it'll presumably tell you something is wrong and offer to "Fix" it. At that point, it'd probably create yet another one.

Summary: Fix your explicit build settings to default values that Xcode expects, clean the build folder, and you should be good to go.

When I look at code signing Identity in tagets / Build Settings, I see either automatic (Mac Developer / mac Distribution / Developer ID:*) or Identities in KeyChain (notably Mac Developer : myName (a number) / Developer ID Application or Developer ID Installer: my name (other number).

Which should I choose ? Identity in KeyChain ?

Use the "automatic" (i.e. "generic") ones at the top.

The point of those is that they don't depend specifically on the keychain of the specific Mac user running Xcode. If you choose one of the specific ones from the list at the bottom, your project can't compile on some else's Mac. When you use the generic ones, behind the scenes Xcode fetches the one for the current login user.

Sorry, I first looked at the menu under Xcode 9, where the items on the popups have slightly different names from Xcode 8. Basically, there are 3 options: developer, MAS and Developer ID. On both Xcode 8 and Xcode 9, the correct one to use for automatic code signing is "Mac Developer".

On both Xcode 8 and 9, the correct one to use for exporting from an archive is MAS or Developer ID, depending on your intended method of distribution.

Hi bro tell me you have gsx