什么是Code Signing
Code Signing是用于驗證一個APP是否由你創(chuàng)建的安全技術(shù)。一旦一個應(yīng)用被簽名，那么系統(tǒng)可以防御任何應(yīng)用的變化北秽，不管這個變化是認(rèn)為還是無意或惡意的代碼。
在安裝到設(shè)備上或者發(fā)布到App Store之前應(yīng)用必須用Apple認(rèn)證的證書進(jìn)行簽名氓仲。
概念描述
App ID
App ID用于標(biāo)識一個或者一組App，App ID應(yīng)該是和Xcode中的Bundle ID是一致的或者匹配的。App ID主要有以下兩種：
- 唯一App ID（Explicit App ID）敬扛，這種App ID用于唯一標(biāo)識一個應(yīng)用程序晰洒，例如com.ABC.demo1，標(biāo)識Bundle ID為com.ABC.demo1的程序啥箭。
- 通配符App ID（Wildcard App ID）谍珊，用于標(biāo)識一組應(yīng)用程序。例如可以表示所有應(yīng)用程序急侥，而com.ABC.可以表示以com.ABC開頭的所有應(yīng)用程序砌滞。
每創(chuàng)建一個App ID，我們都可以設(shè)置該App ID所使用的APP Services坏怪，也就是其所使用的額外服務(wù)贝润。每種額外服務(wù)都有著不同的要求，例如铝宵，如果要使用Apple Push Notification Services打掘，則必須是一個explicit App ID，以便能唯一標(biāo)識一個應(yīng)用程序鹏秋。下面是目前所有可選的服務(wù)和相應(yīng)的配置要求尊蚁。
Device
Device最簡單了，就是iOS設(shè)備拼岳。Devices中包含了該賬戶中所有可用于開發(fā)和測試的設(shè)備枝誊。 每臺設(shè)備使用UDID來唯一標(biāo)識况芒。
每個賬戶中的設(shè)備數(shù)量限制是100個惜纸。Disable 一臺設(shè)備也不會增加名額，只能在membership year 開始的時候才能通過刪除設(shè)備來增加名額绝骚。
證書（Certificate）
證書是用來給應(yīng)用程序簽名的耐版，只有經(jīng)過簽名的應(yīng)用程序才能保證他的來源是可信任的，并且代碼是完整的压汪， 未經(jīng)修改的粪牲。在Xcode Build Setting的Code Signing Identity中，你可以設(shè)置用于為代碼簽名的證書止剖。在申請Certificate之前腺阳，需要先申請一個Certificate Signing Request (CSR) 文件，而這個過程中實際上是生成了一對公鑰（Public Key）和私鑰（Private Key）穿香，保存在鑰匙串訪工具Keychain中亭引，你可以看到所有你持有的私鑰相對應(yīng)的證書。要用一個證書設(shè)置代碼簽名皮获，你必須擁有私鑰焙蚓，所以所有你擁有私鑰的證書都會被列在這里。如果你擁有一個證書的私鑰，你可以展開證書并將它的私鑰顯示出來购公。概括的講萌京，一個證書是一個公鑰加上許多附加信息，這些附加信息都是被某個認(rèn)證機構(gòu)（Certificate Authority 簡稱 CA）進(jìn)行簽名認(rèn)證過的宏浩，認(rèn)證這個證書中的信息是準(zhǔn)確無誤的知残。
代碼簽名正是使用這種基于非對稱秘鑰的加密方式，用私鑰進(jìn)行簽名绘闷，用公鑰進(jìn)行驗證橡庞。如下圖所示，在你keychain的login中存儲著相關(guān)的公鑰和私鑰印蔗，而證書中包含了公鑰扒最。
你只能用私鑰來進(jìn)行簽名，所以如果沒有了私鑰华嘹，就意味著你不能進(jìn)行簽名了吧趣，所以就無法使用這個證書了，此時你只能revoke之前的證書再申請一個耙厚。因此在申請完證書時强挫，最好導(dǎo)出并保存好你的私鑰。當(dāng)你想與其他人或其他設(shè)備共享證書時薛躬，把私鑰傳給它就可以了俯渤。私鑰保存在Mac中，而蘋果生成的Certificate中包含了公鑰型宝。當(dāng)用自己的私鑰對代碼簽名后八匠，蘋果就可以用證書中的公鑰來進(jìn)行驗證，確保是你對代碼進(jìn)行了簽名趴酣，而不是別人冒充你梨树，同時也確保代碼的完整性等。對于 iOS 開發(fā)來說這個認(rèn)證機構(gòu)就是蘋果的認(rèn)證部門 Apple Worldwide Developer Relations CA岖寞。認(rèn)證的簽名有固定的有效期抡四，這就意味著當(dāng)前系統(tǒng)時間需要被正確設(shè)置，因為證書是基于當(dāng)前時間進(jìn)行核對仗谆。這也是為什么將系統(tǒng)時間設(shè)定到過去會對 iOS 造成多方面破壞的原因之一指巡。
證書包含以下兩大類型：
1.Development
- App Development (1年)：用來開發(fā)和真機調(diào)試應(yīng)用程序。
- Push Development (1年)：用來調(diào)試Apple Push Notification
2.Production
- In-House and Ad Hoc (3年)：用來發(fā)布In-House和AdHoc的應(yīng)用程序隶垮。
- App Store ：用來發(fā)布提交App Store的應(yīng)用程序藻雪。
- MDM CSR
- Push Production (1年)：用來在發(fā)布版本中使用Apple Push Notification。
- Pass Type ID Certificate：用于通行證類證書
- Website Push ID Certificate
如果你要導(dǎo)出證書岁疼，例如為了備份阔涉，一定要記得展開證書那一條顯示出私鑰并將兩行都選中缆娃。
還有一種可以用來快速地顯示出你的系統(tǒng)中能用來對代碼進(jìn)行簽名的認(rèn)證的方法，那就是利用用途廣泛的命令行工具 security：
$ security find-identity -v -p codesigning
1) 01C8E9712E9632E6D84EC533827B4478938A3B15 "iPhone Developer: Thomas Kollbach (7TPNXN7G6K)"
Provisioning Profile
一個Provisioning Profile文件包含了上述的所有內(nèi)容：證書瑰排、App ID贯要、設(shè)備。
試想一下椭住，如果我們要打包或者在真機上運行一個應(yīng)用程序崇渗，我們首先需要證書來進(jìn)行簽名，用來標(biāo)識這個應(yīng)用程序是合法的京郑、安全的宅广、完整的等等；然后需要指明它的App ID些举，并且驗證Bundle ID是否與其一致跟狱；再次，如果是真機調(diào)試户魏，需要確認(rèn)這臺設(shè)備能否用來運行程序驶臊。而Provisioning Profile就把這些信息全部打包在一起，方便我們在調(diào)試和發(fā)布程序打包時使用叼丑，這樣我們只要在不同的情況下選擇不同的profile文件就可以了关翎。而且這個Provisioning Profile文件會在打包時嵌入.ipa的包里。
例如鸠信，如下圖所示纵寝，一個用于Development的Provisioning Profile中包含了該Provisioning Profile對應(yīng)的App ID，可使用的證書和設(shè)備星立。這意味著使用這個Provisioning Profile打包程序必須擁有相應(yīng)的證書爽茴，并且是將App ID對應(yīng)的程序運行到Devices中包含的設(shè)備上去。
一個配置文件是一組信息的集合贞铣，這組信息決定了某一個應(yīng)用是否能夠在某一個特定的設(shè)備上運行闹啦。配置文件可以用于讓應(yīng)用在你的開發(fā)設(shè)備上可以被運行和調(diào)試沮明，也可以用于內(nèi)部測試 (ad-hoc) 或者企業(yè)級應(yīng)用的發(fā)布辕坝。Xcode 會將你在 project setting 中選擇的配置文件打包進(jìn)應(yīng)用。前面提到了荐健，選擇配置文件是 Xcode 6 才提供的功能酱畅，在 Xcode 5 或更早版本中，配置文件是 Xcode 根據(jù)你選擇的簽名證書來選擇的江场。事實上同一個證書可以擁有多個不同的配置文件纺酸，因此讓 Xcode 自行選擇可能存在一些不確定性，最好的方式是你自主去選擇址否，在 Xcode 6 中終于提供了這個功能餐蔬。
如上所述碎紊，在一臺設(shè)備上運行應(yīng)用程序的過程如下：
Profile文件的種類是和所能創(chuàng)建的證書種類相關(guān)的，Provisioning Profile也分為Development和Distribution兩種：
- Development (1年)
- Distribution (1年)
- In House
- Ad Hoc
- App Store
iOS Team Provisioning Profile是第一次使用Xcode添加設(shè)備時樊诺，Xcode自動生成的仗考，它包含了Xcode生成的一個Wildcard App ID（*，匹配所有應(yīng)用程序）词爬，賬戶里面所有的Devices和所有Development Certificates秃嗜，如下圖所示。因此顿膨，team中的所有成員都可以使用這個iOS Team Provisioning Profile在team中的所有設(shè)備上調(diào)試所有的應(yīng)用程序锅锨。并且當(dāng)有新設(shè)備添加進(jìn)來時，Xcode會更新這個文件恋沃。
我們下面來仔細(xì)研究一下配置文件必搞。如果你要在自己的機器上找到配置文件，在這個目錄下 ~/Library/MobileDevice/Provisioning Profiles囊咏。Xcode 將從開發(fā)者中心下載的全部配置文件都放在了這里顾画。
不要驚訝，配置文件并不是一個 plist 文件匆笤，它是一個根據(jù)密碼訊息語法 (Cryptographic Message Syntax) 加密的文件（下文中會簡稱 CMS研侣，但不要用這個簡寫 Google，這不是一個很好的關(guān)鍵字）炮捧。如果你處理過 S/MIME 郵件或者證書你會對這種加密比較熟悉庶诡，詳細(xì)信息可以查看互聯(lián)網(wǎng)工程任務(wù)組 (IETF) 制定的 RFC 3852。
采用 CMS 格式進(jìn)行加密使得配置文件可以被設(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)用簽名的所有證書蹂安。如果你用了一個不在這個列表中的證書進(jìn)行簽名椭迎，無論這個證書是否有效，這個應(yīng)用都無法運行田盈。所有的證書都是基于 Base64 編碼符合 PEM (Privacy Enhanced Mail, RFC 1848) 格式的侠碧。要查看一個證書的詳細(xì)內(nèi)容，將編碼過的文件內(nèi)容復(fù)制粘貼到一個文件中去缠黍，像下面這樣：
-----BEGIN CERTIFICATE-----
MIIFnjCCBIagAwIBAgIIE/IgVItTuH4wDQYJKoZIhvcNAQEFBQAwgZYxCzA…
-----END CERTIFICATE-----`
然后讓 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è)備進(jìn)去就要重新下載新的配置文件。
Code Signing app的組成
一個已簽名的可執(zhí)行文件的簽名包含在 Mach-O 二進(jìn)制文件格式中茂蚓；對于例如腳本這樣的非 Mach-O 可執(zhí)行文件壕鹉，就存放在該文件系統(tǒng)的的擴(kuò)展屬性中。這種做法使得在 OS X 和 iOS 上的任何可執(zhí)行二進(jìn)制文件都可以被設(shè)置簽名：不論是動態(tài)庫煌贴，命令行工具御板，還是 .app 后綴的程序包锥忿。這也意味著設(shè)置簽名的過程實際上會改動可執(zhí)行文件的文件內(nèi)容牛郑，將簽名數(shù)據(jù)寫入二進(jìn)制文件中。
如果你擁有一個證書和它的私鑰敬鬓，那么用 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 二進(jìn)制文件。從 Executable 中的路徑信息你可以看出铝穷，這是一個以測試為目的的打包钠怯，所以是一個 Mach-O thin 的二進(jìn)制文件。
在一堆診斷信息中還包含了兩個非常有趣的條目曙聂。 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ìn)制文件已經(jīng)用證書設(shè)置好簽名。就像中世紀(jì)人用蠟來封印信封一樣朦佩，簽名就這樣封印了這個應(yīng)用并思。下面我們來檢查一下封印是否完好：
codesign --verify Example.app
就像大多數(shù) UNIX 工具一樣，沒有任何輸出代表簽名是完好的语稠。那么我下面破壞這個封印宋彼，只要修改一下這個二進(jìn)制文件：
$ echo 'lol' >> Example.app/Example
$ codesign --verify Example.app
Example.app: main executable failed strict validation
修改已經(jīng)簽名的應(yīng)用會破壞封印，從命令行輸出我們可以看到代碼簽名正如我們所預(yù)期一樣起到了作用仙畦。
程序包和其他資源文件
對于命令行工具和腳本來說输涕，只是一個可執(zhí)行文件被設(shè)置簽名，但是 iOS 和 OS X 的應(yīng)用和框架則是包含了它們所需要的資源在其中的慨畸。這些資源包括圖片和不同的語言文件莱坎，資源中也包括很重要的應(yīng)用組成部分例如 XIB/NIB 文件，存檔文件(archives)寸士，甚至是證書文件檐什。所以為一個程序包設(shè)置簽名時碴卧，這個包中的所有資源文件也都會被設(shè)置簽名。
為了達(dá)到為所有文件設(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í)行程序包系宜，例如擴(kuò)展 (extension)照激，是一個獨立的需要設(shè)置簽名的個體，在檢查簽名是否完整時應(yīng)當(dāng)被單獨對待盹牧。
授權(quán)機制
到目前為止俩垃，我們都假設(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)機制決定了哪些系統(tǒng)資源在什么情況下允許被一個應(yīng)用使用右遭。簡單的說它就是一個沙盒的配置列表，上面列出了哪些行為被允許缤削，哪些會被拒絕窘哈。
很可能你已經(jīng)猜到授權(quán)機制也是按照 plist 文件格式來列出的。Xcode 會將這個文件作為 --entitlements 參數(shù)的內(nèi)容傳給 codesign 亭敢，這個文件內(nèi)部格式如下:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>application-identifier</key>
<string>7TPNXN7G6K.ch.kollba.example</string>
<key>aps-environment</key>
<string>development</string>
<key>com.apple.developer.team-identifier</key>
<string>7TPNXN7G6K</string>
<key>com.apple.developer.ubiquity-container-identifiers</key>
<array>
<string>7TPNXN7G6K.ch.kollba.example</string>
</array>
<key>com.apple.developer.ubiquity-kvstore-identifier</key>
<string>7TPNXN7G6K.ch.kollba.example</string>
<key>com.apple.security.application-groups</key>
<array>
<string>group.ch.kollba.example</string>
</array>
<key>get-task-allow</key>
<true/>
</dict>
</plist>
在 Xcode 的 Capabilities 選項卡下選擇一些選項之后宵距，Xcode 就會生成這樣一段 XML。 Xcode 會自動生成一個 .entitlements 文件吨拗，然后在需要的時候往里面添加條目满哪。當(dāng)構(gòu)建整個應(yīng)用時，這個文件也會提交給 codesign 作為應(yīng)用所需要擁有哪些授權(quán)的參考劝篷。這些授權(quán)信息必須都在開發(fā)者中心的 App ID 中啟用哨鸭，并且包含在配置文件中，稍后我們會詳細(xì)討論這一點娇妓。在構(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)用添加進(jìn)了一個 App Group (比如說為了與擴(kuò)展 (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)容添加進(jìn)一個腳本拥诡，每次構(gòu)建應(yīng)用時用腳本檢查是否包含了推送服務(wù)的授權(quán)信息，以此確保推送服務(wù)工作正常氮发。在這里推送服務(wù)只是一個例子渴肉，你使用的服務(wù)越多，這樣的時候都添加推送通知的授權(quán)爽冕，以保證可以注冊推送通知仇祭。在新版本的 Xcode 6 之后，授權(quán)信息列表會以 Example.app.xcent 這樣的名字的文件形式包含在應(yīng)用包中颈畸。在我看來乌奇，這么做是為了在出現(xiàn)配置錯誤時提供更加有用的錯誤信息。
