一個iOS應用最終能在使用者的裝置上使用，是經過了開發 -> 打包 -> 釋出 -> 下載安裝過程的。為了更易於理解，以及避免從一開始就陷入細節，本文將逆序講述整個過程。
一、背景在iOS開發中，大概每個新手都被各種配置、證書、打包和釋出等事情折騰過，我亦如此。
教程一搜一大堆，照著教程1234也能做下來。但是在這個過程中，我會產生很多問號：
為什麼程式能在模擬器上執行，卻無法在真機上執行？為什麼不是每個人都能在本地打包？具備什麼條件才能打包？為什麼需要證書，描述檔案？生成證書的原理是怎樣的？... ...很多事情是知其然而不知其所以然。
為了解決心中的疑惑，我藉著專案的機會，研究了一番整個打包釋出的流程，以及流程中每一步操作的背後都發生了什麼。
一個iOS應用最終能在使用者的裝置上使用，是經過了開發 -> 打包 -> 釋出 -> 下載安裝的過程的。
為了更易於理解，以及避免從一開始就陷入細節，本文將逆序講述整個過程。
二、iOS應用的安裝方式作為一個iOS使用者，我能通過哪些途徑安裝app？
App StoreApp Store是Apple官方的App釋出平臺。在App Store中搜索並安裝App，也是作為一個普通使用者最常用的安裝方式。TestFlightTestFlight是Apple官方的App測試平臺。在上架到App Store之前，可以通過TestFlight邀請一部分使用者參與測試，類似於網路遊戲的公測。App Center, FIR...除了官方的Apple Store之外，市面上還存在著App Center, FIR等非Apple官方的App管理平臺。在開發過程中，我們通常會將各個環境的App上傳到這些非官方的平臺中，用於日常測試；另外，我們也會將其作為企業級應用的最終釋出平臺。通過Xcode安裝到真機通過Xcode安裝到模擬器在開發過程中，DEV們作為特殊的iOS使用者，也會通過IDE直接在真機或模擬器上進行開發和測試。這裡把真機和模擬器分開，是因為它們確有不同。關於不同之處，我們將會在後文中談到。上面列出的，是使用者，以及DEV、QA同學最常用的5種安裝方式。那麼這篇文章是要講打包和釋出，為什麼我們要了解這些安裝方式呢？
是因為不同的安裝方式本身，背後就對應著不同型別的釋出方式。
或者更嚴謹的說，不同型別的釋出方式，就決定了用這種釋出方式打出來的app，最終能通過哪種安裝方式安裝到機器上。
三、iOS應用的釋出方式作為打包的那個人，我能通過選擇釋出方式，來決定我的應用能讓哪些使用者、通過何種安裝方式下載安裝
雖然我們有著以上不同的安裝方式，但其實本質上都是從某個平臺上，下載一個軟體包到本地並安裝（Xcode除外）。
不同的平臺做的也是同樣的事情，即提供一個存放軟體包的倉庫，可供使用者下載軟體包。
釋出，就是把軟體包上傳到釋出平臺。這步就無需贅述了。
那麼我們再往前一步：打包。
簡單來說，所謂打包，就是將原始碼轉換成iOS系統的軟體包-ipa檔案iPhone application archive。
對於一個iOS應用，它的打包過程包括：
選擇釋出方式選擇證書和描述檔案編譯 & 簽名匯出ipa檔案本節我們關注第一步：選擇一個釋出方式。
Apple提供了4種釋出方式：
App Store Connect -上架App Store以及TestFlight的app，用於生產環境釋出Ad Hoc - 部分機器可安裝的app，用於非生產環境的測試Enterprise - 企業級應用釋出Development - 與Ad Hoc類似，只有後續步驟所需要的證書和描述檔案不同圖1 iOS應用的釋出方式
結合上文，安裝方式和釋出方式之間的關係可以表示成：
圖2 安裝方式和釋出方式之間的關係
我們再對比它們之間的主要區別：
圖3 安裝方式和釋出方式之間的區別
從上圖中我們能得出一些結論：
能從App Store和TestFlight上安裝使用的，一定是App Store Connect的釋出方式。只有App Store中app和企業級應用沒有安裝數量上的限制。只要向真機上安裝app，無論選擇哪種安裝方式或釋出方式，都需要證書，簽名，描述檔案。這裡我自己的一些額外猜想是，Apple通過釋出方式上的限制，確保真正public的應用只能通過Apple稽核 ，App Store下載安裝。
但大家可能會發現，企業級應用也沒有任何安裝數量上的限制，甚至不需要稽核。那是否可以把企業級應用public的釋出呢？
答案是否定的。
首先，企業級應用需要Apple企業賬號，Apple對於企業級賬號的發放是非常嚴格的。
其次，Apple規定企業級應用的下載途徑不可公開，若發現公開則會有封號，應用失效的後果。
因此，雖然從能力上看企業級應用能被安裝在任意一臺機器上，但是從途徑上Apple限制了可能性。
至於只要向真機上安裝app，都需要證書，簽名，描述檔案，我猜測這是對每一臺裝置負責吧。
現在我們講完了打包的第一步釋出方式，下一步就是選擇證書和描述檔案。
我們已經知道，只要向真機上安裝app，哪怕是Xcode直接執行，就都需要證書，簽名，描述檔案。
那麼這些資源從哪來、怎麼來，就是我們接下來的話題。
四、Apple Developer Account和Member Center作為負責打包釋出的人，我要如何、在哪管理開發和釋出所需要的資源？
證書、描述檔案等資源被維護在Member Center中。它是開發者的資源管理中心，可以全生命週期管理：
證書，簽名，描述檔案等資源TestFlight、Apple Store上的應用... ...登陸Member Center需要開發者賬號Apple Developer Account。
開發者賬號有不同的型別。不同型別的開發者賬號對應的Member Center擁有不同的能力。
1. 開發者賬號的種類圖4 開發者賬號的種類
從大類上，開發者賬號分為三種：個人、組織和教育機構。教育機構這個類別我並沒有接觸過，也就不在這裡深入。
在4個小類中，公司和個人型別的賬號只有能否有團隊成員這一個區別。因此實際上很多開發者會把個人型別的賬號轉為公司型別，便於團隊協作。
也正是因為大多數應用都需要不止一個DEV來開發，所以比較常用的開發者賬號型別就是支援development team的公司和企業級應用。
對於公司和企業級應用，二者之間除了賬號的年費不一樣之外，最重要的區別在於，它能否將應用上架App Store。
那麼為什麼企業級賬號無法將應用上架App Store呢？
這裡大概解釋一下：
從前文我們已經知道，想要上架App Store，就必須選擇App Store Connect的釋出方式。
選了某種釋出方式之後，後續步驟所需要的證書，描述檔案等的型別也是不一樣的。
在Member Center中，企業級賬號只能生成釋出企業應用所需的證書，無法生成App Store Connect的釋出方式所需的證書，當然也就沒有上架App Store的能力。
同樣，公司賬號也無法生成企業級證書，無法釋出企業級應用。
2. Member Center的用途之：管理ID、裝置、證書、描述檔案全生命週期管理ID、裝置、證書、描述檔案，是Member Cente最重要的功能之一。
下面，我們分別看看它們的概念、用途和生成方式。
（1）ID - 唯一識別符號，根據用途分為App ID、Music ID、Merchant IDs等
目前我們只考慮最簡單的情況，就只介紹iOS應用必須的，用於標識一個或一組應用的App ID。
下圖即用公司型別的開發者賬號註冊一個App ID的過程：
圖5 註冊一個App ID
從圖中我們可以的看出：
App ID需要指定應用平臺App ID與Team ID繫結在一起。即，Apple知道一個應用的ID是註冊在哪個開發者賬號下的，也只允許這個賬號內的成員在真機上除錯或打包。App ID指定了應用的capabilities，如：獲取WI-FI資訊、使用錢包、健康、SIRI....（2）裝置 - 能安裝該開發者賬號下的應用的裝置
裝置的概念就更簡單了。每個蘋果裝置都有一個唯一識別符號UDID - Unique Device Identifier。
將某個設備註冊到開發者賬號下，就是在註冊時將該裝置的UDID填入。同一臺裝置可以被註冊到多個開發者賬號下。
可以理解為開發者賬號通過UDID列表，形成自己的裝置資源池。
（3）證書 - 由Apple 證書認證中心頒發的，用於確保應用內容可靠性和完整性的憑證
證書分為兩種：
開發證書，用於日常開發;釋出證書，用於應用釋出。生成一個證書的步驟也很簡單：
只需要在藉助keychain在本地生成一個CSR檔案，然後通過開發者賬號上傳，成功後就會存在於證書資源池中，在失效前可隨時使用下載（這裡我們只需要了解生成證書的步驟，至於這個過程中都發生了什麼，以及證書如何能確保應用的可靠性，我們後面會詳述）。
（4）描述檔案 - 一個ID，裝置，證書的集合
你可能已經發現了，前面的ID，裝置和證書的都是各自獨立的，我們看不到它們之間有任何的聯絡。
而描述檔案正是把這些資源整合到一起的集合。
一個描述檔案包含：
一個App ID開發或釋出證書一組可安裝該應用的裝置列表（非必有）描述檔案會被打包到應用中，描述該應用的App ID、持有的釋出證書、以及能被哪些裝置安裝。
描述檔案與證書一樣，也分開發和釋出兩大型別。其中，釋出又被細分為Ad Hoc、App Store、Enterprise型別。
還記得前面說的4種釋出方式嗎？它們和描述檔案的型別是一一對應的。
在打包的第一步選擇了一個釋出方式後，第二步就必須要選擇相應的描述檔案。
生成一個描述檔案的步驟，就是選擇一個型別，然後在開發者賬號下的ID、裝置、證書資源池中選出資源，將它們整合到一起。
最後，我們用更直觀的圖來表述描述檔案與安裝方式、釋出方式之間的關係：
圖7 描述檔案與安裝方式、釋出方式之間的關係
至此，我們已經大致了解了開發者賬號和它管理的App ID、證書、裝置和描述檔案，能夠完成打包的第二步了。
接下來就是第三步編譯和簽名，我們重點關注簽名。
簽名與證書緊密相關。
為了更好的了解簽名的原理和作用，我們將從證書開始講起。
五、證書的生成上一節講過證書的生成步驟：
藉助keychain在本地生成一個CSR檔案通過開發者賬號將CSR上傳至Member Center從Member Center下載證書但看這個描述，我們根本無法得知每一步的原理和目的。比如：CSR是什麼，有什麼用；上傳CSR成功為什麼能生成一個證書？這中間Apple又做了什麼？
相信這些問題在這一小節結束後，你會知道答案。
1. 生成CSR檔案: Keychain -> 證書助理 -> 從證書頒發機構請求證書
圖8 生成CSR檔案
CSR(Certificate Signing Request)檔案是用keychain生成的，包含了請求證書者的個人資訊的，用於向Apple證書頒發機構(Apple Worldwide Developer Relations Certification Authority，為了簡單理解，後文統稱Apple Root CA)申請證書的一個檔案。
圖9 CSR檔案的內容
想象一個場景：如果你去銀行辦理一張儲蓄卡，那麼銀行就會要求你提供身份證，並填一份申請單，添上姓名、籍貫、常用住址等個人資訊。
我們簡單做一下類比：Apple Root CA就相當於銀行，證書相當於儲蓄卡，CSR檔案就相當於儲蓄卡的申請單。
生成CSR的時候發生了什麼？
通過非對稱加密，在本地生成了證書的公鑰和私鑰，儲存在Keychain中（雖然與非對稱加密的方式並不一致，但為了便於理解，我們把私鑰類比成儲蓄卡密碼）將公鑰和個人資訊一起組合形成了CSR這裡插播一點對非對加密的簡單理解：通過非對稱加密生成的一對公鑰和私鑰，它們能互相解密出經過對方加密後的資訊，並且也只有它們才能解密。
如果我們將+和-分別定義為加密和解密，那麼：
圖10 非對稱加密
2. 通過開發者賬號將CSR上傳至Member Center成功後，我們就能在Member Center上下載證書了。
回到辦理銀行卡的流程：你將身份證、申請單交給工作人員，工作人員確認你本人和身份證相符，然後經過一系列的操作，最終會把辦理好的銀行卡交給你。
銀行卡中是包含了你的個人資訊的，因為辦理很多的業務，都需要你本人攜帶身份證，並保證和開戶資訊一致。
這正是對應了當前這一步。
類比於銀行工作人員的一系列操作，Apple Root CA在從CSR到證書的過程中做了什麼呢？
首先，Apple Root CA是有一個由自己頒發的證書的(CA證書)。同樣，這個證書也有它對應的公鑰和私鑰。
當我們將CSR傳給Apple Root CA，它會在驗證身份之後，後用CA證書的私鑰，對公鑰和部分個人資訊做加密，然後連同CSR中的公鑰一起，形成證書，並記錄在Member Center中。
圖11 證書生成的原理
3. 從Member Center下載證書下載證書到本地並安裝。由於證書中包含證書的公鑰，我們本地儲存著證書的私鑰，所以它們在Keychain中可以匹配得上：
六、簽名加密應用的內容
打包的第三步：編譯和簽名。對應用簽名，就是用證書的私鑰加密應用的內容。簽名會一併打包到應用中。
簽名是打包的必需步驟。
簽名需要證書的私鑰。
證書的私鑰儲存在證書申請人的keychain中。
圖13 App的簽名
因此：
作為非證書申請人，如果你想在本地打包，則需要向證書申請人請求私鑰。作為證書申請人，請像保護銀行卡密碼一樣保護私鑰，儘量不分發私鑰。分發私鑰意味著其他人可以以你的名義打包和釋出應用。至此，我們已經介紹完了打包的核心步驟。
那麼我們為什麼需要證書和簽名呢？
前面我們講了簽名和證書的生成過程，這裡終於到了展現它們用處的時候了。
我們將通過2步驗證，最終相信應用的可靠。
首先我們來回顧前面的內容：
描述檔案中包含有證書App中包含有描述檔案和簽名除此之外，iOS裝置預設裝有並信任Apple Root CA證書。
圖14 iOS 裝置上的App和Apple Root CA證書
下面我們開始驗證：
1. 用Apple Root CA證書，驗證應用證書的有效性應用證書的簽名，是由Apple Root CA的私鑰加密應用證書的公鑰和一些個人資訊得到的。
如果用Apple Root CA證書中的公鑰，能解密應用證書的簽名得到應用證書上公鑰，則能證明應用證書是由Apple頒發的。
2. 用驗證過的應用證書，驗證應用簽名的有效性應用簽名，是由應用證書的私鑰加密應用內容得到的。
如果用應用證書中的公鑰，能解密應用簽名得到應用的內容，則能證明簽名有效，應用可信。
八、不是總結的總結通過以上內容，我們了解到iOS應用打包釋出的流程，和證書體系。
在這裡，我刻意的沒做總結。
開篇的那些問題，大家找到答案了嗎？