將Ad-hoc應用程序提交到Appstore / iTunesConnect

Question

我知道如何使用Appstore移動設備簽署應用程序，以及如何使用Appstore移動設備重新簽署Adhoc簽名的IPA。 這不是我的問題。

我的問題是，您是否可以向Appstore / iTunesConnect 提交 Adhoc簽名的IPA，並通過Apple驗證並最終通過Appstore分發。 為什么？ 因此，我不必在每個Adhoc簽名的候選版本IPA上存儲冗余的Appstore簽名的IPA，並且不必執行需要Mac計算機的重新簽名的額外步驟。

使用Application Loader時 ，它能夠找到所有愚蠢的小錯誤，比如丟失圖標和啟動圖像，但即使我通過Application Loader上傳Adhoc簽名的IPA， 它也不會抱怨非appstore移動設備 （這是很容易驗證，就像圖標一樣）。

我在測試中也發現，當您使用Appstore簽名的IPA（除非通過Appstore分發，您不應該在設備上安裝），可以將其安裝在測試設備上，前提是設備已經有Adhoc配置文件（相同的AppID，相同的分發證書）。

因此，這讓我覺得Apple在通過Appstore分發時只是刪除了移動設備。

從差不多3年前就有一個類似的問題（已關閉），但如果OP確實有效，則OP從未提供答案： 使用adhoc配置文件向appstore提交應用程序 。

我希望從那以后有人真的試過它確認結果。

Answer 1

