将Ad-hoc应用程序提交到Appstore / iTunesConnect
我知道如何使用Appstore移动设备签署应用程序，以及如何使用Appstore移动设备重新签署Adhoc签名的IPA。 这不是我的问题。
我的问题是，你能否将 Adhoc签名的IPA 提交给Appstore / iTunesConnect，并通过Applevalidation并最终通过Appstore分发。 为什么？ 因此，我不必在每个Adhoc签名的候选版本IPA上存储冗余的Appstore签名IPA，并且不必执行需要Mac计算机的重新签名的额外步骤。
当使用Application Loader时 ，它能够找到所有愚蠢的小错误，比如丢失图标和启动图像，但即使我通过Application Loader上传Adhoc签名的IPA， 它也不会抱怨非appstore移动设备 （这是很容易validation，就像图标一样）。
我在测试中也发现，当你采用Appstore签名的IPA（你不应该在设备上安装，除非通过Appstore分发）时，可以将它安装在测试设备上，前提是设备已经有Adhoc配置文件（相同的AppID，相同的分发证书）。
所以，这让我觉得Apple只是在通过Appstore分发时删除了移动设备。
从差不多3年前就有一个类似的问题（已关闭），但如果OP确实有效，则OP从未提供答案： 使用adhoc配置文件向appstore提交应用程序 。
我希望从那以后有人真的试过它确认结果。
在你的主要问题中有一些有针对性的内心问题，我会随时关注每个部分 – 一如既往，如果我错过了某些内容，我会很乐意修改或澄清。 我认为它只是一个严密保密的秘密，因为它工作的大部分推理都回到加密细节作为公钥基础设施系统的function，支持Apple的配置 – 这个东西变得非常快，所以有些人认为它是[黑暗魔法。 希望这会对正在发生的事情有所启发！
TL; DR版本
是的，你可以，但它在技术上是一个不受支持的用例，可能随时改变。 这是有效的，因为iTunes Connect选择validation的信息不包括App Store和AdHoc分发配置文件之间的单一区别因素。 由于这在技术上不是允许的配置，我主张至少有一个备份计划，因为Apple可能会随时更改iTunes Connectvalidation政策，从而打破此提交边缘案例。
现在对于好奇，这是故事的其余部分……
您是否可以将Adhoc签名的IPA提交给Appstore / iTunesConnect，并通过Applevalidation并最终通过Appstore [？]分发
截至iTunesConnect和Application Loader的特定迭代（2014年9月4日/ Xcode 5.1.1），是的，您可以提交AdHoc签名版本并通过管道接受。 老鹰眼的读者会注意到我的’是’带有一个内置的逃生舱 – 由于AdHoc与App Store中编码的数据，配置文件几乎完全相同，而iTunesConnect实际上用于validation这些文件的哪些部分，AdHoc配置文件以与同一应用程序的AppStore版本相同的方式呈现给交付管道。
如果AdHoc和App Store文件之间的配置格式发生变化，以明确区分两种类型的分发配置配置文件，或者Apple iTunesConnect工程师是否应更改服务器端validation规则，则此未记录的行为显然可能会停止工作。 当然，我们都知道我们应该使用App Store配置文件，根据应用程序分发指南>提交应用程序>关于商店供应配置文件中的开发人员文档（ https://developer.apple.com/library/ios/ documentation / IDEs / Conceptual / AppDistributionGuide / SubmittingYourApp / SubmittingYourApp.html＃// apple_ref / doc / uid / TP40012582-CH9-SW32 ）[强调补充]：
商店分发配置文件包含一个与您的一个或多个应用程序匹配的应用程序ID，以及一个分发证书。 对于iOS应用，您需要商店配置文件才能提交您的应用。
……但是这条其他大道现在有效。 如果您确实选择使用此途径，您只需要知道它不是记录在案的行为，因此可能会在任何时间点发生变化，可能没有提前通知。 由于它正在避开提交要求的边缘，至少可以为Apple更改配置或iTCvalidation要求的情况设置备份计划 – 墨菲定律将规定这些validation更改将在最不合适的时间发生。
走出“最佳实践”肥皂盒并转向技术方面……
为什么[这有效]？
正如您可能知道或不知道的那样，供应配置文件由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
- 版
配置文件的元数据是不同的，但这些是完全预期的差异，仅对validation配置文件有效性或询问配置文件的人员有用：
- 创建日期
- 截止日期
- 名称
- 传输TimeToLive
- UUID
要点的重点是：
- 两个配置文件之间的
DeveloperCertificates块相同 。 - AdHoc配置文件仅将信息（
ProvisionedDevices） 添加到App Store配置文件的结构和格式。
DeveloperCertificates数组的内容是DER编码的X.509 iPhone分发证书 – 与您的钥匙串中的完全相同。 重要的是要注意，此DER数据只是您的分发证书公钥 – 私钥对的公共部分，并且它只能被其他人用来validation来自您的应用程序的签名 – 它不能用于重新签名二进制文件像你一样
如果将DeveloperCertificates：Array：Data元素的内容粘贴到ASN.1解码器（ http://lapo.it/asn1js/ ）中，并将输出元素与Keychain中包含的Distribution证书中编码的信息进行比较，在通过证书，标识符和配置文件工具提交证书签名请求后，您会发现它是您从Apple下载的公共分发证书的精确副本。
由于AdHoc和App Store配置文件使用与其签名标识相同的公钥证书，因此它们在生成应用程序签名时固有地使用相同的私钥。 这意味着使用AdHoc配置文件签名时生成的签名在function上与使用App Store配置文件签名时生成的签名相同
当Apple在提交过程中在iTunes Connect上执行签名validation时，AdHoc签名的加密签名和App Store签名的加密签名将成功validationApple已存档的分发证书，因为两个配置文件都由相同的分发证书支持。
因此签名匹配，但为什么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”权限。 事实certificate，iTunes Connect / Application Loadervalidation目前仅validation分发配置文件是否用于应用程序的签名，而不是使用的配置文件是App Store配置文件而不是AdHoc配置文件。
这归结为以下事实：版本1（plist中的ala Version块）是AdHoc和App Store分发配置文件之间唯一的区别因素是ProvisionedDevices块的存在与否。 事实certificate，截至今天，这不是 Apple在查询所使用的配置文件时所寻找的细节，因此二进制文件传递了应用validation的自动部分。 他们肯定会检查配置文件中的AppId是否与App声称的匹配，签名身份与用于签署二进制文件的内容匹配，到期日期以及使用的任何权利与应用程序的自动扫描中找到的权限相匹配，此外您在原始问题中突出显示的项目（iTunes Connect和info.plist之间的版本检查，图标存在，图标尺寸等）
假设，在随后的iTunes Connect / Application Loader更新中，他们可以开始检查提交的二进制文件中存在的embedded.mobileprovision配置文件中是否存在此密钥，并自动拒绝提交，理由是App Store配置文件不是用过的。 同样，如果更新了配置文件格式（例如Version = 2），他们可以添加一个显式调出配置文件类型的新元素，如果它不是App Store类型则自动拒绝。 它可能看起来像这样：
ProfileType 1
其中整数值可以是1,2或3，具体取决于所使用的配置文件的类型，与Info.plist中用于识别支持的设备系列（仅限iPhone，仅限iPad或通用）的格式一致。 这将澄清有关识别构建类型的其他问题。
相关阅读：
- 如何以编程方式检测供应配置文件是用于开发还是分发
- 检查app是否在运行时是ad-hoc | dev | app-store构建
所以，这让我觉得Apple只是在通过Appstore分发时删除了移动设备。
是的他们做到了！ 如果您查看您提交的应用程序的存档版本，您会发现该应用程序的内容包含embedded.mobileprovision – 如果您从App Store下载相同版本，您将发现该文件丢失。 Apple仅在提交和审核过程中使用embedded.mobileprovision来validation应用程序的内容。 当应用程序为“处理App Store”时，将组装最终包，并删除嵌入的配置文件。