1. 程式人生 > >ios學習之 關於Certificate、Provisioning Profile、App ID的介紹及其之間的關係

ios學習之 關於Certificate、Provisioning Profile、App ID的介紹及其之間的關係

剛接觸iOS開發的人難免會對蘋果的各種證書、配置檔案等不甚瞭解,可能你按照網上的教程一步一步的成功申請了真機除錯,但是還是對其中的緣由一知半解。這篇文章就對Certificate、Provisioning Profile等做個總結。

 1.概念介紹

如果你擁有一個開發者賬戶的話,在iOS Dev Center開啟Certificates, Indentifiers & Profiles,你就可以看到如下的列表:

Profile Portal改版有一段時間了,改版之後的結構比以前更清晰明瞭,易於理解和管理。

上面的列表就包含了開發、除錯和釋出iOS應用程式所需的所有內容:Certificates、Identifiers、Devices、Provisioning Profiles。下面將一一解釋這幾個東東。

Certificate

證書是用來給應用程式簽名的,只有經過簽名的應用程式才能保證他的來源是可信任的,並且程式碼是完整的, 未經修改的。在Xcode Build Setting的Code Signing Identity中,你可以設定用於為程式碼簽名的證書。 

眾所周知,我們申請一個Certificate之前,需要先申請一個Certificate Signing Request (CSR) 檔案,而這個過程中實際上是生成了一對公鑰和私鑰,儲存在你Mac的Keychain中。程式碼簽名正是使用這種基於非對稱祕鑰的加密方式,用私鑰進行簽名,用公鑰進行驗證。如下圖所示,在你Mac的keychain的login中儲存著相關的公鑰和私鑰,而證書中包含了公鑰。你只能用私鑰來進行簽名,所以如果沒有了私鑰,就意味著你不能進行簽名了,所以就無法使用這個證書了,此時你只能revoke之前的證書再申請一個。因此在申請完證書時,最好匯出並儲存好你的私鑰。當你想與其他人或其他裝置共享證書時,把私鑰傳給它就可以了。私鑰儲存在你的Mac中,而蘋果生成的Certificate中包含了公鑰。當你用自己的私鑰對程式碼簽名後,蘋果就可以用證書中的公鑰來進行驗證,確保是你對程式碼進行了簽名,而不是別人冒充你,同時也確保程式碼的完整性等。 

 

證書主要分為兩類:Development和Production,Development證書用來開發和除錯應用程式,Production主要用來分發應用程式(根據證書種類有不同作用),下面是證書的分類資訊:(括號內為證書有效期)

(注:不同型別的開發者賬戶所能建立的證書種類不同,關於開發者賬戶的對比和InHouse證書相關的內容,請見我的另一篇文章)

  • Development
    • App Development (1年):用來開發和真機除錯應用程式。
    • Push Development (1年):用來除錯Apple Push Notification
  • Production
    • In-House and Ad Hoc (3年):用來發布In-House和AdHoc的應用程式。

    •  App Store :用來發布提交App Store的應用程式。
    • MDM CSR
    • Push Production (1年):用來在釋出版本中使用Apple Push Notification。
    • Pass Type ID Certificate
    • Website Push ID Certificate

有一些型別的證書我沒有使用過,所以也不瞭解具體的作用。

App ID

App ID用於標識一個或者一組App,App ID應該是和Xcode中的Bundle ID是一致的或者匹配的。App ID主要有以下兩種:

  • Explicit App ID:唯一的App ID,這種App ID用於唯一標識一個應用程式,例如com.ABC.demo1,標識Bundle ID為com.ABC.demo1的程式。
  • Wildcard App ID:萬用字元App ID,用於標識一組應用程式。例如*可以表示所有應用程式,而com.ABC.*可以表示以com.ABC開頭的所有應用程式。

 每建立一個App ID,我們都可以設定該App ID所使用的APP Services,也就是其所使用的額外服務。每種額外服務都有著不同的要求,例如,如果要使用Apple Push Notification Services,則必須是一個explicit App ID,以便能唯一標識一個應用程式。下面是目前所有可選的服務和相應的配置要求。

