自动管理代码签名
简介：通过配置Xcode环境来自动管理描述文件（profiles）、app IDs（Bundle Identifier）和证书（certificates）。
当我们选中Automatically manage signing(这里简称AMS)选框，并且选择对应Team时，Xcode就会帮我们自动生成对应的描述文件、app id和证书文件（完全不需要我们自己手动去创建这些证书）。
作用：在真机调试的时候，如果我们有新的设备，不需要我们到苹果开发者网站去添加新设备的UDID和更新对应的描述文件，Xcode会自动帮我们创建和更新这些内容，这就是它的方便之处。
自动配置开发证书过程
出现错误：
存 在：Xcode会在本机钥匙串寻找team对应的开发证书,如果本地钥匙串存在该证书则加载使用。
不存在：则从开发者中心寻找本机对应的开发证书,如果开发者中心没有则自动生成一个并下载到钥匙串使用;如果AMS已为这台电脑生成过开发证书,则提示如下图中的信息。
出现上述【自动配置证书错误】解决方法：
MethodOne：前往开发者中心证书管理页面（上图）下载本机的证书导入本机钥匙串。
MethodTwo：直接选择revoke，但revoke会把开发者中心对应本机的证书重新生成覆盖掉，这样可以解决问题，但是会有一个隐患如果profile中存在被覆盖的本机证书对应的profile，且只有这一个证书时，该profile会因不含发布证书而变无效。这个很重要，具体会在文后关于Provisioning展开讨论。
>打包上传到AppStore的背后
选择save for app store deployment或者save for Ad Hoc deployment或者upload to App Store发生了什么?
Xcode自动加载发布证书。
若存在Xcode会去本机钥匙串寻找苹果账号对应的发布证书，若不存在则从开发者中心寻找发布证书，如果开发者中心不存在则新生成一个，并下载到本机钥匙串，并加载。
下一步，如果存在出现下面的错误。
解决方案：
方法一：可选择去开发者中心下载（前提是那个发布证书是本机生成的，如果是其他人的机器生成的，下载也没用，因为没有私钥，私钥要从别人那里导出，这种情况只能去那个人的电脑钥匙串导出p12文件，关于证书和私钥的详细说明请移步后文）
方法二：选择reset，然后try again就可以了。但reset慎重，reset还是有可能会导致Provisioning无效的情况，而且别人的证书不再有效，以后进行和发布证书相关的操作，他就会面临和你现在相同的问题，出现恶性循环。
Xcode正确加载发布证书之后，会根据App id去profile下载Provisioning了，有则下载，无则自动创建一个(绑定当前app id和发布证书)并下载，但是，在这一步并不会检查Provisioning有无效，详细请看文后关于Provisioning话题。
从开发者中心下载其他电脑生成的证书，然后导入到本机中。会在【钥匙串】中发现证书是不包含秘钥的。自然使用不了，结果也的确这样，提示revoke。
由以上也可证明一点，Xcode帮我们申请的证书（开发、测试证书）都跟电脑绑定的。如果我们想让其他电脑也能用这台电脑的证书，也只有采用老方法，导出p12文件，这样秘钥也导过去了。就可以正常使用。
关于Provisioning Profiles
APP IDs、证书、Provisioning Profiles 三者的联系
我们知道最终打包进去ipa的是Provisioning Profiles描述文件，而Provisioning Profiles文件则包含了开发者的开发或者发布证书，以及APP IDs（可以理解为bundle identifier）。做了这么多事情，也是为了得到正确的Provisioning从而成功的打包或者上传我们的app。如果证书或者APP ID出错了，最后的Provisioning自然也是错的，签名过程自然就会出现问题。
revoke和reset导致的Provisioning Profiles错误
经过观察，Provisioning 无效会有两种情况，要么过期了，要么不含有证书了。这样在开发者中心Provisioning Profiles页面就会显示invalid无效。Xcode加载Provisioning的时候并不会验证Provisioning是否有效。也就是说，显示invalid的Provisioning，Xcode也会加载回来，且不会提示错误。这样就有可能会有问题。
举个例子
假如开发者中心一片空白，当在mac A打包上传时，开发者中心为该开发者创建了关联mac A的开发证书和发布证书，并且自动生成了app id和Provisioning，此时的Provisioning就是关联了发布证书的，且就一个证书，例如下图。
mac A就成功打包上传了，一切都很顺利。然而过了一段日子，需要在mac B打包上传，因为mac B是没有发布证书的，自然会提示reset，如果mac B进行了reset，那么Xcode自动为mac B创建的发布证书就会替代mac A之前的证书了，原证书没了，Provisioning的Certificates就会变成0 total，从而变成invalid，无效了。但是mac B继续打包上传，在Xcode从开发者信息中寻找Provisioning的时候，因为含有同样的APP ID的Provisioning存在了，Xcode不会再为开发者重新创建一个Provisioning，而是直接加载！！而加载这个恰好就是无效的！Xcode也不会提示任何错误。那么之后就GG了。
App IDs
在开发者中心APP IDs有个Wildcard App ID的概念，大概的意思就是使用通配符的App ID可以通配一系列符合的APP ID；比如定义了一个Wildcard App ID：com.，那么这个App ID就可以统配所以以com.开头的bundle identifier，xcode不会再为其生成相同名字的App ID。同理，在第一次使用com. App ID时，Xcode会为其新建Provisioning，Provisioning对应的App ID就是com.，以后再有新项目bundle identifier以com.开头，Xcode不会再为其创建Provisioning，也就是公用com. APP ID的应用共用一个Provisioning。通配符有其好处，也有不好的地方，感兴趣大家可以到Apple官方看看相关内容。
Xcode自动为项目创建APP ID的过程
说了这么多Wildcard App ID的内容，也是为了说一下，Xcode自动为项目创建APP ID的过程。如果开发者中心有与bundle identifier相同的APP ID则不创建，如果没有，会看有没有适合的Wildcard App ID，如果有也不创建，如果没有才最后创建与bundle identifier相同ID的App ID。
