在iOS開發過程中，不可避免的要和證書打交道，真機除錯、App上架、打包給測試去測試等都需要搞證書。在此過程中我們會遇到很多的問題，但是如果掌握了真機除錯的原理和本質；遇到問題，我們就更容易定位問題之所在，從而迅速的解決問題。這篇文章不是一步步教給你證書，描述檔案的製作（其實製作步驟是非常簡單的），而是儘可能的講明白Member Center中的一些知識及原理。並且此文不涉及如何申請開發者賬號，以及App上架App Store的流程。
此篇文章的邏輯如下圖所示：
Certificates
什麼是證書
什麼是證書？證書就是：證明證書擁有者擁有證書上所說的能力。一個證書要涉及到頒發者，擁有者，證明擁有者擁有了什麼能力。例如，CET-4證書；頒發者：學校，擁有者：自己，證明的能力：英語達到四級水平。蘋果開發者證書也是一樣，頒發者：自己，擁有者：安裝證書的電腦；證明的能力：可以安裝或者打包某應用程式。開發者證書分為兩種型別：Development Certificate（開發證書）和Production Certificate（釋出證書）。
開發者證書能力來源
那麼當某臺電腦安裝開發者證書後，這臺電腦是如何擁有這種能力的呢？
蘋果在此運用了程式碼簽名技術。程式碼簽名驗證允許我們的作業系統來判斷是誰對App進行了簽名，在安裝了Xcode後，Xcode會在專案編譯期間使用你的程式碼簽名驗證，這個驗證由一個由Apple認證過的公鑰-私鑰對組成，私鑰儲存在你的鑰匙串中（Mac本地，在系統實用工具中），公鑰包含在證書（Certificates）中，證書在本地鑰匙串和開發者賬號中都有儲存，另外，還有一個我們可以叫做媒介證書的證書來確保我們的證書（Certificates）是經過授權而釋出的當安裝好Xcode時，媒介證書（Intermediate Certificate）就已經安裝到我們的鑰匙串中去了。通過在開發者賬號（Developer Account）和本地（Mac）都經過驗證的證書（Certificate）我們就可以利用合法的證書進行App的測試和釋出了。
證書在Xcode工程中所對應的位置
Identifiers
Identifiers中又分為App IDs、Pass Type IDs、Website Push IDs、iCloud Containers、App Groups、Merchant IDs、這裡主要講解App IDs。
App ID是什麼
App ID其實就是一個App的身份證，一個App的唯一標示。在Project中稱為Bundle ID。在Member Center、Project、iTunes Connect都是需要此ID去標示此App的唯一性。Bundle ID在不同環境下的表現關係。如（圖2-1）所示。
一個Bundle ID精確的標識了一個App。Bundle ID字串中只能包含字元（A-Z，a-z，0-9），連線符（-），點（.）而且此字串最好是reverse-DNS格式的。例如你公司的域名是Acme.com，你App的名字是Hello，那麼你可以用com.Acme.Hello作為你的Bundle ID。
Bundle ID的作用：
- 在Xcode工程中，Bundle ID儲存在Info.plist中，當你編譯工程的時候，他會把此檔案拷貝到你的app包中。
- 在iTunes Connect，用Bundle ID去標識App，在你第一次構建上傳之後，你就不能在改變或者刪除你的Bundle ID了。
- 在Member Center，你建立一個和Bundle ID相匹配的App ID。如果App ID是精準型別的，你就必須精確的去匹配你的Bundle ID，Bundle ID是大小寫敏感的。
在Member Center中新增App ID
在Member Center中新增App ID也是很簡單，選中App ID點選右上角的+號，App ID Description就是寫一下這個App ID的描述了。App ID Prefix：App ID的字首，這裡蘋果為了更精確的保證App ID的唯一性使用了開發者賬號的Team ID作為App ID的字首。App ID Suffix：App ID的字尾，這裡有兩種型別，一種是精準的，一種是通用的，我們在使用中大多數都是使用精準的，直接把我們的Bundle ID填進去就好。下面就是App包含的服務，這個根據自己業務所需的型別自己選擇就可以了，而我們用的最多的也就是Push Notifications推送服務。然後continue就可以了。
Devices
Device就是用來測試的裝置。在Member Center中新增device的步驟其實也很簡單了，主要就是要拿到device的UDID，這裡我們可以利用iTunes、iTools、Xcode這些工具都可以拿到裝置的UDID。需要注意的就是，每個開發者賬號，每年最多可以新增100臺除錯裝置，而且不能更改，想要更改就要等到下一年重新續費的時候才能更改除錯裝置了。在下面要講述的描述檔案中只有釋出到App Store和In House的時候這兩種型別的描述檔案的製作是不需要新增device的，而其他描述檔案的製作都是需要新增device的。具體使用情況，參考下面的【Provisioning Profiles】。
使用iTunes查詢UDID
使用Xcode查詢UDID
選擇Xcode工具條上的Window，然後選Devices選項。
Provisioning Profiles
描述檔案描述了可由哪臺電腦，把哪個App，安裝到哪臺手機上面。一個描述檔案的製作是需要上面的一些資訊的。所以蘋果在Member Center中把這個檔案的製作排在最後面是很合理的。描述檔案其實可以分為兩種型別，一種是帶有device資訊的；而另一種是不帶device資訊的。
帶device資訊的描述檔案
這種型別的描述檔案包括所有開發型別的描述檔案和釋出到Ad Hoc上面的描述檔案，因為做這些事情的時候，都有很明確的目的，這個App要安裝到哪臺裝置上面。
不帶device資訊的描述檔案
不帶device資訊的描述檔案只有釋出到App Store和In House兩種情況下才使用這個描述檔案，因為通過這兩個渠道釋出的App我們是不能確定將來那一臺裝置才會安裝，只讓也就不會帶有App的資訊。
描述檔案在Xcode中的位置
團隊開發證書的管理
在團隊開發的時候，最好是一個人去管理證書，當有其他人要用的時候，可直接匯出.p12證書供其他開發者使用。證書出了問題，我感覺還是相當麻煩的，而App ID在新增之後，基本上是不會改變的，除非要為App新增新的服務，這時候才要重新編輯App ID，所以App ID最好也是管理證書的人去管理App ID。新增裝置這一塊就很隨意了，所有的開發者都應該有權去管理新增裝置這一塊。描述檔案的製作這個要區分一下是開發型別的描述檔案，還是釋出型別的描述檔案。開發型別的描述檔案應該是團隊裡的每一個開發者都有權去管理的，實際上當開發型別的描述檔案出現問題的時候，開發者可以對此描述檔案重新編輯一下進行使用，這樣是不會影響其他開發者的，甚至你可以自己重新制作一個描述檔案也沒什麼問題。但是釋出型別的描述檔案，這個最好還是管理證書的那個人去管理這個描述檔案。打包釋出的時候如果這個描述檔案出現變化，還是很麻煩的，而且這個描述檔案對於團隊其他開發者來說也不是很常用，甚至是根本用不到這個描述檔案。以上這些就是我個人對於團隊開發證書管理的建議，當然也有不足之處，如你有好的建議，也歡迎你私密我，共同交流，共同進步。
舉例使用
上面幾段可能原理性的內容過多了一些，但是個人感覺掌握這些原理還是很有必要的。下面舉個例子，對應上面的原理，講一下實際的運用。
產品需求：我的一個App，包含推送功能，在開發狀態下已經測試完成所有功能，但是這時產品經理為了保證產品在上線後也萬無一失，就想測試一下上線後，推送的功能是否穩定。這時我們的App還沒有上線，那我們要怎樣才能去測試這樣的一個功能呢？
分析這個需求，要測試上線後推送功能，其實無非就是看上線後推送的證書會不會出現什麼問題。這時候我們就會想到Ad Hoc。因為釋出App除了App Store渠道之外，還可以選擇Ad Hoc。這時候我們就先選定用哪幾部手機進行測試，先新增到device中，然後開始製作描述檔案。點選右上角+號 -> 然後選擇Distribution中的Ad Hoc -> 點選continue -> 選擇你要測試的App的App ID -> 點選continue -> 選擇你釋出到App Store時候所用的證書 -> 點選continue -> 選擇你要安裝的測試裝置 -> 給此描述檔案起一個名字 -> 點選generate。這樣你就生成了一個釋出到Ad Hoc上面對應的描述檔案，用此描述檔案打包出來的App和釋出到App Store上面的App用的是同一個證書，所以在此情況下App的推送沒有什麼問題，基本可以推斷App上線之後應該也是沒有什麼問題的。
總結
對於蘋果開發者證書不是太瞭解的同學，證書問題可能是非常頭疼的一件事情。因為開發者賬號有三種型別，而在製作證書的時候，有開發證書，釋出證書以及一些附帶屬性的證書，以及新增App ID，Device，製作描述檔案，感覺就是很亂，搞了一堆的東西，最後也不知道這些東西到底都是幹什麼用的，運氣好的話，可能這樣瞎搞一通，App就能跑到真機上面了，但是也不排除，瞎搞一通，還是有各種問題。所以我們在學習知識的時候，還是要儘可能的去了解他的原理。關於開發者證書，我們還要根據實際需求自己去做一些判斷，來滿足實際的需求。這篇文章看起來可能有些亂，而且有些地方也沒有提到。一些不足之處，還請多多見諒，同時也歡迎你私密我，私下交流共同探討，共同進步。