Ios教程網 >> IOS使用技巧 >> IOS技巧綜合 >> iOS 程序從開發完到上 AppStore 那點事兒

iOS 程序從開發完到上 AppStore 那點事兒

編輯：IOS技巧綜合

[摘要]本文是對iOS 程序從開發完到上 AppStore 那點事兒的講解，對學習IOS蘋果軟件開發有所幫助,與大家分享。

收錄待用，修改轉載已取得騰訊雲授權

一、賬號體系

想要進行iOS開發，除了必備一台裝有Mac OS X/Xcode的Mac開發機（iMac or MacBook）之外，還必須要有蘋果開發者賬號，只有擁有開發者賬號，才能申請開發/發布證書及相應配置文件，項目才可以發布到App Store上。

開發者賬號分為兩種類型：

Individual（個人或公司開發者賬號$99）：能夠在指定的設備上進行真機調試，可以在AppStore發布項目。

個人賬號和公司賬號的區別：個人賬號注冊流程快，沒有團隊角色管理。只能一個用戶登錄操作；公司賬號需要注冊鄧白氏碼，企業營業執照，流程復雜，流程耗時長。有角色管理功能，能邀請多個appleid分不同角色管理。

Company/Organization（企業開發者賬號$299）：企業賬號還不同於公司賬號，企業賬號能夠進行Debug，Inhouse（企業內部發布，鵝廠的RDM）發布應用，不能發布AppStore，更像是企業內測賬號。

注意：第一類中的公司賬號和第二類中的企業賬號不是一碼事，雖然聽上去公司和企業是有些相似的概念。

如果我只是想本地開發練手，並不想發布到App Store上，也是可以不必花錢就能進行真機調試的。Xcode7以後，蘋果放寬了開發者的范圍，只要一個真實的蘋果賬號（在App Store裡下載應用的或者用於iTunes的賬號）即可。詳情請見http://www.jianshu.com/p/351be39f959e

二、打包

一個App能在自己的手機上運行，和能放到App Store裡被所有人下載還是不一樣的。當我們開發完APP，肯定想要發布到App Store供人下載，這個過程中，我們不是直接把寫好的代碼發給蘋果公司就完事了，而是要把自己的代碼像發快遞一樣打個包裝，發給蘋果公司，由它審核通過，允許發布到App Store才能上線。嗯，就是說我們是淘寶賣家，蘋果公司是我們的收件人，它收到貨後確認收貨我們才能拿到錢。

但是在這個過程中會有一個問題，如果別人冒充我的名義發給蘋果公司一份惡意代碼包怎麼辦？蘋果公司豈不是要給我差評？我豈不是很冤？為了避免這樣的問題，在蘋果App Store中上線的應用都需要通過一套數字證書簽名機制來確保項目代碼的來源是可信任的，代碼是完整的，未經他人修改的。這套機制基於非對稱性加密（也稱為公鑰加密）算法，開發者用私鑰對代碼進行簽名加密，蘋果公司用包含公鑰的證書進行驗證。

不同的開發者賬號可以打的包也不同，大體可以分為debug版還是release版，具體打包分類如下：

個人／公司開發者

development：本地調試使用

distribution

Ad Hoc：可供有限個登記到開發者中心-->設備中的設備安裝使用

App Store：發布到App Store版本

企業開發者

development：本地調試使用

distribution

Ad Hoc：可供有限個登記到開發者中心-->設備中的設備安裝使用

in house：企業內部使用，沒有測試機的數量限制，我們大鵝廠的RDM就屬於in house類型。用企業證書打包應用的最大好處是：應用可以安裝到非越獄的設備上運行，這樣很方便進行較大規模的測試、或公司范圍發起內部體驗，企業證書打包的應用禁止外發。

這裡詳細說一下Ad Hoc模式，Ad Hoc這種方式主要是為了給測試人員或者內部體驗人員安裝我們的程序以供測試使用的，對於大公司來說，讓他們每個人都拿著手機連到開發機進行安裝顯然是不現實，我們需要打包（Archive）我們的程序。