在你的主要問題中有一些有針對性的內在問題，我會隨時關注每個部分 - 一如既往，如果我錯過了某些內容，我會樂意修改或澄清。 我認為它只是一個嚴密保密的秘密，因為它工作的大部分推理都會回到加密細節，作為支持Apple配置的公鑰基礎設施系統的一個功能 - 這個東西變得非常快，所以有些人認為它是[黑暗魔法。 希望這會對正在發生的事情有所啟發！

TL; DR版本

是的，你可以，但它在技術上是一個不受支持的用例，可能隨時改變。 這是有效的，因為iTunes Connect選擇驗證的信息不包括App Store和AdHoc分發配置文件之間的單一區別因素。 由於這在技術上不是允許的配置，因此我主張至少有一個備份計划，因為Apple可能會隨時更改iTunes Connect驗證政策，從而打破此提交邊緣情況。

現在對於好奇，這是故事的其余部分......

您是否可以將Adhoc簽名的IPA提交給Appstore / iTunesConnect，並通過Apple驗證並最終通過Appstore [？]分發

截至iTunesConnect和Application Loader的特定迭代（2014年9月4日/ Xcode 5.1.1），是的，您可以提交AdHoc簽名版本並通過管道接受它。 老鷹眼的讀者會注意到我的'是'帶有內置的逃生艙 - 由於AdHoc與App Store中編碼的數據配置配置文件幾乎完全相同，而iTunesConnect實際上用於驗證這些文件的哪些部分，AdHoc配置文件以與同一應用程序的AppStore版本相同的方式呈現給交付管道。

如果AdHoc和App Store文件之間的配置格式發生變化，以明確區分兩種類型的分發配置文件，或者Apple iTunesConnect工程師是否應更改服務器端驗證規則，則此未記錄的行為顯然可能會停止工作。 當然，我們都知道我們應該使用App Store配置文件，根據應用程序分發指南>提交應用程序>關於商店配置文件中的開發人員文檔（ https://developer.apple.com/library/ios/ documentation / IDEs / Conceptual / AppDistributionGuide / SubmittingYourApp / SubmittingYourApp.html＃// apple_ref / doc / uid / TP40012582-CH9-SW32 ）[強調補充]：

商店分發配置文件包含與您的一個或多個應用程序匹配的單個App ID以及分發證書。 對於iOS應用，您需要商店配置文件才能提交您的應用。

......但是這條其他大道現在有效。 如果您確實選擇使用此途徑，您只需要知道它不是記錄在案的行為，因此可能會在任何時間點發生變化，可能沒有提前通知。 由於它正在避開提交要求的邊緣，因此至少可以為Apple更改配置或iTC驗證要求的情況設置備份計划 - 墨菲定律將規定這些驗證更改將在最不合適的時間發生。

走出“最佳實踐”肥皂盒並轉向技術方面......

為什么[這有效]？

您可能知道或不知道，配置文件正好由1個appId，一個或多個簽名證書以及零個或多個測試設備組成。

相關閱讀 ：我對代碼簽名身份有什么更長的答案？ 這更詳細地說明了代碼簽名過程的各個部分。

在這種情況下，問題是“當文檔說您需要擁有App Store配置文件時，為什么AdHoc配置文件會起作用？”

配置文件的內容包含加密簽名的.plist，其中包含上面標識的信息以及一些其他元數據。 在OS X計算機上，您可以打開終端並運行：

security cms -D -i path/to/AdHoc.mobileprovision

...並在單獨的終端窗口中運行等效的App Store配置文件：

security cms -D -i path/to/AppStore.mobileprovison

這些命令會將配置文件的plist部分轉儲到各自的Terminal窗口。 當您滾動瀏覽兩個窗口的內容時，您會注意到以下部分是相同的：

• AppIDName
• AppliationIdentifierPrefix
• DeveloperCertificates
• 權益
• TeamIdentifier
• 版

配置文件的元數據是不同的，但這些是完全預期的差異，僅對驗證配置文件有效性或詢問配置文件的人員有用：

• 創建日期
• 截止日期
• 名稱
• 傳輸TimeToLive
• UUID

要點的重點是：

• DeveloperCertificates塊在兩個配置文件之間是相同的 。
• AdHoc配置文件僅將信息（ ProvisionedDevices ） 添加到App Store配置文件的結構和格式。

DeveloperCertificates數組的內容是DER編碼的X.509 iPhone分發證書 - 與您的鑰匙串中的完全相同。 重要的是要注意，此DER數據只是您的分發證書公鑰 - 私鑰對的公共部分，並且它只能被其他人用來驗證來自您的應用程序的簽名 - 它不能用於重新簽名二進制文件像你一樣

如果將DeveloperCertificates：Array：Data元素的內容粘貼到ASN.1解碼器（ http://lapo.it/asn1js/ ）中，並將輸出元素與Keychain中包含的分發證書中編碼的信息進行比較，在通過證書，標識符和配置文件工具提交證書簽名請求后，您會發現它是您從Apple下載的公共分發證書的精確副本。

由於AdHoc和App Store配置文件都使用與其簽名標識相同的公鑰證書，因此它們在生成應用程序簽名時固有地使用相同的私鑰。 這意味着使用AdHoc配置文件簽名時生成的簽名在功能上與使用App Store配置文件簽名時生成的簽名相同

當Apple在提交過程中在iTunes Connect上執行簽名驗證時，AdHoc簽名的加密簽名和App Store簽名的加密簽名將成功驗證Apple已存檔的分發證書，因為兩個配置文件都由相同的分發證書支持。

因此簽名匹配，但為什么AdHoc配置文件中的額外信息不會提交提交？

您的原始問題表明您已熟悉iOS的應用安裝政策。 為了將來絆倒這個答案的人的利益，我將簡要總結一下：

iOS采用'拒絕 - 除非特別允許的'政策。 也就是說，iOS假定您不允許安裝應用程序，除非允許使用特定的“授權”。 對於來自App Store的設備，該應用程序的簽名包括Apple的App Store標識，iOS具有特定的“授權”權限。 默認情況下，AdHoc安裝屬於“拒絕”策略，而開發或AdHoc配置文件的ProvisionedDevices部分是特定的“授權”權限。 如果滿足以下所有條件，應用程序將安裝在App Store外部：

• 應用程序的加密簽名有效
• 應用程序的嵌入式配置文件的加密簽名仍然有效（配置文件未被篡改）
• 應用程序的嵌入式配置文件的ExpirationDate尚未通過，當前時間不在CreationDate之前
• 嵌入的配置文件或安裝到設備的配置文件與建議安裝的AppId匹配。
• 嵌入的配置文件或安裝到設備的配置文件在ProvisionedDevices中包含與設備的UDID完全匹配的條目。

如上所述，App Store配置文件和Ad Hoc配置文件之間的應用程序標識和簽名信息是相同的 - ProvisionedDevices添加僅用於為外部（App Store外部）分發機制添加這些“grant”權限。 事實證明，iTunes Connect / Application Loader驗證目前僅驗證分發配置文件是否用於應用程序的簽名，而不是使用的配置文件是App Store配置文件而不是AdHoc配置文件。

這可以歸結為這樣一個事實：版本1（plist中的ala Version塊）是AdHoc和App Store分發配置文件之間唯一的區別因素是ProvisionedDevices塊的存在與否。 事實證明，截至今天，這不是 Apple在查詢所使用的配置文件時所尋找的細節，因此二進制文件傳遞了應用驗證的自動部分。 他們肯定會檢查配置文件中的AppId是否與App聲明的內容匹配，簽名身份是否與用於簽署二進制文件的內容相符，到期日期以及使用的任何權利與應用程序的自動掃描中找到的權限相匹配，此外您在原始問題中突出顯示的項目（iTunes Connect和info.plist之間的版本檢查，圖標存在，圖像尺寸等）

假設，在隨后的iTunes Connect / Application Loader更新中，他們可以開始檢查提交的二進制文件中存在的embedded.mobileprovision配置文件中是否缺少此密鑰，並自動拒絕提交，理由是App Store配置文件不存在用過的。 同樣，如果更新了配置文件格式（例如Version = 2），他們可以添加一個顯式調出配置文件類型的新元素，如果它不是App Store類型則自動拒絕。 它可能看起來像這樣：

<key>ProfileType</key>
<integer>1</integer>

其中整數值可以是1,2或3，具體取決於使用的配置文件類型，與Info.plist中用於識別支持的設備系列（僅限iPhone，僅限iPad或通用）的格式一致。 這將澄清有關識別構建類型的其他問題。

相關閱讀：

• 如何以編程方式檢測供應配置文件是用於開發還是分發
• 檢查app是否在運行時是ad-hoc | dev | app-store構建

因此，這讓我覺得Apple在通過Appstore分發時只是刪除了移動設備。

是的他們做到了！ 如果您查看您提交的應用程序的存檔版本，您會發現該應用程序的內容包含embedded.mobileprovision - 如果您從App Store下載相同版本，您將發現該文件丟失。 Apple僅在提交和審核過程中使用embedded.mobileprovision來驗證您應用的內容。 當應用程序為“處理App Store”時，將組裝最終包，並刪除嵌入的配置文件。