詳解iOS打包、釋出與證書體系

小顧iOSer發表於2021-07-28

一個iOS應用最終能在使用者的裝置上使用,是經過了開發 -> 打包 -> 釋出 -> 下載安裝過程的。為了更易於理解,以及避免從一開始就陷入細節,本文將逆序講述整個過程。Github開源地址,一步步教你使用

一、背景

在iOS開發中,大概每個新手都被各種配置、證照、打包和釋出等事情折騰過,我亦如此。

教程一搜一大堆,照著教程1234也能做下來。但是在這個過程中,我會產生很多問號:

  • 為什麼程式能在模擬器上執行,卻無法在真機上執行?
  • 為什麼不是每個人都能在本地打包?具備什麼條件才能打包?
  • 為什麼需要證照,描述檔案?
  • 生成證照的原理是怎樣的?
  • ... ...

很多事情是知其然而不知其所以然。

為了解決心中的疑惑,我藉著專案的機會,研究了一番整個打包釋出的流程,以及流程中每一步操作的背後都發生了什麼。

之後便總結成了這篇文章,分享給大家,希望能使新手iOS開發同學對iOS的打包、釋出和證照體系有更直觀的瞭解。

一個iOS應用最終能在使用者的裝置上使用,是經過了**開發 -> 打包 -> 釋出 -> 下載安裝**的過程的。

為了更易於理解,以及避免從一開始就陷入細節,本文將逆序講述整個過程。

二、iOS應用的安裝方式

作為一個iOS使用者,我能通過哪些途徑安裝app?

  1. App Store

    App Store是Apple官方的App釋出平臺。在App Store中搜尋並安裝App,也是作為一個普通使用者最常用的安裝方式。

  2. TestFlight

    TestFlight是Apple官方的App測試平臺。在上架到App Store之前,可以通過TestFlight邀請一部分使用者參與測試,類似於網路遊戲的公測。

  3. App Center, FIR...

    除了官方的Apple Store之外,市面上還存在著App Center, FIR等非Apple官方的App管理平臺。在開發過程中,我們通常會將各個環境的App上傳到這些非官方的平臺中,用於日常測試;另外,我們也會將其作為企業級應用的最終釋出平臺。

  4. 通過Xcode安裝到真機

  5. 通過Xcode安裝到模擬器

    在開發過程中,DEV們作為特殊的iOS使用者,也會通過IDE直接在真機或模擬器上進行開發和測試。這裡把真機和模擬器分開,是因為它們確有不同。關於不同之處,我們將會在後文中談到。

上面列出的,是使用者,以及DEV、QA同學最常用的5種安裝方式。那麼這篇文章是要講打包和釋出,為什麼我們要了解這些安裝方式呢?

是因為不同的安裝方式本身,背後就對應著不同型別的釋出方式。

或者更嚴謹的說,不同型別的釋出方式,就決定了用這種釋出方式打出來的app,最終能通過哪種安裝方式安裝到機器上。

三、iOS應用的釋出方式

作為打包的那個人,我能通過選擇釋出方式,來決定我的應用能讓哪些使用者、通過何種安裝方式下載安裝

雖然我們有著以上不同的安裝方式,但其實本質上都是從某個平臺上,下載一個軟體包到本地並安裝(Xcode除外)。

不同的平臺做的也是同樣的事情,即提供一個存放軟體包的倉庫,可供使用者下載軟體包。

釋出,就是把軟體包上傳到釋出平臺。這步就無需贅述了。

那麼我們再往前一步:打包

簡單來說,所謂打包,就是將原始碼轉換成iOS系統的軟體包-ipa檔案iPhone application archive

對於一個iOS應用,它的打包過程包括:

  1. 選擇釋出方式
  2. 選擇證照和描述檔案
  3. 編譯 & 簽名
  4. 匯出ipa檔案

本節我們關注第一步:選擇一個釋出方式。

Apple提供了4種釋出方式:

圖1 iOS應用的釋出方式

圖1 iOS應用的釋出方式

  1. App Store Connect -上架App Store以及TestFlight的app,用於生產環境釋出
  2. Ad Hoc - 部分機器可安裝的app,用於非生產環境的測試
  3. Enterprise - 企業級應用釋出
  4. 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的過程:

註冊一個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 證照認證中心頒發的,用於確保應用內容可靠性和完整性的憑證

證照分為兩種:

  1. 開發證照,用於日常開發;
  2. 釋出證照,用於應用釋出。

生成一個證照的步驟也很簡單:

只需要在藉助keychain在本地生成一個CSR檔案,然後通過開發者賬號上傳,成功後就會存在於證照資源池中,在失效前可隨時使用下載(這裡我們只需要瞭解生成證照的步驟,至於這個過程中都發生了什麼,以及證照如何能確保應用的可靠性,我們後面會詳述)。

生成一個證照

生成一個證照

圖6 生成一個證照

(4)描述檔案 - 一個ID,裝置,證照的集合

你可能已經發現了,前面的ID,裝置和證照的都是各自獨立的,我們看不到它們之間有任何的聯絡。

