"用戶會感激代碼簽名帶來的好處" – Apple Developer Library: Code Signing Guide
在 iOS 或 OS X 平臺上進行應(yīng)用開發(fā)時薪伏，你所需要使用的 API 大多設(shè)計得簡潔明了播玖。你可以輕易地實現(xiàn)酷炫的動畫效果嫌佑，便捷地進行應(yīng)用發(fā)布前測試强胰，或是用 Core Data 將數(shù)據(jù)安全的存儲在本地洛二。但是總有一天馋劈，你會碰上代碼簽名 (code signing) 和配置文件 (provisioning)，大多數(shù)情況下晾嘶，這會是你在心里問候某些人祖宗的開始妓雾。
如果你已經(jīng)在 iOS 上開發(fā)過應(yīng)用，那么你多半已經(jīng)與代碼簽名或設(shè)備配置文件打過交道了垒迂。即使是 OS X 開發(fā)者械姻，如果你想發(fā)布自己的應(yīng)用到 Mac App Store 上去或者想?yún)⑴c蘋果的開發(fā)者項目，那么也不得不開始為自己的代碼進行簽名机断。
大多數(shù)時候代碼簽名看上去像是一個難以理解的神秘黑盒楷拳。在這篇文章里我會盡可能揭示盒子內(nèi)部的運作機理。
通常來說吏奸，我們無法直接看到代碼簽名的運作過程欢揖，它們隱藏在 iOS 系統(tǒng)內(nèi)部和 SDK 之中。但我們可以通過觀察設(shè)置代碼簽名所需工具的運作方式奋蔚，來找出一些線索她混。除此之外，我們還可以參考 OS X 上的代碼簽名運作方式泊碑，畢竟 iOS 和 OS X 系出同源坤按，我們可以從他們的對比之中得到很多有用的信息。
OS X 上代碼簽名技術(shù)和相應(yīng)的 API 是在 Mac OS X Leopard 10.5 上首次出現(xiàn)的馒过，這剛好是第一臺 iPhone 發(fā)布的時候晋涣。這并非巧合，因為在 iOS 上沉桌，代碼簽名起到的作用更加重要谢鹊。iPhone 是在眾多游戲主機之后第一個大規(guī)模出售并且從頭就開始使用代碼簽名的計算平臺。只有在越獄之后留凭，iOS 才能運行沒有簽名的代碼佃扼。越獄使應(yīng)用可以繞過代碼簽名和沙盒安全機制的全部限制，這會是一個非常危險的行為蔼夜。
證書和密匙
作為一個 iOS 開發(fā)者兼耀，在你開發(fā)使用的機器上應(yīng)該已經(jīng)有一個證書，一個公鑰，以及一個私鑰瘤运。這些是代碼簽名機制的核心窍霞。像 SSL 一樣，代碼簽名也依賴于采用 X.509 標(biāo)準(zhǔn)的公開密鑰加密拯坟。
在 OS X 上但金，X.509 的基本組成部分（譯者注：例如證書等）都是由一個叫鑰匙串訪問的工具來進行管理。打開你開發(fā)機器上的鑰匙串訪問應(yīng)用郁季，選擇類別選項下的“我的證書（My Certificates）”冷溃，你可以看到所有你持有的私鑰相對應(yīng)的證書。要用一個證書設(shè)置代碼簽名梦裂，你必須擁有私鑰似枕，所以所有你擁有私鑰的證書都會被列在這里。如果你擁有一個證書的私鑰年柠，你可以展開證書并將它的私鑰顯示出來：
如果你要導(dǎo)出證書凿歼，例如為了備份（強烈建議進行），一定要記得展開證書那一條顯示出私鑰并將兩行都選中冗恨。
還有一種可以用來快速地顯示出你的系統(tǒng)中能用來對代碼進行簽名的認(rèn)證的方法答憔，那就是利用用途廣泛的命令行工具 security：
概括的講，一個證書是一個公鑰加上許多附加信息派近，這些附加信息都是被某個認(rèn)證機構(gòu)（Certificate Authority 簡稱 CA）進行簽名認(rèn)證過的，認(rèn)證這個證書中的信息是準(zhǔn)確無誤的洁桌。對于 iOS 開發(fā)來說這個認(rèn)證機構(gòu)就是蘋果的認(rèn)證部門 Apple Worldwide Developer Relations CA。認(rèn)證的簽名有固定的有效期，這就意味著當(dāng)前系統(tǒng)時間需要被正確設(shè)置殷蛇，因為證書是基于當(dāng)前時間進行核對孙乖。這也是為什么將系統(tǒng)時間設(shè)定到過去會對 iOS 造成多方面破壞的原因之一。
對于 iOS 開發(fā)來說吠谢，一般會有兩個證書：一個帶有前綴 iPhone Developer土童，另一個帶有前綴 iPhone Distribution。前者用于使應(yīng)用可以在你的測試設(shè)備上運行工坊，后者是在提交應(yīng)用到 APP store 時用到献汗。一個證書的用途取決于它所包含的內(nèi)部信息，在鑰匙串訪問中雙擊打開一個證書文件王污，你可以看到許多詳細條目罢吃，拖動到最下面有一條標(biāo)記著 Apple Developer Certificate (Submission)， 或者 Apple Developer Certificate (Development)昭齐，具體你會看到哪一種尿招，取決于你所打開的證書是哪一種類型，iOS 系統(tǒng)會利用這個信息來判斷你的應(yīng)用是運行在開發(fā)模式下還是發(fā)布模式，并據(jù)此判斷以切換應(yīng)用運行規(guī)則就谜。
為了讓擁有公鑰的證書起作用怪蔑，我們需要有私鑰。私鑰是你在為組成應(yīng)用的二進制文件進行簽名時派上用場的丧荐。沒有私鑰缆瓣，你就無法用證書和公鑰對任何東西設(shè)置簽名。
簽名過程本身是由命令行工具 codesign 來完成的篮奄。如果你在 Xcode 中編譯一個應(yīng)用捆愁，這個應(yīng)用構(gòu)建完成之后會自動調(diào)用 codesign 命令進行簽名，codesign 也正是給你提供了許多格式友好并且有用錯誤信息的那一個工具窟却。你可以在 Xcode 的 project settings 中設(shè)置代碼簽名信息昼丑。
需要注意的是 Xcode 只允許你在有限的選項中進行選擇，這些選項都是你既擁有公鑰也擁有私鑰的證書夸赫。所以如果在選項中沒有出現(xiàn)你想要的那一個菩帝，那么你需要檢查的第一件事情就是你是否擁有這個證書的私鑰。在這里你需要區(qū)分開用于開發(fā)測試還是用于發(fā)布茬腿，如果你想要在機器上測試你的應(yīng)用呼奢，你需要用用于開發(fā)測試的那一對密匙來進行簽名，如果你是要發(fā)布應(yīng)用切平，無論是給測試人員還是發(fā)布到 APP Store握础，你需要用用于發(fā)布的那一對密匙來進行簽名。
一直以來悴品，以上這些就是代碼簽名需要設(shè)置的全部禀综，設(shè)置了這些就幾乎完成了。
但是在 Xcode 6 的 project settings 中出現(xiàn)了設(shè)置配置文件的選項苔严。如果你選擇了某一個配置文件定枷，你必須選擇這個配置文件的證書中所包含的公鑰所對應(yīng)的那個密匙對，或者你可以選擇讓 Xcode 自動完成正確的設(shè)置届氢。關(guān)于這方面我們稍后再詳細說明欠窒，首先還是回到代碼簽名。
一個已簽名應(yīng)用的組成
一個已簽名的可執(zhí)行文件的簽名包含在 Mach-O 二進制文件格式中退子；對于例如腳本這樣的非 Mach-O 可執(zhí)行文件岖妄，就存放在該文件系統(tǒng)的的擴展屬性中。這種做法使得在 OS X 和 iOS 上的任何可執(zhí)行二進制文件都可以被設(shè)置簽名：不論是動態(tài)庫寂祥，命令行工具衣吠，還是 .app 后綴的程序包。這也意味著設(shè)置簽名的過程實際上會改動可執(zhí)行文件的文件內(nèi)容壤靶，將簽名數(shù)據(jù)寫入二進制文件中缚俏。
如果你擁有一個證書和它的私鑰，那么用 codesign 來設(shè)置簽名非常簡單，我們現(xiàn)在嘗試用下面列出的這個證書來為 Example.app 設(shè)置簽名：
$ codesign -s 'iPhone Developer: Thomas Kollbach (7TPNXN7G6K)' Example.app
如果你想為某一個 app 程序包重新設(shè)置簽名忧换，那么這個工具就很有用了恬惯。為了重新設(shè)置簽名，你必須帶上 -f參數(shù)亚茬，有了這個參數(shù)酪耳，codesign 會用你選擇的簽名替換掉已經(jīng)存在的那一個：
$ codesign -f -s 'iPhone Developer: Thomas Kollbach (7TPNXN7G6K)' Example.app
codesign 還可以為你提供有關(guān)一個可執(zhí)行文件簽名狀態(tài)的信息，這些信息在出現(xiàn)不明錯誤時會提供巨大的幫助刹缝。舉例來說碗暗，$ codesign -vv -d Example.app 會列出一些有關(guān) Example.app 的簽名信息：
你需要查看的第一件事是以 Authority 開頭的那三行。這三行告訴你到底是哪一個證書為這個 app 設(shè)置了簽名梢夯。在這里當(dāng)然是我的證書言疗，iPhone Developer: Thomas Kollbach (7TPNXN7G6K)。我的這個證書則是被證書 Apple Worldwide Developer Relations Certification Authority 設(shè)置了簽名的颂砸，依此類推這個證書則是被證書 Apple Root CA 設(shè)置了簽名噪奄。
在 Format 中也包含了一些關(guān)于代碼的信息：Example.app 并不單單是一個可執(zhí)行文件，它是一個程序包人乓，其中包含了一個 arm64 二進制文件勤篮。從 Executable 中的路徑信息你可以看出，這是一個以測試為目的的打包色罚，所以是一個 Mach-O thin 的二進制文件碰缔。
在一堆診斷信息中還包含了兩個非常有趣的條目。 Identifier 是我在 Xcode 中設(shè)置的 bundle identifier戳护。 TeamIdentifier 用于標(biāo)識我的工作組（系統(tǒng)會用這個來判斷應(yīng)用是否是由同一個開發(fā)者發(fā)布）金抡。此外用于發(fā)布應(yīng)用的證書中也包含這種標(biāo)識，這種標(biāo)識在區(qū)分同一名稱下的不同證書時非常有用姑尺。
現(xiàn)在這個二進制文件已經(jīng)用證書設(shè)置好簽名竟终。就像中世紀(jì)人用蠟來封印信封一樣蝠猬，簽名就這樣封印了這個應(yīng)用切蟋。下面我們來檢查一下封印是否完好：
就像大多數(shù) UNIX 工具一樣，沒有任何輸出代表簽名是完好的榆芦。那么我下面破壞這個封印柄粹，只要修改一下這個二進制文件：
修改已經(jīng)簽名的應(yīng)用會破壞封印，從命令行輸出我們可以看到代碼簽名正如我們所預(yù)期一樣起到了作用匆绣。
程序包和其他資源文件
對于命令行工具和腳本來說驻右，只是一個可執(zhí)行文件被設(shè)置簽名，但是 iOS 和 OS X 的應(yīng)用和框架則是包含了它們所需要的資源在其中的崎淳。這些資源包括圖片和不同的語言文件堪夭，資源中也包括很重要的應(yīng)用組成部分例如 XIB/NIB 文件，存檔文件(archives)，甚至是證書文件森爽。所以為一個程序包設(shè)置簽名時恨豁，這個包中的所有資源文件也都會被設(shè)置簽名。
為了達到為所有文件設(shè)置簽名的目的爬迟，簽名的過程中會在程序包中新建一個叫做 _CodeSignatue/CodeResources 的文件橘蜜，這個文件中存儲了被簽名的程序包中所有文件的簽名。你可以自己去查看這個簽名列表文件付呕，它僅僅是一個 plist 格式文件计福。
這個列表文件中不光包含了文件和它們的簽名的列表，還包含了一系列規(guī)則徽职，這些規(guī)則決定了哪些資源文件應(yīng)當(dāng)被設(shè)置簽名象颖。伴隨 OS X 10.10 DP 5 和 10.9.5 版本的發(fā)布，蘋果改變了代碼簽名的格式活箕，也改變了有關(guān)資源的規(guī)則力麸。如果你使用10.9.5或者更高版本的 codesign 工具，在 CodeResources 文件中會有4個不同區(qū)域育韩，其中的 rules 和 files 是為老版本準(zhǔn)備的克蚂，而 files2 和 rules2是為新的第二版的代碼簽名準(zhǔn)備的。最主要的區(qū)別是在新版本中你無法再將某些資源文件排除在代碼簽名之外筋讨，在過去你是可以的埃叭，只要在被設(shè)置簽名的程序包中添加一個名為 ResourceRules.plist 的文件，這個文件會規(guī)定哪些資源文件在檢查代碼簽名是否完好時應(yīng)該被忽略悉罕。但是在新版本的代碼簽名中赤屋，這種做法不再有效。所有的代碼文件和資源文件都必須設(shè)置簽名壁袄，不再可以有例外类早。在新版本的代碼簽名規(guī)定中，一個程序包中的可執(zhí)行程序包嗜逻，例如擴展 (extension)涩僻，是一個獨立的需要設(shè)置簽名的個體，在檢查簽名是否完整時應(yīng)當(dāng)被單獨對待栈顷。
授權(quán)機制 (Entitlements) 和配置文件 (Provisioning)
到目前為止逆日，我們都假設(shè)所有的證書起到的作用都是一樣的，并且假設(shè)如果我們有了一個有效的證書代碼簽名也就相應(yīng)的有效萄凤。然而這當(dāng)然不是唯一的規(guī)則室抽。操作系統(tǒng)有許多標(biāo)準(zhǔn)來檢測你的代碼是否允許運行。
這些標(biāo)準(zhǔn)并不是一成不變的靡努。舉例來說坪圾，在 OS X 上一個應(yīng)用是否允許被開啟是由 Gatekeeper 的選項決定的晓折，你可以在系統(tǒng)設(shè)置的安全選項中改變選項。在 Gatekeeper 選項中選擇 “受信任的開發(fā)者或者來自 Mac App Store” 會要求被打開的應(yīng)用必須被證書簽名兽泄，可以是 Mac App Store 開發(fā)者的應(yīng)用發(fā)布證書也可以是開發(fā)者 ID 證書已维。這些選項是由一個系統(tǒng)工具 spctl 來管理的，它管理著系統(tǒng)的所有安全評估策略已日。
在 iOS 上規(guī)則是不一樣的垛耳，無論是用戶還是開發(fā)者都不能改變應(yīng)用開啟策略，你必須有一個開發(fā)者帳號或者應(yīng)用發(fā)布證書才能讓應(yīng)用運行在 iOS 系統(tǒng)上飘千。
即使你可以讓應(yīng)用運行起來堂鲜，在 iOS 上你的應(yīng)用能做什么依然是受限制的。這些限制是沙盒管理的护奈。沙盒和代碼簽名機制是不同的缔莲，這很重要。代碼簽名保證了這個應(yīng)用里所包含的內(nèi)容正如它所說的那樣不多不少霉旗，而沙盒則是限制了應(yīng)用訪問系統(tǒng)的資源痴奏。這兩種技術(shù)是相互合作來發(fā)揮作用的，它們都能阻止你的應(yīng)用運行厌秒，也都能在 Xcode 中引起奇怪的問題读拆。但是在日常開發(fā)過程中，沙盒可能會更經(jīng)常引起問題鸵闪。沙盒機制在什么時候會引起問題呢檐晕，大多數(shù)情況下都是由于一個叫做授權(quán)的機制決定的。
授權(quán)機制
授權(quán)機制決定了哪些系統(tǒng)資源在什么情況下允許被一個應(yīng)用使用蚌讼。簡單的說它就是一個沙盒的配置列表辟灰，上面列出了哪些行為被允許，哪些會被拒絕篡石。
很可能你已經(jīng)猜到授權(quán)機制也是按照 plist 文件格式來列出的芥喇。Xcode 會將這個文件作為 --entitlements 參數(shù)的內(nèi)容傳給 codesign ，這個文件內(nèi)部格式如下：
在 Xcode 的 Capabilities 選項卡下選擇一些選項之后凰萨，Xcode 就會生成這樣一段 XML继控。 Xcode 會自動生成一個 .entitlements 文件，然后在需要的時候往里面添加條目沟蔑。當(dāng)構(gòu)建整個應(yīng)用時湿诊，這個文件也會提交給 codesign 作為應(yīng)用所需要擁有哪些授權(quán)的參考狱杰。這些授權(quán)信息必須都在開發(fā)者中心的 App ID 中啟用瘦材，并且包含在配置文件中，稍后我們會詳細討論這一點仿畸。在構(gòu)建應(yīng)用時需要使用的授權(quán)文件可以在 Xcode build setting 中的 code signing entitlements 中設(shè)置食棕。
在這個應(yīng)用中我啟用了 iCloud 鍵值對存儲 (key-value storage) (com.apple.developer.ubiquity-kvstore-identifier) 朗和，以及 iCloud 文檔存儲 (com.apple.developer.ubiquity-container-identifiers)。另外我還將應(yīng)用添加進了一個 App Group (比如說為了與擴展 (extensions) 共享數(shù)據(jù)簿晓，com.apple.security.application-groups)眶拉， 最后開啟了推送功能 (aps-environment)。這是一個開發(fā)版本憔儿，我會有將它連接到調(diào)試器的需求忆植，這就需要將 get-task-allow 設(shè)為 true。另外谒臼，app id朝刊，也就是 bundle id 加上開發(fā)者 id，也被單獨列出來了蜈缤。
當(dāng)然你并不能隨心所欲的取得授權(quán)拾氓，你的應(yīng)用能否得到某一項授權(quán)是有特定的規(guī)定的。舉例來說底哥，當(dāng) get-task-allow 被設(shè)定為 ture 時咙鞍，應(yīng)用只能在用于開發(fā)的證書簽名下運行。你被允許使用的推送環(huán)境 (aps-environment) 也存在類似的限制趾徽。
根據(jù)操作系統(tǒng)版本的不同我們可選的授權(quán)項目是不一樣的续滋，所以很難有一份列表可以詳盡地列出所有條目。至少在文檔 Adding Capabilities 中提到的所有功能都是需要經(jīng)過授權(quán)的孵奶。
授權(quán)信息會被包含在應(yīng)用的簽名信息中吃粒。如果你在這方面遇到了問題，可以嘗試查看簽名信息中具體包含了什么授權(quán)信息：$ codesign -d --entitlements - Example.app 會列出一個和前面的很像的 XML 格式的屬性列表拒课。你可以將這個文件的內(nèi)容添加進一個腳本徐勃，每次構(gòu)建應(yīng)用時用腳本檢查是否包含了推送服務(wù)的授權(quán)信息，以此確保推送服務(wù)工作正常早像。在這里推送服務(wù)只是一個例子僻肖，你使用的服務(wù)越多，這樣的時候都添加推送通知的授權(quán)卢鹦，以保證可以注冊推送通知臀脏。在新版本的 Xcode 6 之后，授權(quán)信息列表會以 Example.app.xcent這樣的名字的文件形式包含在應(yīng)用包中冀自。在我看來揉稚，這么做是為了在出現(xiàn)配置錯誤時提供更加有用的錯誤信息。
配置文件
在整個代碼簽名和沙盒機制中有一個組成部分將簽名熬粗，授權(quán)和沙盒聯(lián)系了起來搀玖，那就是配置文件 (provisioning profiles)。
每一個 iOS 開發(fā)者可能都花費過相當(dāng)?shù)臅r間研究如何設(shè)置配置文件驻呐，這個環(huán)節(jié)也正是會經(jīng)常出問題的地方灌诅。
一個配置文件中存放了系統(tǒng)用于判斷你的應(yīng)用是否允許運行的信息芳来，這就意味著如果你的配置文件有問題，修復(fù)起來會相當(dāng)煩人猜拾。
一個配置文件是一組信息的集合即舌，這組信息決定了某一個應(yīng)用是否能夠在某一個特定的設(shè)備上運行。配置文件可以用于讓應(yīng)用在你的開發(fā)設(shè)備上可以被運行和調(diào)試挎袜，也可以用于內(nèi)部測試 (ad-hoc) 或者企業(yè)級應(yīng)用的發(fā)布顽聂。Xcode 會將你在 project setting 中選擇的配置文件打包進應(yīng)用。前面提到了盯仪，選擇配置文件是 Xcode 6 才提供的功能芜飘，在 Xcode 5 或更早版本中，配置文件是 Xcode 根據(jù)你選擇的簽名證書來選擇的磨总。事實上同一個證書可以擁有多個不同的配置文件嗦明，因此讓 Xcode 自行選擇可能存在一些不確定性，最好的方式是你自主去選擇蚪燕，在 Xcode 6 中終于提供了這個功能娶牌。
我們下面來仔細研究一下配置文件。如果你要在自己的機器上找到配置文件馆纳，在這個目錄下 ~/Library/MobileDevice/Provisioning Profiles诗良。Xcode 將從開發(fā)者中心下載的全部配置文件都放在了這里。
不要驚訝鲁驶，配置文件并不是一個 plist 文件鉴裹，它是一個根據(jù)密碼訊息語法 (Cryptographic Message Syntax) 加密的文件（下文中會簡稱 CMS，但不要用這個簡寫 Google钥弯，這不是一個很好的關(guān)鍵字）径荔。如果你處理過 S/MIME 郵件或者證書你會對這種加密比較熟悉，詳細信息可以查看互聯(lián)網(wǎng)工程任務(wù)組 (IETF) 制定的 RFC 3852脆霎。
采用 CMS 格式進行加密使得配置文件可以被設(shè)置簽名总处，所以在蘋果給你這個文件之后文件就不能被改變了。配置文件的簽名和應(yīng)用的簽名不是一回事睛蛛，它是由蘋果直接在開發(fā)者中心 (developer portal) 中設(shè)置好了的鹦马。
某些版本的 OpenSSL 可以讀取這種格式，但是 OS X 自帶那個版本并不行忆肾。幸運的是命令行工具 security也可以解碼這個 CMS 格式荸频，那么我們就用 security 來看看一個 .mobileprovision 文件內(nèi)部是什么樣子：
$ security cms -D -I example.mobileprovision
這個命令會輸出簽名信息中的內(nèi)容，如果你親自試一下客冈，接下來你會得到一個 XML 格式的 plist 文件內(nèi)容輸出旭从。
這個列表中的內(nèi)容是 iOS 用于判斷你的應(yīng)用是否能運行在某個設(shè)備上真正需要的配置信息，每一個配置文件都有它自己的 UUID 郊酒。Xcode 會用這個 UUID 來作為標(biāo)識遇绞，記錄你在 build settings 中選擇了哪一個配置文件。
首先來看 DeveloperCertificates 這項燎窘，這一項是一個列表摹闽，包含了可以為使用這個配置文件的應(yīng)用簽名的所有證書。如果你用了一個不在這個列表中的證書進行簽名褐健，無論這個證書是否有效付鹿，這個應(yīng)用都無法運行。所有的證書都是基于 Base64 編碼符合 PEM (Privacy Enhanced Mail, RFC 1848) 格式的蚜迅。要查看一個證書的詳細內(nèi)容舵匾，將編碼過的文件內(nèi)容復(fù)制粘貼到一個文件中去，像下面這樣：
然后讓 OpenSSL 來處理 openssl x509 -text -in file.pem谁不。
回到配置文件中繼續(xù)往下看坐梯，你可能會注意到在 Entitlements 一項中包含了你的應(yīng)用的所有授權(quán)信息，鍵值就和之前在授權(quán)那節(jié)看到的一模一樣刹帕。
這些授權(quán)信息是你在開發(fā)者中心下載配置文件時在 App ID 中設(shè)置的吵血，理想的情況下，這個文件應(yīng)該和 Xcode 為應(yīng)用設(shè)置簽名時使用的那一個同步偷溺，但這種同步并不能得到保證蹋辅。這個文件的不一致是比較難發(fā)現(xiàn)的問題之一。
舉例來說挫掏，如果你在 Xcode 中添加了 iCloud 鍵值對存儲授權(quán) (com.apple.developer.ubiquity-kvstore-identifier)侦另，但是沒有更新，重新設(shè)置并下載新的配置文件尉共，舊的配置文件規(guī)定你的應(yīng)用并沒有這一項授權(quán)褒傅。那么如果你的應(yīng)用使用了這個功能，iOS 就會拒絕你的應(yīng)用運行袄友。這也是當(dāng)你在開發(fā)者中心編輯了應(yīng)用的授權(quán)樊卓，對應(yīng)的配置文件會被標(biāo)記為無效的原因。
如果你打開的是一個用于開發(fā)測試的證書杠河，你會看到一項 ProvisionedDevices碌尔，在這一項里包含了所有可以用于測試的設(shè)備列表。因為配置文件需要被蘋果簽名券敌，所以每次你添加了新的設(shè)備進去就要重新下載新的配置文件唾戚。
小結(jié)
代碼簽名和配置文件這一套大概是一個 iOS 開發(fā)者必須處理的僅次于編碼的最復(fù)雜的問題之一。與在 Mac 或 PC 上直接的編譯運行你的代碼不同待诅，處理這些問題會是非常不同的經(jīng)歷叹坦。
雖然了解每一個部分是怎么運作的很有幫助，但是要控制好所有這些設(shè)置和工具其實是一件很消耗時間的事情卑雁，特別是在一個開發(fā)團隊中募书，到處發(fā)送證書和配置文件顯然很不方便绪囱。雖然蘋果在最近幾次發(fā)布的 Xcode 中都嘗試改善，但是我不是很確定每一項改動都起到了好的作用莹捡。處理代碼簽名是每個開發(fā)者必過的大坑鬼吵。
雖然處理代碼簽名對于開發(fā)者來說非常繁瑣，但不可否認(rèn)正是它使得 iOS 對于用戶來說是一個非常安全的操作系統(tǒng)篮赢。如果你注意安全相關(guān)的新聞齿椅，每一次出現(xiàn)號稱能在 iOS 上運行的木馬或者惡意軟件，例如不怎么出名的 FinFisher启泣，仔細看看詳細說明涣脚，都會寫明 “需要越獄”。說實話我還沒見過面向 iOS 的不需要越獄的病毒或者木馬寥茫。
所以為代碼簽名和配置文件進行的這些麻煩設(shè)置并不是徒勞無功遣蚀。