Ad Hoc方式就是在上架前最大程度的呈現出上架後的狀態，它與上架到AppStore的包唯一的區別在於Ad Hoc的包可以在指定機器上安裝，而上AppStore的包需要蘋果重簽名才能安裝到iOS設備上。也就是說，Ad Hoc模式需要用distribution證書並以release方式打包，但是它可以指定設備（DeviceId）。

打包的過程需要申請發布證書、配置文件等，每種打包模式必須對應各自的證書和配置文件，下面就詳細介紹一下這個過程以及其中涉及到的一些文件的主要功能。

2.1 Bundle ID

Bundle ID (Bundle Identifier)是一款iOS應用的唯一標識，應用與Bundle ID之間是唯一對應關系。應用新建成功後，Bundle ID將不可修改，如必須修改只能創建一個新的應用。

2.2 APP ID

開發者需要在開發者中心下圖的頁面點擊加號來注冊自己的APP，通過App ID用於標識一個或者一組App， App ID應該是和Xcode中項目的Bundle ID是一致的或者匹配的。開發者可以在下面的位置點擊加號創建App ID。

每創建一個App ID，我們都可以設置該App ID所使用的APP Services，也就是其所使用的額外服務。

下面是目前所有可選的服務和相應的配置要求。按照這個要求去配置你的App以獲得相應的服務。

App ID主要有以下兩種：

Explicit App ID：唯一的App ID，這種App ID用於唯一標識一個應用程序，例如com.tencent.portfolio，標識Bundle ID為com.tencent.portfolio的程序。Explicit App ID要與App ID一致。

Wildcard App ID：通配符App ID，用於標識一組應用程序。例如_可以表示所有應用程序，而com.tencent._可以表示以com.tencent開頭的所有應用程序。對於Wildcard App ID，只要bundle identifier包含其作為Prefix/Seed即可。

在某些時候我們可以使用通配符，但是通配符無法完成推送功能。也就是說，如果要使用Apple Push Notification Services，則必須是一個explicit App ID，以便能唯一標識一個應用程序。

需要著重說明一下，AppID是一款應用程序在蘋果全平台的唯一標識。正好前兩天同事們討論一個問題：一個bundleID的程序能不能既作調試使用又能發到AppStore？答案是可以的，在開發者中心配置的設備可供調試使用。

更進一步，debug、inhouse和發布到App Store的項目能不能是同一個bundleID？答案是否定的。因為企業賬號可以發inhouse版本的項目，卻不能發App Store，而AppId是全球唯一的，一個賬號創建了，其他賬號無法再創建。所以一般公司如果想發inhouse版本的企業內測包，通常是有兩個賬號，公司賬號用來調試和發布，企業賬號用來發布inhouse版，也就是說，inhouse和 AppStore、debug的bundleID肯定是不一樣的，至少有兩個bundleID。像大鵝廠這樣的大公司，由於調試／發布的賬號由專人統一管理，不能給到各個產品，所以我們必須自己購買一個專門用來調試的賬號，這也就導致了我們的項目有個三個bundleID。

2.3 證書

首先來說證書，顧名思義，證書就是為了證明某些信息真實性的憑證。不過可能不同人或者機構對真假的判斷都不一樣，A說是真的，B說是假的，證書也不過是證明簽發證書的機構的態度而已，真真假假這麼哲學的問題我們就不討論了，畢竟要到蘋果公司的App Store上線程序，蘋果爸爸的態度決定一切。也就是說，我們的信任起點就是蘋果公司，所以首先我們需要一個根證書（Apple Root Certificate），根證書是一切證書的合法性的來源，其含義就是“我們認蘋果爸爸說的一切”。根證書一般不需要自己去申請，iOS以及Mac OS X系統在安裝Xcode時將自動安裝。但是根證書需要及時更新，如果過期了，其他所有證書都會失效，會報Missing iOS Distribution signing identity for XXXXXX錯誤。再次提醒，一切蘋果公司的證書都依賴於根證書，根證書是其他所有證書的基礎。

