摘要：一個iOS應用最終能在用戶的設備上使用，是經過了開發 -> 打包 -> 發佈 -> 下載安裝過程的。爲了更易於理解，以及避免從一開始就陷入細節，本文將逆序講述整個過程。
一、背景
在iOS開發中，大概每個新手都被各種配置、證書、打包和發佈等事情折騰過，我亦如此。
教程一搜一大堆，照着教程1234也能做下來。但是在這個過程中，我會產生很多問號：
- 爲什麼程序能在模擬器上運行，卻無法在真機上運行？
- 爲什麼不是每個人都能在本地打包？具備什麼條件才能打包？
- 爲什麼需要證書，描述文件？
- 生成證書的原理是怎樣的？
- … …
很多事情是知其然而不知其所以然。
爲了解決心中的疑惑，我藉着項目的機會，研究了一番整個打包發佈的流程，以及流程中每一步操作的背後都發生了什麼。
之後便總結成了這篇文章，分享給大家，希望能使新手iOS開發同學對iOS的打包、發佈和證書體系有更直觀的瞭解。
一個iOS應用最終能在用戶的設備上使用，是經過了 開發 -> 打包 -> 發佈 -> 下載安裝 的過程的。
爲了更易於理解，以及避免從一開始就陷入細節，本文將逆序講述整個過程。
二、iOS應用的安裝方式
作爲一個iOS用戶，我能通過哪些途徑安裝app？
-
App Store
App Store是Apple官方的App 發佈 平臺。在App Store中搜索並安裝App，也是作爲一個普通用戶最常用的安裝方式。
-
TestFlight
TestFlight是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類似，只有後續步驟所需要的證書和描述文件不同
結合上文，安裝方式和發佈方式之間的關係可以表示成：
我們再對比它們之間的主要區別：
從上圖中我們能得出一些結論：
- 能從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個小類中，公司和個人類型的賬號只有能否有團隊成員這一個區別。因此實際上很多開發者會把個人類型的賬號轉爲公司類型，便於團隊協作。
也正是因爲大多數應用都需要不止一個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的過程：
從圖中我們可以的看出：
- 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、設備、證書資源池中選出資源，將它們整合到一起。
最後，我們用更直觀的圖來表述描述文件與安裝方式、發佈方式之間的關係：
至此，我們已經大致瞭解了開發者賬號和它管理的App ID、證書、設備和描述文件，能夠完成打包的第二步了。
接下來就是第三步編譯和簽名，我們重點關注簽名。
簽名與證書緊密相關。
爲了更好的瞭解簽名的原理和作用，我們將從證書開始講起。
五、證書的生成
上一節講過證書的生成步驟：
- 藉助keychain在本地生成一個CSR文件
- 通過開發者賬號將CSR上傳至Member Center
- 從Member Center下載證書
但看這個描述，我們根本無法得知每一步的原理和目的。比如：CSR是什麼，有什麼用；上傳CSR成功爲什麼能生成一個證書？這中間Apple又做了什麼？
相信這些問題在這一小節結束後，你會知道答案。
1. 生成CSR文件: Keychain -> 證書助理 -> 從證書頒發機構請求證書
CSR(Certificate Signing Request)文件是用keychain生成的，包含了請求證書者的個人信息的，用於向Apple證書頒發機構(Apple Worldwide Developer Relations Certification Authority，爲了簡單理解，後文統稱Apple Root CA)申請證書的一個文件。
想象一個場景：如果你去銀行辦理一張儲蓄卡，那麼銀行就會要求你提供身份證，並填一份申請單，添上姓名、籍貫、常用住址等個人信息。
我們簡單做一下類比：Apple Root CA就相當於銀行，證書相當於儲蓄卡，CSR文件就相當於儲蓄卡的申請單。
生成CSR的時候發生了什麼？
- 通過非對稱加密，在本地生成了證書的公鑰和私鑰，保存在Keychain中（雖然與非對稱加密的方式並不一致，但爲了便於理解，我們把私鑰類比成儲蓄卡密碼）
- 將公鑰和個人信息一起組合形成了CSR
這裏插播一點對非對加密的簡單理解：通過非對稱加密生成的一對公鑰和私鑰，它們能互相解密出經過對方加密後的信息，並且也只有它們才能解密。
如果我們將+和-分別定義爲加密和解密，那麼：
2. 通過開發者賬號將CSR上傳至Member Center
成功後，我們就能在Member Center上下載證書了。
回到辦理銀行卡的流程：你將身份證、申請單交給工作人員，工作人員確認你本人和身份證相符，然後經過一系列的操作，最終會把辦理好的銀行卡交給你。
銀行卡中是包含了你的個人信息的，因爲辦理很多的業務，都需要你本人攜帶身份證，並保證和開戶信息一致。
這正是對應了當前這一步。
類比於銀行工作人員的一系列操作，Apple Root CA在從CSR到證書的過程中做了什麼呢？
首先，Apple Root CA是有一個由自己頒發的證書的(CA證書)。同樣，這個證書也有它對應的公鑰和私鑰。
當我們將CSR傳給Apple Root CA，它會在驗證身份之後，後用CA證書的私鑰，對公鑰和部分個人信息做加密，然後連同CSR中的公鑰一起，形成證書，並記錄在Member Center中。
3. 從Member Center下載證書
下載證書到本地並安裝。由於證書中包含證書的公鑰，我們本地保存着證書的私鑰，所以它們在Keychain中可以匹配得上：
六、簽名
加密應用的內容
打包的第三步：編譯和簽名。對應用簽名，就是用證書的私鑰加密應用的內容。簽名會一併打包到應用中。
簽名是打包的必需步驟。
簽名需要證書的私鑰。
證書的私鑰保存在證書申請人的keychain中。
因此：
- 作爲非證書申請人，如果你想在本地打包，則需要向證書申請人請求私鑰。
- 作爲證書申請人，請像保護銀行卡密碼一樣保護私鑰，儘量不分發私鑰。分發私鑰意味着其他人可以以你的名義打包和發佈應用。
至此，我們已經介紹完了打包的核心步驟。
那麼我們爲什麼需要證書和簽名呢？
七、證書和簽名的作用
用證書驗證簽名，從而保證App來源可信
前面我們講了簽名和證書的生成過程，這裏終於到了展現它們用處的時候了。
我們將通過2步驗證，最終相信應用的可靠。
首先我們來回顧前面的內容：
- 描述文件中包含有證書
- App中包含有描述文件和簽名
除此之外，iOS設備默認裝有並信任Apple Root CA證書。
下面我們開始驗證：
1. 用Apple Root CA證書，驗證應用證書的有效性
應用證書的簽名，是由Apple Root CA的私鑰加密應用證書的公鑰和一些個人信息得到的。
如果用Apple Root CA證書中的公鑰，能解密應用證書的簽名得到應用證書上公鑰，則能證明應用證書是由Apple頒發的。
2. 用驗證過的應用證書，驗證應用簽名的有效性
應用簽名，是由應用證書的私鑰加密應用內容得到的。
如果用應用證書中的公鑰，能解密應用簽名得到應用的內容，則能證明簽名有效，應用可信。
八、不是總結的總結
通過以上內容，我們瞭解到iOS應用打包發佈的流程，和證書體系。
在這裏，我刻意的沒做總結。
開篇的那些問題，大家找到答案了嗎？
作者介紹
王叄，ThoughtWorks軟件開發工程師，專注於web和mobile領域。
本文轉載自ThoughtWorks洞見
原文鏈接：