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

多亏了下面的这些习惯，这一年里我再也没有为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 服务突然发怒，警告你代码错误。