01
Jul
新版App包裝製作流程(下)
Facebook

上一期的專欄我們提到了App 實機運行美夢成真的第一步, Certicate 的生成和取得。照著包裝製作App 的設定步驟四部曲,我們還有漫長的三個步驟,App 的設定,機器(iDevice) 的設定, Provisioning Prole 的生成和取得等待著我們。然而除了某些特殊功能的App 需要在Identiers 頁面新增對應的App ID,一般普通的App 其實用不著這麼麻煩。因此接下來就讓我們暫且跳過Identiers,從機器的設定開始,繼續進行我們的App 實機啟動旅程吧!

撰文:彼得潘

 

從Xcode 註冊iDevice 

一個開發帳號,自行產生的測試App,最多只能安裝至100 台機器上。換句話說,唯有註冊的機器,才能安裝我們所包裝的測試App。因此在實機測試前,請先將欲安裝App 的機器註冊。以下為從Xcode 註冊機器的流程(同樣的我們也可以從Certicates, Identiers & Prolest 網頁上操作): 

1. 將機器連接到Mac 

2. 打開Xcode 的Organizer 視窗

3. 切換到Devices 分頁(點選上方的Devices 按鈕) 

此時左邊側邊欄下方的Devices 區塊將顯示一長串的device 清單。正連接到Mac 上的device 旁會有個小圓圈, 其它則是曾經連接到此台Mac 的devices 兄弟們。

4. 切換到某個Device 分頁 ,點選Add to Portal 按鈕

不管是不是目前連接到Mac 的機器,只要點選它,然後點選下方的Add to Portal 按鈕,即可啟動註冊機器的流程。

和之前我們點選Refresh 生成和下載certicate 一樣,此時會先跳出開發帳號的登入視窗。 我們必須登入後, Xcode 才知道要將機器註冊到哪一個帳號底下。

 

5. 註冊的device 清單

成功註冊後,連結到Certicates, Identiers & Prolest 網頁,點選Devices,即可看到註冊的機器清單。從清單裡我們可看到每個機器都有個UDID 欄位。UDID 就好像我們人類的身份證字號一樣,每個iDevice 都擁有一個獨一無二的UDID。

每一個帳號都只有100 個註冊機器的名額,請謹慎運用。如果想要移除,只有在隔年帳號續約的時候才能做移除的動作。因此在註冊機器前,請三思而後行呀,不小心輸錯,可是要讓它佔據名額,一年之內都無法移除呀 ! 如圖所示,只有在隔年帳號續約時候,才能做reset,移除不再愛了的機器的行動。

設定App 的App ID 

想要將App 安裝到實機上,必須滿 足以下四個條件: 

1. 搭配的certicate
​2. 註冊的iDevice
​3. 搭配的App ID
4. 搭配的provisioning prole 

經過了前面的步驟,我們已經成功取得certicate,也註冊了欲安裝App 的機器,接下來就剩下設定App ID 和取得provisioning prole 了。每一個我們在iOS 裝置上所看到的App,皆有個獨一無二的App ID。天底下沒有2 個App 會有著 一樣的ID。接下來讓我們建立全新的Xcode 專案,學習如何設定App 的App ID 吧。

1. 建立Single View Application 專案Test 

當我們在設定專案資訊時,Bundle Identier 欄位即是我們朝思暮想的App ID 的另一個名稱。在這裡我們無法直接編輯,因為預設BundleIdentier 將等同於Company Identier 結合Product Name(專案名稱)。為了確保App ID 的獨一無二,不和別的App 撞名,Apple 建議以顛倒的domain name 形式來命名,比方在這裡彼得潘將Company Identier 設為com.peterpan,如此結合專案名稱Test 後,Bundle Identier 即變成com.peterpan.Test。

因此Company Identier 欄位的主要目的正是為了產生Bundle Identier。一般而言,同一個開發帳號所開發的App,我們在命名App 的Bundle Identier 時,習慣前面一樣,只差在最後的字元。因此最常見的模式為採用一樣的Company Identier,再結合不同的專案名稱,即可讓我們開發的每個App 有著不同的App ID,而且也不會和別人開發的App 撞名。

