您的主要问题中有一些有针对性的内在问题，我会在进行过程中提醒大家注意每个部分 - 一如既往，如果我遗漏了什么，我会很乐意修改或澄清。我想这只是一个严密保护的秘密，因为它工作的大部分原因都回到了加密细节作为支持 Apple 配置的公钥基础设施系统的功能——这些东西变得很快，所以有些人认为它是[黑暗魔法。希望这能对正在发生的事情有所启发！
TL;DR 版本
是的，您可以，但从技术上讲，这是一个不受支持的用例，可能随时更改。这是因为 iTunes Connect 选择验证的信息不包括 App Store 和 AdHoc 分发配置文件之间的单一区别因素。由于这在技术上是不允许的配置，因此我主张至少有一个备份计划，因为 Apple 可能会随时更改 iTunes Connect 验证策略，打破这种提交边缘情况。
现在对于好奇的人来说，这里就是故事的其余部分......
您能否将 Adhoc 签名的 IPA 提交到 Appstore / iTunesConnect，并让它通过 Apple 验证并最终通过 Appstore 分发[？]
在 iTunesConnect 和应用程序加载器的这个特定迭代（2014 年 9 月 4 日/Xcode 5.1.1）中，是的，您可以提交一个 AdHoc 签名的构建并通过管道接受它。目光敏锐的读者会注意到，我的“是”带有一个内置的逃生舱口——因为 AdHoc 与 App Store 配置文件中编码的数据几乎相同，再加上 iTunesConnect 实际用于验证的这些文件的哪些部分，AdHoc 供应配置文件以与同一应用的 AppStore 版本相同的方式呈现给交付管道。
如果 AdHoc 和 App Store 文件之间的配置格式发生变化，以明确区分这两种分发配置文件，或者 Apple iTunesConnect 工程师更改服务器端验证规则，那么这种未记录的行为很可能会停止工作。当然，我们都知道我们应该使用 App Store 配置文件，根据 App Distribution Guide > Submitting Your App > About Store Provisioning Profiles (https://developer.apple.com/library/ios/documentation/IDEs/Conceptual/AppDistributionGuide/SubmittingYourApp/SubmittingYourApp.html#//apple_ref/doc/uid/TP40012582-CH9-SW32) 中的开发人员文档 [强调添加]:
商店分发配置文件包含与您的一个或多个应用匹配的单个应用 ID，以及分发证书。 对于 iOS 应用，您需要一个商店配置文件来提交您的应用。
...但是其他途径目前有效。如果您确实选择使用此途径，您只需要注意它不是记录在案的行为，因此可能会随时更改，可能不会提前通知。由于它避开了提交要求的边缘，因此至少为 Apple 更改配置或 iTC 验证要求的情况设置一个备用计划可能会很好——墨菲定律将规定这些验证更改将在最不合时宜的时间发生.
走出“最佳实践”肥皂盒，转向技术方面...
为什么[这行得通]？
您可能知道也可能不知道，配置文件恰好由 1 个 appId、一个或多个签名证书以及零个或多个测试设备组成。
相关阅读：我对What are code signing identities? 有一个更长的答案，它更详细地说明了协同设计过程的各个部分。
在这种情况下，问题是“当文档说您需要拥有 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 部分转储到它们各自的终端窗口。当您滚动浏览两个窗口的内容时，您会注意到以下部分是相同的：
- AppID 名称
- 应用标识符前缀
- 开发者证书
- 权利
- 团队标识符
- 版本
配置文件的元数据是不同的，但这些完全是预期的差异，仅对验证配置文件有效性或对查询配置文件的人很重要：
要带走的要点是：
-
DeveloperCertificates 块在两个配置文件之间相同。
- AdHoc 配置文件仅向 App Store 配置文件的结构和格式添加信息 (
ProvisionedDevices)。
DeveloperCertificates 数组的内容是 DER 编码的 X.509 iPhone 分发证书——与钥匙串中的完全相同。需要注意的是，这个 DER 数据只是你的 Distribution 证书公私钥对的公共部分，它只能被其他人用来验证应用程序的签名来自你——它可以不习惯像你一样辞去二进制文件。
如果您将 DeveloperCertificates:Array:Data 元素的内容粘贴到 ASN.1 解码器 (http://lapo.it/asn1js/) 中，并将输出的元素与钥匙串中包含的分发证书中编码的信息进行比较，您会发现它是您通过证书、标识符和配置文件工具提交证书签名请求后从 Apple 下载的公共 分发 证书的精确副本。
由于 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 仅用于为外部（应用程序之外）添加这些“授予”权限商店）分配机制。事实证明，iTunes Connect / Application Loader 验证当前仅验证 Distribution 配置文件用于应用程序的签名，而不是使用的配置文件是 App Store 配置文件而不是 AdHoc 配置文件。
这归结为这样一个事实，即版本 1（在 plist 中的ala Version 块）AdHoc 和 App Store 分发配置文件之间的唯一区别因素是 ProvisionedDevices 块的存在或不存在。事实证明，截至今天，这不是 Apple 在询问所使用的配置文件时寻找的细节，因此二进制文件通过了应用程序验证的自动部分。他们肯定会检查配置文件中的 AppId 是否与应用程序声明的内容相匹配，签名身份是否与用于签署二进制文件、到期日期的内容相匹配，以及所使用的任何权利是否与应用程序自动扫描中发现的内容相匹配，此外到您在原始问题中突出显示的项目（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 处理”时，将组装最终包并删除嵌入的配置文件。