轉(zhuǎn)載于：
原文鏈接：Code Signing in Xcode 8
譯文鏈接：Xcode 8 中的代碼簽名
譯者： leoxu
代碼簽名和管理開發(fā)證書配置多年來一直是開發(fā)者揮之不去的煩惱权纤。為此我進行了大量的寫作和演講來幫助人們理解代碼簽名和開發(fā)證書配置到底是什么遣疯，以及如何才能對其較好的管理。所以你就可以想象得到當Matthew Firlik在今年的WWDC大會上《聯(lián)盟的平臺現(xiàn)狀》(53:30)上提到代碼簽名和開發(fā)證書配置時，我是有多么的驚訝和興奮丧枪。另外據(jù)其透露大會的日程安排包含了一完整的會議踢故，討論 Xcode App 簽名會有什么新的東西运挫，而且有兩個專注于于該話題的實際操作旗们。那么，Xcode 8 是否能擺平過去我在代碼簽名和開發(fā)證書配置上所受到的委屈呢? 確實好多了蔓涧。
在過去件已，代碼簽名被隱藏在Xcode的“構(gòu)建設(shè)置（Build Settings）”Tab中。CODE_SIGN_IDENTITY 和 PROVISIONING_PROFILE 兩個設(shè)置項很難對付而且它們相互之間沒有直接的鏈接元暴。開發(fā)者經(jīng)常會碰到“沒有找到匹配的開發(fā)正式配置（No Matching Provisioning Profiles Found）”錯誤篷扩，或者是一個“應(yīng)用程序代碼簽名授權(quán)文件中指定的權(quán)限不能匹配開發(fā)證書配置中指定的權(quán)限（The entitlements specified in your application’s Code Signing Entitlements file do not match those specified in your provisioning profile）∽蚰”錯誤, 這還是在他們幸運的情況下瞻惋。如果他們不夠走運，構(gòu)建倒是會成功援岩，但構(gòu)建出來的APP會在設(shè)備上運行失敗歼狼，或者奔潰掉，就因為缺少了App組權(quán)限享怀。Xcode 8 完全重構(gòu)的開發(fā)證書系統(tǒng)羽峰，其所做出的變化會解決所有這些問題。
現(xiàn)在你在如何對你的APP進行代碼簽名和證書配置上有了選擇權(quán) 。自動代碼簽名令許多人感到興奮梅屉。自動代碼簽名使用了一個新的由Xcode管理的值纱，獨立于你已經(jīng)創(chuàng)建的配置的專用配置。這確實是對令人感到可怕的“（解決問題）Fix Issue”按鈕進行的一個擴展坯汤，但確實是隔離獨立的虐唠，因此并不會影響到你現(xiàn)在已經(jīng)管理的配置。自動代碼簽名看起來很棒惰聂，而且它很有可能將會被大量的開發(fā)者使用到疆偿，
不過，這并非 Xcode 8 代碼簽名的改進中最令我感到興奮之處搓幌。在大型團隊中工作的人們或者沒有APP團隊和開發(fā)者門戶訪問權(quán)限的開發(fā)者晌梨，需要對其APP中的代碼簽名進行更細粒度的控制翘簇。自定義的代碼簽名提供了那樣的東西妹沙。自定義代碼簽名就是我們多年來如何對配置和APP進行管理的方式揩魂，它讓我們能對APP如何進行代碼簽名擁有最大程度的控制。 Xcode 8 將自定義代碼簽名和開發(fā)證書配置的從暗箱操作帶到了陽光下拐揭。沒有被埋沒在構(gòu)建設(shè)置（Build Settings）, 代碼簽名現(xiàn)在被通用（General）Tab的前頭和中心位置撤蟆。當“自動管理簽名（Automatically manage signing）”沒有被選中的時候，我們可以特別地選擇我們希望用于每個配置的開發(fā)證書配置投队。目前這個在其自身中沒有新東西枫疆，我們總是能夠在 構(gòu)建設(shè)置（Build Settings）Tab中做這個事情。真正棒的地方是 Xcode 8在這里所展示出來的機智敷鸦。配置的下拉列表可選項現(xiàn)在對合格配置和不合格配置進行了分組，前者在后者之上寝贡。這意味著完全或者通配符匹配捆綁標識符的配置將會顯示在那些不匹配的配置之上扒披。
不僅如此，如果你選擇了一個不匹配捆綁標識符的配置圃泡，現(xiàn)在就回得到一個錯誤消息碟案，告訴你具體出了什么問題。
這是同我們的過去相比的一個巨大改善颇蜡。XCode不再為我們隱藏細節(jié)价说。我們也不再為了找到哪里可能出了問題而東想西想。 Xcode 8 就會告訴你到底哪里出了問題风秤，不會張冠李戴鳖目，丟三落四。如果我們止步于此缤弦，我也會對代碼簽名的變化感到完全地滿足领迈。我知道我的描述聽起來像是一檔電視購物節(jié)目，但其實要更好!
Xcode 團隊已經(jīng)在報告導航（Report Navigator）中引入了一份新的報告，概述了Xcode為你所做的跟代碼簽名相關(guān)的事情狸捅。
這一報告完全揭掉了在Xcode用來同開發(fā)者門戶打交道的“API”的面紗衷蜓。老版本的Xcode會神不知鬼不覺的同Apple開發(fā)者門戶通信。現(xiàn)在則是當Xcode 8代你處理代碼簽名的時候尘喝，你可以具體地看到執(zhí)行了什么檢查磁浇，還有Xcode8做了什么來修復它識別出來的問題。
還有一件令我感到驚喜的事情就是有了一個新的構(gòu)建配置設(shè)置朽褪，PROVISIONING_PROFILE_SPECIFIER扯夭。過去你可能要根據(jù)名稱指定 PROVISIONING_PROFILE，而Xcode轉(zhuǎn)而會像后面這樣引用項目中的配置的UUID: PROVISIONING_PROFILE = “9b7bca71-29ac-44de-a96d-131d06b46501”鞍匾。如果帶有特定的那個UUID的配置丟失了交洗，Xcode沒辦法自己去擺平這個事情。你就不得不到構(gòu)建設(shè)置 （Build Settings ）中你的列表里去找到配置名稱橡淑，為了讓Xcode獲取到新的UUID构拳。 PROVISIONING_PROFILE_SPECIFIER 讓你可以指定開發(fā)證書配置名稱，而現(xiàn)在Xcode8將會在你的項目文件中保存后面這樣的東西: PROVISIONING_PROFILE_SPECIFIER = “9K9F9LCV74/KeyGrinder Dev”— 一個 Team ID 和配置名稱的組合(由于它是在開發(fā)者門戶中被命名的梁棠，并沒有必要時一個實際的文件名稱)置森。這樣Xcode就總是會使用這個名稱的最新的配置，而不管什么UUID了符糊。在你做過更新之后凫海，Xcode就不會再使用老的過時的配置。有了這個附加的功能男娄，Apple為我們放開了自己的 set_project_profiles腳本行贪。而沒有什么會比這更讓我們感到高興了。
最后一件我要重點提一提的事情就是Apple在會議和實際操作中都提到過的一個最佳實踐模闲。應(yīng)用程序發(fā)布是一個兩步走的過程：編譯然后進行代碼簽名建瘫。你的應(yīng)用首先應(yīng)該被編譯成一個 XCArchive 然后被導出成一個用于發(fā)布的IPA。因此尸折，你并不需要在你的發(fā)布配置中有確切的證書和配置設(shè)定啰脚。只要APP是使用正確的發(fā)布標識、優(yōu)化等等進行的編譯实夹，它就可以用一個AdHoc或者甚至是一個開發(fā)配置來簽名橄浓。你只需要在導出IPA或者提交到 App Store時使用正確的 App Store 或者 Enterprise 配置就行了。這可以幫助那些不必接觸發(fā)布憑證和證書的開發(fā)者避免遇到那些他們拿著沒有任何辦法的錯誤亮航。
Xcode 8 的發(fā)布讓我感覺Apple已經(jīng)在傾聽并提供我們所訴求的東西了荸实。
