ios - 将临时应用提交到Appstore/iTunesConnect

Question

我知道如何使用Appstore移动提供对应用程序进行签名，以及如何使用Appstore移动提供对Adhoc签名的IPA进行重新签名。这不是我的问题。

我的问题是，您可以提交 Adhoc签名的IPA到Appstore/iTunesConnect，并使其通过Apple验证并最终通过Appstore分发。为什么？这样我就不必在每个Adhoc签名的发行候选IPA上存储一个由Appstore签名的IPA冗余，也不必执行需要Mac机器的重新签名的额外步骤。

当使用 Application Loader 时，它能够找到所有愚蠢的小错误，例如缺少图标和启动图像，但是即使我通过Application Loader上载Adhoc签名的IPA ，它也不会提示非应用商店移动供应(非常容易验证，就像图标一样)。

我在测试中还发现，当您使用由Appstore签名的IPA(除非通过Appstore分发，否则您不应将其安装在设备上)，可以将其安装在测试设备上，前提是该设备已经具有Adhoc供应配置文件(相同的AppID，相同的分发证书)。

因此，这让我认为Apple在通过Appstore进行分发时只是去除了移动服务。

在将近3年前有一个类似的问题(已关闭)，但是OP确实提供了答案，但实际上没有起作用: Submitted app to appstore with adhoc profile 。

我希望从那时起有人实际尝试过证实的结果。

Answer 1

在您的主要问题中有一些针对性的内在问题，我们将逐步关注每个部分-与往常一样，如果我错过了某些内容，我将很乐意进行修改或澄清。我认为这只是一个受严格保护的 secret ，因为它的工作原理在很大程度上取决于加密细节，这是支持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签名的构建并通过管道接受它。鹰眼的读者会注意到，我的"is"带有内置的逃生舱口盖-由于AdHoc与App Store设置配置文件中编码的数据几乎完全相同，并且iTunesConnect实际使用了这些文件的哪些部分进行验证，AdHoc供应配置文件以与同一应用程序的AppStore版本相同的方式呈现给交付管道。

