隨着蘋果對於企業分發證書的頻繁吊銷和日益收緊，代簽名行業也隨之迭代出了黑科技，即所謂的超級簽名。從整個安裝流程上來看，超級簽名少了在設置裏面信任企業證書的步驟，體驗上要比企業分發更簡單和容易接受，同時分發價格也貴的離譜，不禁讓人好奇這新瓶裏面到底裝的是什麼酒。今天就來幫大家解析一下其中的門門道道，以及這套機制的技術難點。
簽名原理簽名原理其實就一句話，使用了蘋果提供給開發者的Ad-Hoc分發通道，把安裝設備當做開發設備進行分發。既然簽名用是 Ad-Hoc ，那麼 Ad-Hoc 所具有的優劣勢也一併繼承了下來：
優勢：
直接分發，安裝即可運行，不需要用戶做企業證書的信任操作
目前穩定，不會有證書吊銷導致的業務風險(後續蘋果政策風險非常高)
缺點：
單開發者賬號的iPhone設備數量只有100個，導致分發成本非常高(99美元/1年/100個設備)
開發者賬號需要預先寫入安裝設備的UDID，在工具鏈不通的情況下，獲取用戶的UDID相對困難和繁瑣，而且手動寫入UDID不存在商用可行性，當然目前這個缺點被解決了
整體架構接下來我們就看看整套機制是如何進行的：
設備安裝描述文件後，會向服務器發送設備的UDID。
服務器收到UDID後，將UDID註冊到某個開發者賬號下。
再生成簽名用的描述文件，給IPA簽名。
然後iPA傳Server，使用itms-services方式讓用戶下載。
技術細節使用配置文件獲取UDID蘋果公司允許開發者通過IOS設備和Web服務器之間的某個操作，來獲得IOS設備的UDID(包括其他的一些參數)。這裏的一個概述：
在你的Web服務器上創建一個.mobileconfig的XML格式的描述文件；
用戶在所有操作之前必須通過某個點擊操作完成.mobileconfig描述文件的安裝；
服務器需要的數據，比如：UDID，需要在.mobileconfig描述文件中配置好，以及服務器接收數據的URL地址；
當用戶設備安裝描述文件後，設備會回調你設置的URL，如果你的URL返回302跳轉的話，Safari瀏覽器會跳轉到你所給的地址；
Apple Developer Center 自動化工具接下來的關鍵點就是如何在獲取到用戶的UDID之後，秒級完成註冊新的開發者設備+更新Provisioning Profile的。 這裏我們需要藉助開源工具(Spaceship)：
Spaceship公開了Apple Developer Center的API，而且執行速度比解析開發者Web頁面快兩個數量級，從而在非常短的時間內搞定Provisioning Profile。 這個框架解決了整套機制的關鍵問題，成爲整個工具鏈的基石。其實某平臺早就完成了UDID獲取和應用簽名分發的技術儲備，只差這套API。下面是解析開發者Web頁面和直接訪問API的速度對比圖：
Cool!!!!!!! 非常棒！再次爲Spaceship鼓掌如何自動簽名封包此處其實應該有一萬個解決方案，通過命令行腳本/Python腳本/或者其他第三方都能實現。這裏推薦使用 Sigh 這個框架來解決這個問題。
Sigh的用法和配置都非常簡單，一個純命令工具，豐富的配置選項(自行查閱文檔)，活躍的社區，完全夠用了。直接上演示圖：
OTA 分發已簽名的應用emmmm 此處也應該有一萬個解決方案，那就選擇 AppDeploy 吧。入選原因非常簡單，這個框架有Logo(看臉的社會就是那麼真實...)。
可視化部署流程如下圖(同時支持命令行調用)：
結語通過開源社區的力量，我們成功搞清了整個機制上的關鍵技術點，必須要說fastlane團隊非常優秀的提供了工具鏈關鍵一環(Spaceship)，從而使Ad-Hoc自動分發成爲可能。蘋果對於App的分發審覈管控可以說是非常嚴苛，這背後既有安全考慮，也有壟斷利益。但無論如何，對於終端用戶都是利大於弊的措施，App審覈保護了無數的手機用戶免受惡意程序的侵害。 個人強烈反對這種繞過審覈的分發形式。同時我要指出，分發平臺以這種情況繞過蘋果的審覈是嚴重違反 APPLE 開發商計劃許可協議的3.3.3條款：