如果你的App使用上述的任何一種service,就要按照要求去配置。

Device

Device最簡單了,就是iOS裝置。Devices中包含了該賬戶中所有可用於開發和測試的裝置。 每臺裝置使用UDID來唯一標識。

每個賬戶中的裝置數量限制是100個。Disable 一臺裝置也不會增加名額,只能在membership year 開始的時候才能通過刪除裝置來增加名額。

關於裝置數量的問題,詳見這篇文章

Provisioning Profile

一個Provisioning Profile檔案包含了上述的所有內容:證書、App ID、裝置。

試想一下,如果我們要打包或者在真機上執行一個應用程式,我們首先需要證書來進行簽名,用來標識這個應用程式是合法的、安全的、完整的等等;然後需要指明它的App ID,並且驗證Bundle ID是否與其一致;再次,如果是真機除錯,需要確認這臺裝置能否用來執行程式。而Provisioning Profile就把這些資訊全部打包在一起,方便我們在除錯和釋出程式打包時使用,這樣我們只要在不同的情況下選擇不同的profile檔案就可以了。而且這個Provisioning Profile檔案會在打包時嵌入.ipa的包裡。

例如,如下圖所示,一個用於Development的Provisioning Profile中包含了該Provisioning Profile對應的App ID,可使用的證書和裝置。這意味著使用這個Provisioning Profile打包程式必須擁有相應的證書,並且是將App ID對應的程式執行到Devices中包含的裝置上去。

如上所述,在一臺裝置上執行應用程式的過程如下:

與證書一樣,Provisioning Profile也分為Development和Distribution兩種:

(注:前面提到不同賬戶型別所能建立的證書種類不同,顯然Profile檔案的種類是和你所能建立的證書種類相關的)

  • Development (1年)
  • Distribution (1年)
    • In House
    • Ad Hoc
    • App Store

In House 與Ad Hoc的不同之處在於:In House沒有裝置數量限制,而Ad Hoc是用來測試用的,Ad Hoc的包只能執行在該賬戶內已登記的可用裝置上,顯然是有最多100個裝置的數量限制。所以這兩種Provisioning Profile檔案的區別就在於其中的裝置限制不一樣而已,而他們所使用的Certificate是相同的。

2.開發/釋出流程

瞭解了上面的概念,再來看開發及釋出流程就非常簡單了,而且相信你不用看教程也能一步步完成所有的操作了。

開發/真機除錯流程

根據上面的介紹,可以知道進行Development主要有以下幾個步驟:

  • 申請證書
  • 加入裝置
  • 生成Provisioning Profile
  • 設定Xcode Code Sign Identifer

事實上第三步通常是不需要的,因為我們通常都是用Xcode生成和管理的iOS Team Provisioning Profile來進行開發,因為它非常方便,所以不需要自己手動生成Provisioning Profile。

iOS Team Provisioning Profile是第一次使用Xcode新增裝置時,Xcode自動生成的,它包含了Xcode生成的一個Wildcard App ID(*,匹配所有應用程式),賬戶裡面所有的Devices和所有Development Certificates,如下圖所示。因此,team中的所有成員都可以使用這個iOS Team Provisioning Profile在team中的所有裝置上除錯所有的應用程式。並且當有新裝置新增進來時,Xcode會更新這個檔案。

釋出流程

網上有很多關於釋出App Store的流程,我就不綴述了,不過根據上面的概念介紹,不管是App Store、In-House還是Ad-Hoc,打包流程都是差不多的,都包括了以下幾個關鍵步驟:

  • 建立釋出證書
  • 建立App ID
  • 建立對應的Provisioning Profile檔案
  • 裝置Bundle ID和App ID一致
  • 設定Xcode Code Sign Identifer,選擇合適的Profile和證書進行簽名,打包

以上就是對證書、Provisioning Profile、App ID等的介紹,下一篇文章會介紹以下In-House證書相關的內容。