一個iOS應用最終能在使用者的裝置上使用，是經過了開發 -> 打包 -> 釋出 -> 下載安裝過程的。為了更易於理解，以及避免從一開始就陷入細節，本文將逆序講述整個過程。Github開源地址，一步步教你使用
一、背景
在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種釋出方式：
圖1 iOS應用的釋出方式
- App Store Connect -上架App Store以及TestFlight的app，用於生產環境釋出
- Ad Hoc - 部分機器可安裝的app，用於非生產環境的測試
- Enterprise - 企業級應用釋出
- Development - 與Ad Hoc類似，只有後續步驟所需要的證照和描述檔案不同
結合上文，安裝方式和釋出方式之間的關係可以表示成：
圖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檔案，然後通過開發者賬號上傳，成功後就會存在於證照資源池中，在失效前可隨時使用下載（這裡我們只需要瞭解生成證照的步驟，至於這個過程中都發生了什麼，以及證照如何能確保應用的可靠性，我們後面會詳述）。
圖6 生成一個證照
（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中可以匹配得上：
圖12 安裝證照到本機
六、簽名
加密應用的內容
打包的第三步：編譯和簽名。對應用簽名，就是用證照的私鑰加密應用的內容。簽名會一併打包到應用中。
簽名是打包的必需步驟。
簽名需要證照的私鑰。
證照的私鑰儲存在證照申請人的keychain中。
圖13 App的簽名
因此：
- 作為非證照申請人，如果你想在本地打包，則需要向證照申請人請求私鑰。
- 作為證照申請人，請像保護銀行卡密碼一樣保護私鑰，儘量不分發私鑰。分發私鑰意味著其他人可以以你的名義打包和釋出應用。
至此，我們已經介紹完了打包的核心步驟。
那麼我們為什麼需要證照和簽名呢？
七、證照和簽名的作用
用證照驗證簽名，從而保證App來源可信
前面我們講了簽名和證照的生成過程，這裡終於到了展現它們用處的時候了。
我們將通過2步驗證，最終相信應用的可靠。
首先我們來回顧前面的內容：
- 描述檔案中包含有證照
- App中包含有描述檔案和簽名
除此之外，iOS裝置預設裝有並信任Apple Root CA證照。
圖14 iOS 裝置上的App和Apple Root CA證照
下面我們開始驗證：
1. 用Apple Root CA證照，驗證應用證照的有效性
應用證照的簽名，是由Apple Root CA的私鑰加密應用證照的公鑰和一些個人資訊得到的。
如果用Apple Root CA證照中的公鑰，能解密應用證照的簽名得到應用證照上公鑰，則能證明應用證照是由Apple頒發的。
圖15 驗證App證照的有效性
2. 用驗證過的應用證照，驗證應用簽名的有效性
應用簽名，是由應用證照的私鑰加密應用內容得到的。
如果用應用證照中的公鑰，能解密應用簽名得到應用的內容，則能證明簽名有效，應用可信。
圖16 驗證App簽名的有效性
八、不是總結的總結
通過以上內容，我們瞭解到iOS應用打包釋出的流程，和證照體系。
在這裡，我刻意的沒做總結。
開篇的那些問題，大家找到答案了嗎？
收入於：Github