2. 手動修改Bundle Identier

切換到Target Test 的Summary 頁面,即可看到Bundle Identier 的蹤影。雖然我們可以從此處直接修改,不過預設在這裡我們只能修改前面的Company Identier。

若是連後頭的專案名稱也想換掉,則需切換到Info 頁面,在Bundle identier 欄位做調整。 

不過在這裡我們也可以什麼都不改,因為預設生成的Bundle Identier 已經 足夠我們待會將App 安裝至實機。

生成iOS Team Provisioning Prole 

終於來到最後一步,provisioning prole 了。到時候App 能夠順利安裝至實機,prole 可說是關鍵中的關鍵。prole 設定了certicate,AppID,以及支援的iDevice, 到時候安裝App 時,唯有結合prole 和certicate (含有public key 和private key),通過以下三道嚴密的檢查,App 才能順利於實機上啟動: 

1. App 的App ID 符合prole 設定的App ID
​2. prole 搭配正確的certicate
3. 欲安裝的實機包含在prole 所支援的device 清單裡

看來生成prole 似乎是件不簡單的事,然而,令人意想不到的,當我們完成開發帳號下第 一個機器的註冊時(也就是點選Add to Portal),Xcode 即貼心地幫我們自動生成第一個prole,iOS Team Provisioning Prole。而且除了生成,它也一併將生成的prole 下載下來了! 

在Organizer 的Provisioning Proles 頁面可以看到剛剛才生成下載的iOS Team Provisioning Prole。

從網頁上也可以在Provisioning Proles 頁面找到它。

iOS Team Provisioning Prole 是非常特別的prole。右上圖為它和一般我們自己手動生成prole 的PK 比較表。

從剛剛的PK 表, 我們領教了iOS Team Provisioning Prole 強大之處。由於它包含了帳號底下所有的註冊機器,設定的App ID 為可對應任何App 的Xcode iOS Wildcard App ID, 因此換句話說, 當我們將App 的prole 設為它時,即可順利地將任何我們開發的App 安裝到有註冊的實機上。

雖然我們還沒有做過任何建立App ID 的動作,但其實當我們我們完成第一個機器的註冊時,Xcode 不只自動生成了第一個prole iOS TeamProvisioning Prole,此prole 搭配的App ID,Xcode iOS Wildcard App ID 也一併生成了。從網頁上的Identiers 頁面我們可以找到它。注意它的ID 欄位為*,* 表示可以對應任何字串的App ID,這也就是為何所有我們開發的App 都可以搭配iOS Team Provisioning Prole 的原因。(凡事總有例外,還是存在著某些特殊功能需求的App 不能搭配iOS Team Provisioning Prole。) 

 

Prole 的PK 比較表

 

iOS Team Provisioning Prole

其它prole

生成和修改方式

Xcode 自動生成和修改 

(不能人工修改)

手動生成和修改

包含的機器

登記在帳號底下的所有註冊機器

手動設定 支援的機器

類型

development prole,搭配development certificate, 只能運 用於開發模式

可選擇三種模式

1. 開發模式的development prole 

2. 測試模式的Ad Hoc distribution prole 

3. 上架模式的App Store distribution prole

App ID

可對應任何App 的Xcode iOS Wildcard App ID

只能對應單一App 或某幾個App 的App ID

 

設定prole 

1. 切換到Target Test 的Build Settings 頁面,找尋Code Signing Identity 的蹤影

2. 設定Debug 下的Any iOS SDK 欄位

正常情況下,Automatic Prole Selector 模式即會幫我們選出正確的prole。不過若是它選的不是我們要的, 還是可以自己從清單裡挑選。請確認最後中選的是iOS Team Provisioning Prole。

現在我們終於可以大方地按下Xcode 左上角的Run 按鈕,享受App 於實機運行的快感了!