如果在AdHoc和App Store文件之间更改配置格式以明确区分两种分发配置文件类型，或者Apple iTunesConnect工程师更改服务器端验证规则，则很明显，这种未记录的行为将停止工作。当然，我们都知道，按照应用分发指南>提交您的应用>关于商店供应配置文件(https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/SubmittingYourApp/SubmittingYourApp.html#//apple_ref/doc/uid/TP40012582-CH9-SW32)[强调添加]中的开发人员文档，我们应该使用来使用App Store供应配置文件:

A store distribution provisioning profile contains a single App ID that matches one or more of your apps, and a distribution certificate. For iOS apps, you need a store provisioning profile to submit your app.

...但是这条大道暂时有效。如果您确实选择使用此途径，则只需要知道它不是已记录的行为，因此随时可能会更改，而可能没有事先通知。由于它绕过提交要求的边缘，因此至少应为苹果公司更改供应或iTC验证要求的情况制定备份计划可能会比较好-墨菲定律规定，这些验证更改将在最不合时宜的时间发生。

走出“最佳实践” Soapbox并转向技术方面...

为什么[这项工作]？

您可能知道，也可能不知道，配置文件完全由1个appId，一个或多个签名证书以及零个或多个测试设备组成。

相关阅读:我对 What are code signing identities?的回答更长，它更详细地介绍了代码签名过程的各个部分。

在这种情况下，问题是“当文档说您需要拥有App Store配置文件时，为什么AdHoc配置文件有效？”

供应配置文件的内容包含一个加密签名的.plist，该列表包括上面标识的信息以及一些其他元数据。在OS X机器上，您可以打开Terminal并运行:
security cms -D -i path/to/AdHoc.mobileprovision
...并在单独的终端窗口中运行等效的App Store配置文件:
security cms -D -i path/to/AppStore.mobileprovison
这些命令会将转储配置文件的plist部分转储到它们各自的终端窗口中。滚动浏览两个窗口的内容时，您会注意到以下部分是相同的:

AppIDName

AppliationIdentifierPrefix

开发人员证书

权利

TeamIdentifier

版本

个人资料的元数据是不同的，但这些完全是预期的差异，仅对验证个人资料的有效性或询问个人的个人资料很重要:

CreationDate

ExpirationDate

名称

TimeToLive

UUID

要注意的要点是:

两种配置文件之间的DeveloperCertificates块为相同的。

仅AdHoc配置文件将信息(ProvisionedDevices)添加到App Store配置文件的结构和格式中。

DeveloperCertificates数组的内容是DER编码的X.509 iPhone发行证书-与钥匙串(keychain)中的证书完全相同。重要的是要注意，此DER数据仅是 发行版证书的public-private key 对的公共(public)部分，并且只能由其他人用来验证来自您的应用程序签名-不能用于辞职。与您一样的二进制文件。

如果将DeveloperCertificates:Array:Data元素的内容粘贴到ASN.1解码器( http://lapo.it/asn1js/)中，然后将输出的元素与钥匙串(keychain)中包含的分发证书中编码的信息进行比较，您会发现它是准确的您通过“证书”，“标识符”和“配置文件”工具提交“证书签名请求”后从Apple下载的公共(public) 分发证书的副本。

由于AdHoc和App Store的供应配置文件都使用相同的公钥证书作为其签名身份，因此在生成应用程序签名时，它们固有地使用相同的私钥。 这意味着使用AdHoc配置文件签名时生成的签名与使用App Store配置文件签名时生成的签名在功能上相同

当Apple在提交过程中在iTunes Connect上执行签名验证时，AdHoc签名的加密签名和App Store签名的加密签名都将根据Apple存档的分发证书成功进行验证，因为两个配置文件均由同一分发证书作为后盾。

因此，签名匹配，但是为什么AdHoc配置文件中的额外信息不会使提交失败？

您最初的问题表明您已熟悉iOS的应用安装政策。为了将来有人绊倒这个答案的好处，我将简要总结一下:

iOS会按照“所有拒绝，除非有明确允许”政策运行。也就是说，iOS假定除非允许特定的“赠予”，否则不允许您安装应用程序。对于来自App Store的设备，应用程序的签名包括iOS拥有其特定“授予”特权的Apple的App Store身份。默认情况下，AdHoc安装属于“拒绝”策略，并且Development或AdHoc配置文件的 ProvisionedDevices部分是特定的“授予”特权。如果满足以下所有条件，则该应用程序将安装在App Store之外:

应用程序的加密签名有效

应用程序的嵌入式供应配置文件的加密签名仍然有效(该配置文件未被篡改)

应用程序的嵌入式配置文件的ExpirationDate尚未通过，并且当前时间不在CreationDate

之前

嵌入式配置文件或安装到设备的配置文件与建议安装的AppId相匹配。

嵌入式配置文件或安装到设备的配置文件在ProvisionedDevices中包含与设备的UDID完全匹配的条目。

正如我们在上面看到的，App Store配置文件和Ad Hoc配置文件之间的应用程序标识和签名信息是相同的-添加 ProvisionedDevices仅用于为外部(在App Store之外)分发机制添加这些“授予”特权。事实证明，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配置文件中此 key 的 缺少，并基于应用商店配置文件不存在而自动拒绝提交用过的。同样，如果供应配置文件格式已更新(例如Version = 2)，则他们可以添加一个新元素，该元素显式调出配置文件的类型，如果不是App Store类型则自动拒绝。它可能看起来像这样:

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

其中的整数值可以是1、2或3，具体取决于所使用的配置文件的类型，与用于识别受支持的设备系列(仅iPhone，仅iPad或Universal)的Info.plist之类的格式一致。这将阐明有关标识构建类型的其他问题。

相关阅读:

How to detect that a provisioning profile is for development or distribution, programmatically

Check if app is ad-hoc|dev|app-store build at run time

因此，这让我认为Apple在通过Appstore进行分发时只是去除了移动服务。

是的，他们愿意!如果查看提交的应用程序的存档版本，您会发现该应用程序的内容包含 embedded.mobileprovision-如果您随后从App Store下载相同版本，则会发现该文件丢失。 Apple仅在提交和审阅过程中使用Embedded.mobileprovision来验证您的应用程序的内容。当应用程序为“为App Store处理”时，将组装最终包装并删除嵌入式配置文件。