将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具有特定的"授权"权限.即席默认秋季"拒绝"政策下安装和ProvisionedDevices一个部分开发或即席轮廓是特定的"批"的权限.如果满足以下所有条件,应用程序将安装在App Store外部:

• 应用程序的加密签名有效
• 应用程序的嵌入式配置文件的加密签名仍然有效(配置文件未被篡改)
• 应用程序的嵌入式配置文件ExpirationDate尚未通过,当前时间不在之前CreationDate
• 嵌入的配置文件或安装到设备的配置文件与建议安装的AppId匹配.
• 嵌入的配置文件或安装到设备的配置文件包含ProvisionedDevices与设备的UDID完全匹配的条目.

如上所述,应用程序标识和签名信息在App Store配置文件和Ad Hoc配置文件之间是相同的 - 添加ProvisionedDevices服务仅为外部(App Store外部)分发机制添加这些"授权"权限.事实证明,iTunes Connect/Application Loader验证目前仅验证分发配置文件是否用于应用程序的签名,而不是使用的配置文件是App Store配置文件而不是AdHoc配置文件.

这可以归结为这样一个事实:版本1(Versionplist中的ala 块)是AdHoc和App Store分布配置文件之间唯一的区别因素是ProvisionedDevices块的存在与否.事实证明,截至今天,这不是 Apple在查询所使用的配置文件时所寻找的细节,因此二进制文件传递了应用验证的自动部分.他们肯定会检查配置文件中的AppId是否与App声明的内容匹配,签名身份是否与用于签署二进制文件的内容相符,到期日期以及使用的任何权利与应用程序的自动扫描中找到的权限相匹配,此外您在原始问题中突出显示的项目(iTunes Connect和info.plist之间的版本检查,图标存在,图像尺寸等)

可以想像,在随后的iTunes Connect中/加载应用程序更新,他们可以开始检查的情况下在这个关键的embedded.mobileprovision中存在的剖面提交的二进制文件,并自动拒绝对未使用的应用程序商店的个人资料为由提交.同样,如果更新了配置文件格式(例如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"时,将组装最终包,并删除嵌入的配置文件.