我 知道 如何使用Appstore移动设备对应用进行签名，以及如何使用Appstore移动设备重新签署Adhoc签名的IPA。这不是我的问题。
我的问题是，您能 提交 Adhoc签名的IPA到Appstore / iTunesConnect，并通过Apple验证并最终通过Appstore分发。为什么？因此，我不必在每个Adhoc签名的候选版本IPA上存储冗余的Appstore签名的IPA，并且不必执行需要Mac机器的重新签名的额外步骤。
使用 Application Loader 时，它可以找到所有愚蠢的小错误，例如缺少图标和启动图像，但即使我通过Application Loader上传Adhoc签名的IPA，它不会抱怨非appstore移动配置（这很容易验证，就像图标一样）。
我在测试中也发现，当您采用Appstore签名的IPA（除非通过Appstore分发，您不应该在设备上安装），可以将其安装在测试设备上，如果设备上已有Adhoc配置文件（相同的AppID，相同的分发证书）。
因此，这让我觉得Apple在通过Appstore分发时会删除移动设备。
近三年前有一个类似的问题（已关闭），但如果实际有效，OP从未提供答案： Submitted app to appstore with adhoc profile 。
我希望从那以后有人真的尝试过确认结果。
答案 0 :(得分：22)
在你的主要问题中有一些有针对性的内心问题，我会随着时间的推移引起对每个部分的注意 - 一如既往，如果我错过了某些内容，我会乐意修改或澄清。我认为它只是一个严密保密的秘密，因为它工作的大部分推理都会回到加密细节，作为支持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签名版本并通过管道接受。老鹰眼的读者会注意到我的“是”＆＃39;内置逃生舱口盖 - 由于AdHoc与App Store中编码的数据配置配置文件几乎完全相同，而iTunesConnect实际上用于验证的这些文件的哪些部分，AdHoc配置配置文件呈现给与同一应用程序的AppStore版本相同。
如果AdHoc和App Store文件之间的配置格式发生变化，以明确区分两种类型的分发配置文件，或者Apple iTunesConnect工程师是否应更改服务器端验证规则，则此未记录的行为显然可能会停止工作。当然，我们都知道我们假设使用App Store配置文件，根据App Distribution Guide中的Developer文档＆gt;提交您的应用程序＆gt;关于商店供应配置文件（https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/SubmittingYourApp/SubmittingYourApp.html#//apple_ref/doc/uid/TP40012582-CH9-SW32）[强调添加]：
商店分发配置文件包含与您的一个或多个应用匹配的单个应用ID，以及分发证书。 对于iOS应用，您需要商店配置文件才能提交您的应用。
......但是这个其他途径现在适用。如果您确实选择使用此途径，您只需要知道它不是记录在案的行为，因此可能会在任何时间点发生变化，可能没有提前通知。由于它正在避开提交要求的边缘，因此至少可以为Apple更改配置或iTC验证要求的情况设置备份计划 - 墨菲定律将规定这些验证更改将在不合时宜的时间。
走出最佳实践＆＃39; Soapbox并转向技术方面...
为什么[这有效]？
您可能知道或不知道，配置文件只包含1个appId，一个或多个签名证书以及零个或多个测试设备。
相关阅读：我对What are code signing identities?的答案更长，更详细地说明了代码签名过程的各个部分。
在这种情况下，问题是“当文档说您需要拥有App Store个人资料时，为什么AdHoc个人资料会有效？＆＃39;
配置文件的内容包含加密签名的.plist，其中包含上面标识的信息以及一些其他元数据。在OS X计算机上，您可以打开终端并运行：
security cms -D -i path/to/AdHoc.mobileprovision
...并在单独的终端窗口中运行等效的App Store配置文件：
security cms -D -i path/to/AppStore.mobileprovison
这些命令会将配置文件的plist部分转储到各自的Terminal窗口。当您滚动浏览两个窗口的内容时，您将注意到以下部分是相同的：
个人资料的元数据不同，但这些完全是预期的差异，只对验证个人资料的有效性或人质询问个人资料有用：
要带走的重点是：
DeveloperCertificates块相同。ProvisionedDevices）到App Store个人资料的结构和格式。 DeveloperCertificates数组的内容是DER编码的X.509 iPhone分发证书 - 与您的钥匙串中的完全相同。请注意，此DER数据仅是分发证书公钥 - 私钥对的公共部分，并且只能由其他人用于验证应用程序的签名来自您 - 它不能用于重新签名二进制文件。
如果将DeveloperCertificates：Array：Data元素的内容粘贴到ASN.1解码器（http://lapo.it/asn1js/）中，并将输出元素与Keychain中包含的分发证书中编码的信息进行比较，那么＆＃ 39;在通过证书，标识符和配置文件工具提交证书签名请求后，它会发现它是您从Apple下载的公共分发证书的精确副本。
由于AdHoc和App Store配置文件都使用与其签名身份相同的公钥证书，因此在生成应用程序的签名时，它们本质上使用相同的私钥。 这意味着使用AdHoc配置文件签名时生成的签名在功能上与使用App Store配置文件签名时生成的签名相同
当Apple在提交过程中在iTunes Connect上执行签名验证时，AdHoc签名的加密签名和App Store签名的加密签名将成功验证Apple已存档的分发证书，因为两个配置文件都由相同的配置文件支持分发证书。
所以签名匹配，但为什么AdHoc个人资料中的额外信息不会提交提交内容？
您的原始问题表明您已熟悉iOS＆＃39;应用安装政策。为了将来绊倒这个答案的人的利益，我将简要总结一下：
除非特别允许，否则iOS会依据“拒绝”进行操作。政策。也就是说，iOS假定您不允许安装应用，除非特定的＆＃39;授予＆＃39;已被允许。对于来自App Store的设备，该应用程序的签名包括Apple的App Store标识，iOS具有特定的“授权”标识。特权。 AdHoc默认安装在“拒绝”下。策略和开发或 AdHoc 个人资料的ProvisionedDevices部分是具体的“授权”。特权。如果满足以下所有条件，应用程序将安装在App Store外部：
ExpirationDate尚未通过，当前时间不在CreationDate ProvisionedDevices中包含与设备的UDID完全匹配的条目。如上所述，应用程序标识和签名信息在App Store个人资料和Ad Hoc个人资料之间是相同的 - 添加ProvisionedDevices仅用于添加这些＆＃39; grant＆＃39;外部（App Store外部）分发机制的权限。事实证明，iTunes Connect / Application Loader验证目前仅验证 Distribution 配置文件是否用于应用程序的签名，而不是使用的配置文件是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配置文件。同样，如果更新了配置文件格式（例如版本= 2），他们可以添加一个明确调出配置文件类型的新元素，如果它不是App Store类型，则自动拒绝。它可能看起来像这样：
<key>ProfileType</key>
<integer>1</integer>
其中整数值可以是1,2或3，具体取决于所使用的配置文件类型，与Info.plist中用于识别支持的设备系列的格式一致（仅限iPhone，仅限iPad或普遍）。这将澄清有关识别构建类型的其他问题。
相关阅读：
因此，这让我觉得Apple在通过Appstore分发时会删除移动设备。
是的，他们这样做！如果你查看你提交的应用程序的存档版本，你会发现该应用程序的内容包含embedded.mobileprovision - 如果你从App Store下载相同的版本，你会发现该文件丢失。 Apple仅在提交和审核过程中使用embedded.mobileprovision来验证您应用的内容。当应用程序处理App Store＆＃39;组装最终包装并移除嵌入的配置文件。