iOS开发之打包上传到App Store——（一）各种证书的理解

内容参考自：苹果所有常用证书，appID,Provisioning Profiles配置说明及制作图文教程 

    理解Certificate、App Id、Identifiers 和 Provisioning Profile

在我们平常的开发过程中，可以使用模拟器进行调试，也可以直接使用真机测试，真机测试的话，证书的申请也是相对容易的多，但是当我们要实际打包发布程序到App Store时，那个证书真叫一个头疼。

首先，我们打开https://developer.apple.com/account/ios/profile/profileList.action，看下左边：

可以看到有这么几个选项。其中，Devices指的是团队（公司账号是可以以Team的形式添加多个成员的）中的设备，每个开发者账号（不论公司还是个人）可以关联100台设备，可以通过在苹果开发者控制台中添加，也可以通过Xcode直接添加设备。

然后，我们今天的重点目标是各类的证书啊、App ID啊还有Provisioning Profile啥的，所以重点理解一下这几个。

Certificate（证书）

证书指的是由苹果颁发（先交钱后发货的说）给你的证明你有权利进行iOS开发（不买证书你就只能用模拟器的说）并且可以将你开发的应用上传到App Store（么有证书估计只能自己做越狱开发）的一个凭证，表示你是一个开发者，就跟护照啊、身份证啊啥的一样。一个开发者账号只有一套，这个套装里呢包含两个证书，一个是Development证书，也就是所谓的开发证书，凭借这个证书你可以进行开发和真机调试（么有这个就只能用模拟器啦）；另一个是Distribution证书，也叫Production证书，即所谓的分发证书或者说生产证书。其中呢，Development证书可以制作多个副本分发到多台设备，但是Distribution证书只能有一个，不能制作副本分发到多台电脑。

下面大致介绍一下证书的种类以及分别包含的子分类啥的：

• Development
  • App Development (1年)：用来开发和真机调试应用程序。
  • Push Development (1年)：用来调试Apple Push Notification
• Production

  • In-House and Ad Hoc (3年)：用来发布In-House和AdHoc的应用程序。

  •  

        App Store ：用来发布提交App Store的应用程序。
  • MDM CSR
  • Push Production (1年)：用来在发布版本中使用Apple Push Notification。
  • Pass Type ID Certificate
  • Website Push ID Certificate
  需要注意的是：

在我们申请添加一个Certificate之前，需要先申请一个Certificate Signing Request（CSR）文件，这个过程呢，实际上是生成了一对公钥和私钥，保存在我们电脑上的钥匙串中。代码的签名也就是使用这种基于非对称密钥的加密方式，用私钥进行签名，用公钥进行验证。如下图：

我们的钥匙串中存储着相关的公钥和私钥，而证书里则包含了公钥。我们只能使用私钥来进行签名，如果不小心把私钥弄丢了，那么就表示这个证书基本上已经被咔嚓了，不要怕不要慌，你只是不能签名了而已，解决的办法就是revoke掉已经咔嚓了的证书，再重新申请一个，不过由此带来的麻烦可也是不少，所以可见备份的重要性啊，在申请完证书的时候，最好导出并且保存好你的私钥。这么做的另一个好处是当你需要跟其他人共享证书时（尤其是手头儿银子不多的个人开发者），只需要把私钥发给他人就好。当你用自己的私钥对代码进行签名后，苹果就可以用证书中的公钥来进行验证，确保真的是你对代码进行签名了，一来防止冒名顶替，二来确保代码的完整性。

App ID

App ID的主要用途是标识一个或者一组App，App ID应该是和Xcode中的Bundle ID是一致的或者说，可以匹配的。App ID有以下两种：

• Explicit App ID：唯一的App ID，这种类型的App ID只能用来标识一个应用，例如，com.aiscot.whatever，用来标识Bundle ID为com.aiscot.whatever的应用程序，其他的不行。
• Wildcard App ID：通配符App ID，这种类型的App ID用来标识一组应用程序，例如，com.aiscot.*可以用来标识Bundle ID为com.aiscot.whatever1和com.aiscot.biteme1等所有Bundle ID以com.aiscot开头的应用程序

每次创建一个新的App ID，我们可以设置该App ID所使用的App Services，比如有的使用Game Center，有的不使用，需要注意的是如果你要使用推送服务，那么你要新建的这个新的App ID必须是Explicit类型的App ID，这样儿，苹果的Apns才能识别到唯一的一个应用从而进行推送提醒，而不会出现所谓“一呼百应”的现象，下面是目前的一些可选服务和相对应的配置要求：

配置的时候，一定仔细瞅瞅哈，搞错了不要打我~\(≧▽≦)/~啦啦啦

Identifiers

Identifiers是标识符的意思，相当于身份证吧，用于创建以下三个：

App IDs

Pass Type IDs

Website Push IDs

其中，App ID是应用的唯一标识符，每个应用的App ID是不一样的。

Provisioning Profile

Provisioning Profile是配置文件，一个Provisioning Profile文件包含了刚刚我们上面讲的所有的内容：证书、App ID、设备。

试想一下，如果我们要打包或者在真机上运行一个应用程序，我们首先需要证书来进行签名，用来标识这个应用程序是合法的、安全的、完整的等等；然后需要指明它的App ID，并且验证Bundle ID是否与其一致；再次，如果是真机调试，需要确认这台设备能否用来运行程序。而Provisioning Profile就把这些信息全部打包在一起，方便我们在调试和发布程序打包时使用，这样我们只要在不同的情况下选择不同的profile文件就可以了。而且这个Provisioning Profile文件会在打包时嵌入.ipa的包里。

例如，如下图所示，一个用于Development的Provisioning Profile中包含了该Provisioning Profile对应的App ID，可使用的证书和设备。这意味着使用这个Provisioning Profile打包程序必须拥有相应的证书，并且是将App ID对应的程序运行到Devices中包含的设备上去。

如上所述，在一台设备上运行应用程序的过程如下：

与证书一样，Provisioning Profile也分为Development和Distribution两种：


（注：前面提到不同账户类型所能创建的证书种类不同，显然Profile文件的种类是和你所能创建的证书种类相关的）


Development (1年)
Distribution (1年)
In House
Ad Hoc
App Store
In House 与Ad Hoc的不同之处在于：In House没有设备数量限制，而Ad Hoc是用来测试用的，Ad Hoc的包只能运行在该账户内已登记的可用设备上，显然是有最多100个设备的数量限制。所以这两种Provisioning Profile文件的区别就在于其中的设备限制不一样而已，而他们所使用的Certificate是相同的。