除了必須的根證書以外，我們開發、調試項目還需要Development證書，發布項目還需要Production證書。結合前文說到的賬戶體系和各自可以打的包，個人／公司開發者和企業開發者都有開發和真機調試程序的功能，都可以申請各自的Development證書。在發布項目方面，個人／公司開發者和企業開發者權限不同，Production證書也不同。個人／公司開發者可以給制定設備安裝release版本的包、可以向App Store發送人人都可以下載安裝的包；而企業開發者賬號不能在App Store上線程序，只能發在企業內部體驗使用的包，比如咱們大鵝廠的RDM包。

Push Development 證書就是用來調試Apple Push Notification的證書，需要特別注意推送證書的對應關系。推送證書也分為兩類：開發環境和生產環境的。App的development證書對應推送的開發環境證書，inHouse AdHoc Distribution的證書對應推送的生產環境證書。此外，推送的開發環境和生產環境的對應的推送環境是不一樣的，需要對應蘋果後台測試推送的地址環境和生產推送的地址環境，如果對應關系搞錯都會收不到推送。

具體來說，證書就是.cer文件，包含開發者信息和公鑰信息，用於驗證代碼是否由該開發者的合法私鑰簽名過。開發者使用開發賬號登陸蘋果開發者網站即可申請（後文有申請過程），當開發者下載並雙擊打開證書文件後，證書會出現在鑰匙串裡。它與本地鑰匙串裡的私鑰匹配之後，開發者就可以使用它了。

2.4 p12文件

一個開發者賬號可以申請的證書數目有限，當我們需要多人合作開發的時候，不能每台機器都去申請證書，這種情況下正確的做法是，一台機器去申請鑰匙串和證書，然後生成出p12文件，分發給其他開發機安裝，使得其他開發機也“擁有”了證書。p12文件就是證書安裝到本地後，與本機私鑰match後生成的備份文件，其中包括證書和私鑰的信息，也可以稱為“備份證書”，跟身份證復印件差不多。

2.5 Provisioning Profile文件

Provisioning Profile文件就是一份配置信息文件，後綴為.mobileprovision。打包或者在真機上運行一個APP，一般要驗證以下幾個信息：

首先，需要證書對應的私鑰來進行簽名，用於標識這個APP是合法、安全、完整的；

其次，需要指明它的App ID，並且驗證Bundle ID是否與其一致；

然後，如果是真機調試，需要確認這台設備是否授權運行該APP。

Provisioning Profile把這些需要驗證的信息全部打包在一起，方便我們在調試和發布程序打包時使用。Provisioning Profile也分為Development和Distribution兩類，有效期同Certificate一樣。如下圖在Xcode中配置好AppStore,Debug,RDM各自所需的ProvisioningProfile文件，Xcode就會根據需要打出不同的包。

Provisioning Profile作為打包必備的一份文件，其中包含以下信息：

AppID：一個Provisioning Profile對應一個Explicit App ID或Wildcard App ID

使用了哪些證書：Provisioning Profile決定了Xcode用哪個證書（公鑰）/私鑰組合（Key Pair/Signing Identity）來簽名應用程序

功能授權列表

可安裝的設備列表： Provisioning Profile文件會在應用程序打包時嵌入到.ipa包裡，進而安裝到iOS設備上，是設備的信任憑證，證明其中包含的設備（iPhone，ipad）是個合法的測試設備。Distribution版本的ProvisioningProfile主要用於提交App Store審核，其中不指定開發測試的Devices。App Store審核通過上架後，允許所有iOS設備上安裝運行該App。

蘋果的簽名：由於Provisioning Profile文件是蘋果簽名的，我們必須從開發者中心申請，申請後也不能再隨意篡改（比如添加別的設備）。