遵循以下几条原则，不再纠结Xcode代码签名问题

本文由sandy翻译自JARED SINCLAIR的博客
原文：Follow These Guidelines and Never Struggle with Xcode Code Signing Again

多亏了下面的这些习惯，这一年里我再也没有为Xcode的Code Signing问题纠结过。这些习惯有的看起来很大材小用，而且它们大都比用Xcode里的内置支持功能更“复杂”。但那又怎样！去他妈的胡说八道！做自己的事情，回去该干嘛干嘛！

1.千万不要使用Xcode内置的Code Signing助手工具。尤其不要点击那个所谓的Fix Issuue按钮。那不仅会让你触及很多没用的文件（iOS Team Provisioning Profile…），而且还会导致你陷入配置文件的怪圈。

2.千万不要使用通配符App ID（wildcard app identifiers）。尤其当你在多个团队，而且每个团队又有多个通配符App ID的时候就会很麻烦。花一点时间登录到开发者中心，为你的每个app生成一个特有的bundle ID。不使用通配符App ID，会大大减少Code Signing道路上的陷阱。如果你有使用通配符的项目，马上删除它。新版Xcode使这些变的比之前更难。Let me Google that for you.

3.使用build code sign 和shared schemes。在“Manage Schemes…”面板勾选Shared让这一切变的轻松。一个是开发环境，一个用于App Store的releases版本。如果需要，也可以考虑增加一个用于beta版本。在编辑窗口为每一个scheme选择合适的编译配置。如果你选择Xcode提供的默认的编译配置，那么的你的开发方案会是debug模式，你的发布方案会是release模式。

4. 使用明确的code-signing identities和自动配置选择。因为你现在使用了share schemes连接到指定的构建配置，所以你可以把你的Xcode项目设置的更具帮助性。对于你工程的Code Signing Identity 和Provisioning Profile设置需要distribution证书(Ad Hoc, Enterprise, or App Store distributions)。如果你懒的话，你也可以使用自动的iOS Distribution。可能我有太多的teams，让我不信任xcode能做的那么准确。我建议使用iOS开发自动设置您的调试版本，这样有益于其他的开发者合作。我发现使用以上的signing identities设置，我能为所有的构建设置使用自动provisioning profile。

5.在target级设置上重复项目级的设置。另一个常见问题就是代码签名和配置文件选择的项目级别设定与target级别设定不匹配。除非你认为你不会犯这个错误（我之前也认为我不会，但现在我知道怎样才更好）。手动将代码签名和Provisioning profile设置为project和 target级别的，并定期检查以确保它们保持一致。

6.删除Keychain Access中过期的证书。Keychain Access让它变的非常简单。大多数证书(Ad Hoc, APN, and App Store)的有效期是365天，一些企业证书可能会延长至三年。在你创建新的分发证书和 APN证书的时候，设置日期闹钟来提醒你去及时更新，以防止证书过期之后你的APN 服务突然发怒，警告你代码错误。

7.确保Keychain Access里有所有需要的证书。在每个团队里你至少需要两个证书：1）一个允许你在设备上安装app的开发者证书。2) 一个分发证书允许你提交程序到 App Store。你也许会需要两个额外的证书用于推送通知(一个用于开发、一个用于生产)。开发和分发证书适用于你团队里的所有程序。APN证书是特定于每个应用的。确保你有这些证书的私钥，存储你的证书并导到安全便捷的地方，以防万一你的高级工程师们因为一些要命的蠢蛋都瘫痪掉的时候，你团队里的每个人都可以传送到APP Store。

8.安装新的文件或证书后无论如何都要重启你的Xcode。缓存过期的证书特别容易出现缓存错误。