iOS app provisioning is notorious for being a convoluted process. In Xcode 6, Apple added features to automatically handle most of this for you. However, a lot of Xcode's "magic" is fragile, and once it stops working, you are left in a broken state with no understanding of how you got there.

One common example is using the same Apple ID as part of multiple developer programs. If you have your own personal developer program, and then use the same account to join your employer or client's developer program, you will wind up with two separate code signing identities that have the same name. When Xcode tries to automatically choose the right one (Automatic -> iOS Developer), it apparently can't differentiate between them, and if the first one it tries fails, it gives up. This leads to many people manually setting their code signing identity for different projects, which means you wind up modifying the pbxproj file in version control and have to keep reverting or changing it every time someone else makes a commit!

Multiple Keychains

Most developers know about the login and System keychains, and all of their signing certificates go into login. But you can also create new keychains with any name you like, and using the --keychain code signing flag, you can tell Xcode which keychain to look in when it builds a target.

Step 1: Make a New Keychain

Open up Keychain Access and click File->New Keychain. Call it something appropriate for the team, and save it somewhere safe (the default is good, ~/Library/Keychains. You can put in a password if you want, but it seems reasonable to me to leave it blank also, since you can only access it once you're logged in, and you're not really creating it for security measures.

• If you don't enter a password (or enter one that's too weak), Keychain Access will complain at you — just click "OK" again and it will let you through the second time.
• If you do enter a password, I recommend right-clicking the keychain after you create it, going to 'Change Settings for Keychain "YourKeychain"…', and modifying or unselecting both boxes, so that Xcode doesn't prompt you to enter the password every time you build.

Step 2: Move Your Certificates to the New Keychain

Now you should move the appropriate certificate(s) to the new keychain. Say you've made a keychain for your employer's developer account certificates; just drag the certificates associated with that account, and drop them onto the new keychain.

If you're using cert, you can create new certificates directly into custom keychains like this:

cert create -u username@example.com -b YourTeamID -k ~/Library/Keychains/YourKeychain.keychain

Step 3: Set Code Signing Flags

The final step is to open any projects that use these certificates, open the xcodeproj file, go to Build Settings and, under that, Code Signing. Then add this line to the Other Code Signing Flags row:

--keychain YourKeychain.keychain

If you're working on a project with other developers, you probably want to coordinate on what to call your keychains. In my experience, most developers will welcome this because they are also tired of changing which code signing identity to use. However, if some don't want to use a separate keychain, they can leave their certificates wherever they like — Xcode will search through all keychains after looking in the specified keychain first.

Conclusion

This is a pretty easy workaround for a problem that I've seen for years. Hopefully Apple will solve this issue in Xcode one day, but until then at least this can serve as a quick keychain tutorial.