而描述檔案正是把這些資源整合到一起的集合。

一個描述檔案包含:

  • 一個App ID
  • 開發或釋出證照
  • 一組可安裝該應用的裝置列表(非必有)

描述檔案會被打包到應用中,描述該應用的App ID、持有的釋出證照、以及能被哪些裝置安裝。

描述檔案與證照一樣,也分開發釋出兩大型別。其中,釋出又被細分為Ad HocApp StoreEnterprise型別。

還記得前面說的4種釋出方式嗎?它們和描述檔案的型別是一一對應的。

在打包的第一步選擇了一個釋出方式後,第二步就必須要選擇相應的描述檔案。

生成一個描述檔案的步驟,就是選擇一個型別,然後在開發者賬號下的ID、裝置、證照資源池中選出資源,將它們整合到一起。

最後,我們用更直觀的圖來表述描述檔案與安裝方式、釋出方式之間的關係:

描述檔案與安裝方式、釋出方式之間的關係

圖7 描述檔案與安裝方式、釋出方式之間的關係

至此,我們已經大致瞭解了開發者賬號和它管理的App ID、證照、裝置和描述檔案,能夠完成打包的第二步了。

接下來就是第三步編譯和簽名,我們重點關注簽名。

簽名與證照緊密相關。

為了更好的瞭解簽名的原理和作用,我們將從證照開始講起。

五、證照的生成

上一節講過證照的生成步驟:

  1. 藉助keychain在本地生成一個CSR檔案

  2. 通過開發者賬號將CSR上傳至Member Center

  3. 從Member Center下載證照

但看這個描述,我們根本無法得知每一步的原理和目的。比如:CSR是什麼,有什麼用;上傳CSR成功為什麼能生成一個證照?這中間Apple又做了什麼?

相信這些問題在這一小節結束後,你會知道答案。

1. 生成CSR檔案: Keychain -> 證照助理 -> 從證照頒發機構請求證照

生成CSR檔案

圖8 生成CSR檔案

CSR(Certificate Signing Request)檔案是用keychain生成的,包含了請求證照者的個人資訊的,用於向Apple證照頒發機構(Apple Worldwide Developer Relations Certification Authority,為了簡單理解,後文統稱Apple Root CA)申請證照的一個檔案。

CSR檔案的內容

圖9 CSR檔案的內容

想象一個場景:如果你去銀行辦理一張儲蓄卡,那麼銀行就會要求你提供身份證,並填一份申請單,添上姓名、籍貫、常用住址等個人資訊。

我們簡單做一下類比:Apple Root CA就相當於銀行,證照相當於儲蓄卡,CSR檔案就相當於儲蓄卡的申請單。

生成CSR的時候發生了什麼?

  1. 通過非對稱加密,在本地生成了證照的公鑰和私鑰,儲存在Keychain中(雖然與非對稱加密的方式並不一致,但為了便於理解,我們把私鑰類比成儲蓄卡密碼)
  2. 將公鑰和個人資訊一起組合形成了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中。

App的簽名

圖13 App的簽名

因此:

  • 作為非證照申請人,如果你想在本地打包,則需要向證照申請人請求私鑰。
  • 作為證照申請人,請像保護銀行卡密碼一樣保護私鑰,儘量不分發私鑰。分發私鑰意味著其他人可以以你的名義打包和釋出應用。

至此,我們已經介紹完了打包的核心步驟。

那麼我們為什麼需要證照和簽名呢?

七、證照和簽名的作用

用證照驗證簽名,從而保證App來源可信

前面我們講了簽名和證照的生成過程,這裡終於到了展現它們用處的時候了。

我們將通過2步驗證,最終相信應用的可靠。

首先我們來回顧前面的內容:

  • 描述檔案中包含有證照
  • App中包含有描述檔案和簽名

除此之外,iOS裝置預設裝有並信任Apple Root CA證照。

iOS 裝置上的App和Apple Root CA證照

圖14 iOS 裝置上的App和Apple Root CA證照

下面我們開始驗證:

1. 用Apple Root CA證照,驗證應用證照的有效性

應用證照的簽名,是由Apple Root CA的私鑰加密應用證照的公鑰和一些個人資訊得到的。

如果用Apple Root CA證照中的公鑰,能解密應用證照的簽名得到應用證照上公鑰,則能證明應用證照是由Apple頒發的。

驗證App證照的有效性

圖15 驗證App證照的有效性

2. 用驗證過的應用證照,驗證應用簽名的有效性

應用簽名,是由應用證照的私鑰加密應用內容得到的。

如果用應用證照中的公鑰,能解密應用簽名得到應用的內容,則能證明簽名有效,應用可信。

驗證App簽名的有效性

圖16 驗證App簽名的有效性

八、不是總結的總結

通過以上內容,我們瞭解到iOS應用打包釋出的流程,和證照體系。

在這裡,我刻意的沒做總結。

開篇的那些問題,大家找到答案了嗎?

收入於:Github

相關文章