将Ad-hoc应用程序提交到Appstore / iTunesConnect [英] Submitting Ad-hoc app to Appstore / iTunesConnect
问题描述
我 知道 如何使用Appstore移动设备对应用进行签名，以及如何使用Appstore移动设备重新签署Adhoc签名的IPA。这不是我的问题。
I know how to sign an app with Appstore mobile provision, and how to re-sign an Adhoc-signed IPA with Appstore mobile provision. This is not my question.
我的问题是，你能 提交 Adhoc签名的IPA到Appstore / iTunesConnect ，让它通过Apple验证，最终通过Appstore分发。为什么？因此，我不必在每个Adhoc签名的候选版本IPA上存储冗余的Appstore签名的IPA，并且不必执行需要Mac计算机的额外重新签名步骤。
My question is, can you submit Adhoc-signed IPA to Appstore / iTunesConnect, and have it pass Apple verification and eventually be distributed through Appstore. Why? So that I don't have to store a redundant Appstore-signed IPA along every Adhoc-signed release candidate IPA, and don't have to do the extra step of re-signing that requires a Mac machine.
使用 Application Loader 时，它能够找到所有愚蠢的小错误，例如丢失图标和启动图像，但即使我通过应用程序上传Adhoc签名的IPA Loader，它没有抱怨非appstore移动配置（这很容易验证，就像图标一样）。
When using Application Loader, it is able to find all the stupid little errors, like missing icons and launch images, but even when I upload Adhoc-signed IPA through Application Loader, it doesn't complain about non-appstore mobile provision (which is very easy to verify, just like icons).
我有在我的测试中也发现，当你采用Appstore签名的IPA（你不应该在设备上安装，除非通过Appstore分发），可以将它安装在测试设备上，前提是设备已经有关于它的特设配置文件（相同的AppID，相同的分发证书）。
I have also found out in my testing, that when you take an Appstore-signed IPA (which you are not supposed to be able to install on devices unless distributed through Appstore), it is possible to install it on testing devices, provided the device already has Adhoc provision profile on it (same AppID, same distribution cert).
因此，这让我觉得Apple在通过Appstore分发时会删除移动设备。
So, this makes me think Apple just strips out mobile provision when distributing through Appstore.
大约3年前有一个类似的问题（已关闭），但如果实际有效，OP从未提供答案： 将应用程序提交到带有adhoc配置文件的appstore 。
There was a similar question (closed) from almost 3 years ago, but the OP never provided an answer if it had actually worked: Submitted app to appstore with adhoc profile.
我希望有人从那以后实际上已经尝试过确认结果。
I hope someone since then had actually tried with it confirmed results.
推荐答案
有一些目标在你的主要问题中的内心问题，我会随时关注每个部分 - 一如既往，如果我错过了某些内容，我会乐意修改或澄清。我认为它只是一个严密保密的秘密，因为它工作的大部分推理都回到加密细节作为公钥基础设施系统的功能，支持Apple的配置 - 这个东西变得非常快，所以有些人认为它是[黑暗魔法。希望这会对正在发生的事情有所启发！
There are a few targeted inner questions within your main question, I'll call attention to each part as we go -- as always, I'll be happy to revise or clarify if I miss something. I suppose it is only a closely guarded secret because much of the reasoning for it working come back to cryptographic details as a function of the Public Key Infrastructure system that backs Apple's provisioning -- This stuff gets deep fast so it is considered by some to be [dark] magic. Hopefully this will shine some light on what is going on!
TL; DR版本
是的，您可以，但从技术上讲，它是一个不受支持的用例，可能随时更改。这是有效的，因为iTunes Connect选择验证的信息不包括App Store和AdHoc分发配置文件之间的单一区别因素。由于这在技术上不是允许的配置，因此我主张至少有一个备份计划，因为Apple可能随时更改iTunes Connect验证政策，打破此提交边缘情况。
Yes you can, but it is technically an unsupported use case that may change at any time. This works because what information iTunes Connect chooses to validate does not include the single differentiating factor between an App Store and AdHoc distribution provisioning profile. Since this is technically not a permitted configuration, I'd advocate for at least having a backup plan since Apple may change iTunes Connect validation policy at any time breaking this submission edge case.
现在好奇，这是故事的其余部分......
你能提交Adhoc签名的IPA吗？到Appstore / iTunesConnect，让它通过Apple验证并最终通过Appstore分发[？]
截至iTunesConnect和Application Loader的特定迭代（2014年9月4日/ Xcode 5.1.1），是的，您可以提交AdHoc签名版本并通过管道接受。老鹰眼的读者会注意到我的'是'带有一个内置的逃生舱 - 由于AdHoc与App Store中编码的数据，配置文件几乎完全相同，而iTunesConnect实际上用于验证这些文件的哪些部分，AdHoc配置文件以与同一应用程序的AppStore版本相同的方式呈现给交付管道。
As of this specific iteration of iTunesConnect and the Application Loader (4 Sept 2014 / Xcode 5.1.1), yes you can submit an AdHoc signed build and have it accepted through the pipeline. The eagle-eyed reader will note that my 'Yes' comes with a built-in escape hatch -- Because of the data encoded in AdHoc vs App Store provisioning profiles is nearly identical coupled with what parts of these files iTunesConnect is actually using for validation, an AdHoc provisioning profile presents to the delivery pipeline in the same manner as the AppStore version of the same app.
如果配置格式在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 ）[强调补充]：
Should the provisioning format change between AdHoc and App Store files to explicitly differentiate the two types of Distribution provisioning profiles or should Apple iTunesConnect engineers change server-side validation rules, it is distinctly possible that this undocumented behavior will stop working. Of course we all know that we are supposed to use the App Store provisioning profile, as per Developer documentation in the 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) [emphasis added]:
商店分发配置文件包含一个与您的一个或多个应用程序匹配的应用程序ID，以及一个分发证书。 对于iOS应用，您需要商店配置资料才能提交您的应用。
...但是这其他大道现在有效。如果您确实选择使用此途径，您只需要知道它不是记录在案的行为，因此可能会在任何时间点发生变化，可能没有提前通知。由于它正在避开提交要求的边缘，至少可以为Apple更改配置或iTC验证要求的情况设置备份计划 - 墨菲定律将规定这些验证更改将在最不合适的时间发生。
...but this other avenue works for now. If you do choose to use this avenue, you just need to be aware that it is not the documented behavior and thus would be subject to change at any point in time, likely without advanced notice. Since it is skirting the edges of submission requirements it would probably be good to at least have a backup plan setup for the case of Apple changing provisioning or iTC validation requirements -- Murphy's law would dictate that these validation changes would happen at the most inopportune time.
走出'最佳实践'肥皂盒并转向技术方面......
Stepping off the 'Best Practice' Soapbox and turning to the technical side of things...
为什么[这样做有效]？
您可能知道或不知道，配置文件只包含1个appId，一个或多个签名证书，以及零个或多个测试设备。
As you may or may not know, provisioning profiles are composed of exactly 1 appId, one or more signing certificates, and zero or more test devices.
相关阅读：我对什么是代码签名身份？，它们更详细地说明了代码签名过程的各个部分。
Related Reading: I've got a longer answer to What are code signing identities? that speaks in more detail to the parts of the codesign process.
在这种情况下，问题是'为什么AdHoc配置文件在t时有效他的文档说你需要有一个App Store配置文件吗？'
In this case the question is 'why do AdHoc profiles work when the documentation says you need to have an App Store profile?'
配置文件的内容包含一个加密签名的.plist，其中包含上面提到的信息，还有一些额外的信息。元数据。在OS X计算机上，您可以打开终端并运行：
The guts of a provisioning profile contain a cryptographically signed .plist that includes the information identified above, plus some additional metadata. On an OS X machine you can open Terminal and run:
security cms -D -i path / to / AdHoc.mobileprovision
...并在单独的终端窗口中运行等价的App Store配置文件：
...and in a separate Terminal window run the App Store profile equivalent:
security cms -D -i path / to / AppStore.mobileprovison
这些命令将转出plist的plist部分配置配置文件到各自的终端窗口。当您滚动浏览两个窗口的内容时，您会注意到以下部分是相同的：
These commands will dump out the plist portion of the provisioning profile to their respective Terminal windows. When you scroll through the contents of both windows you will note that the following sections are identical:
- AppIDName
- AppliationIdentifierPrefix
- DeveloperCertificates
- 权利
- TeamIdentifier
- 版本
- AppIDName
- AppliationIdentifierPrefix
- DeveloperCertificates
- Entitlements
- TeamIdentifier
- Version
配置文件的元数据是不同的，但这些完全是预期的差异，只对验证配置文件的有效性或人类询问个人资料：
The profile's metadata are different, but those are entirely expected differences that only matter for validating profile validity, or for humans interrogating the profile:
- CreationDate
- ExpirationDate
- 姓名
- TimeToLive
- UUID
- CreationDate
- ExpirationDate
- Name
- TimeToLive
- UUID
突出点指向带走的是：
-
DeveloperCertificates块相同两个配置文件之间。 - AdHoc配置文件仅添加信息（
ProvisionedDevices）到结构和格式App Store个人资料。
- The
DeveloperCertificatesblocks are identical between both profiles. - The AdHoc profile only adds information (
ProvisionedDevices) to the structure and format of the App Store profile.
DeveloperCertificates 数组的内容是DER编码的X.509 iPhone分发证书 - 与钥匙串中的证书完全相同。重要的是要注意，此DER数据只是分发证书公钥 - 私钥对的公共部分，并且只能由其他人用来验证来自您的应用程序的签名 - 它可以不能用来辞去二进制文件。
The contents of the DeveloperCertificates array is the DER encoded X.509 iPhone Distribution Certificate -- The exact same as the one in your keychain. Is is important to note that this DER data is only the public portion of your Distribution certificate public-private keypair, and it can only be used by others to authenticate the application's signature came from you -- It can not be used to resign a binary as you.
如果将DeveloperCertificates：Array：Data元素的内容粘贴到ASN.1解码器中（ http://lapo.it/asn1js/ ）并将输出元素与包含在分发证书中的分发证书中编码的信息进行比较钥匙串，您会发现它是您通过证书，标识符和配置文件工具提交证书签名请求后从Apple下载的公共分发证书的完整副本。
If you paste the contents of DeveloperCertificates:Array:Data element into an ASN.1 decoder (http://lapo.it/asn1js/) and compare the elements of the output to the information encoded in the Distribution certificate included in the Keychain, you'll find that it is an exact copy of the public Distribution certificate you downloaded from Apple after submitting your Certificate Signing Request though the Certificates, Identifiers, and Profiles tool.
因为AdHoc和App Store配置文件都使用与其签名身份相同的公钥证书，所以它们本身就是usi生成应用程序签名时使用相同的私钥。 这意味着使用AdHoc个人资料签名时生成的签名在功能上与使用App Store个人资料签名时生成的签名相同
Because both the AdHoc and App Store provisioning profiles use the same public key certificate as their signing identity, they are inherently using the same private key when generating the application's signature. This means that the signature generated when signing with an AdHoc profile is functionally identical to one generated when signing with the App Store profile
当Apple执行时在提交过程中，iTunes Connect上的签名验证，AdHoc签名的加密签名和App Store签名的加密签名将成功验证Apple已存档的分发证书，因为两个配置文件都由相同的分发证书支持。
When Apple performs a signature validation on iTunes Connect during the submission process, both and AdHoc signed cryptographic signature and an App Store signed cryptographic signature will successfully validate against the Distribution Certificate Apple has on file as both provisioning profiles are backed by the same Distribution Certificate.
所以签名匹配，但为什么AdHoc配置文件中的额外信息没有提交提交？
您的原始问题表明您熟悉iOS的应用安装政策。为了将来绊倒这个答案的人的利益，我将简要总结一下：
Your original question suggests that you have familiarity with iOS' app install policies. For the benefit of someone stumbling across this answer in the future I'll briefly summarize:
iOS采用'拒绝 - 除非特别允许的'政策。也就是说，iOS假定您不允许安装应用程序，除非允许使用特定的授权。对于来自App Store的设备，该应用程序的签名包括Apple的App Store标识，iOS具有特定的授权权限。默认情况下，AdHoc安装属于拒绝政策，开发或 AdHoc 配置文件的 ProvisionedDevices 部分属于特定的授予权限。如果满足以下所有条件，应用程序将安装在App Store外部：
iOS operates on a 'deny-all unless specifically permitted' policy. That is, iOS assumes you are not allowed to install an app unless a specific 'grant' has been allowed. For devices coming from the App Store, the app's signature includes Apple's App Store identity for which iOS has a specific 'grant' privilege. AdHoc installs by default fall under the 'deny' policy and the ProvisionedDevices section of a Development or AdHoc profile are the specific 'grant' privileges. The app will install outside of the App Store if all of the following hold true:
- 应用程序的加密签名有效
- 应用程序的嵌入式配置文件的加密签名仍然有效（配置文件未被篡改）
- 应用程序的嵌入式配置文件的
ExpirationDate尚未通过且当前时间不在CreationDate - 嵌入的个人资料或个人资料之前安装到设备上的是与建议安装的AppId匹配。
- 嵌入的配置文件或安装到设备的配置文件包含
ProvisionedDevices 与设备的UDID完全匹配。
- The application's cryptographic signature is valid
- The application's embedded provisioning profile's cryptographic signature is still valid (the profile hasn't been tampered with)
- The application's embedded provisioning profile's
ExpirationDatehasn't passed and the current time isn't before theCreationDate - The embedded profile or a profile installed to the device match the AppId being proposed for installation.
- The embedded profile or a profile installed to the device contain an entry in
ProvisionedDevicesthat exactly match the device's UDID.
如上所述，应用程序标识和签名信息在App Store配置文件和和Ad Hoc配置文件 - 添加 ProvisionedDevices 仅用于添加对外部（App Store外部）分发机制的授予权限。事实证明，iTunes Connect / Application Loader验证目前仅验证 Distribution 配置文件是否用于应用程序的签名，而不是使用的配置文件是App Store配置文件而不是AdHoc配置文件。
As we saw above, the app identity and signing information is identical between an App Store profile and and Ad Hoc profile -- the addition of ProvisionedDevices serves only to add these 'grant' privileges for an external (outside of App Store) distribution mechanism. It turns out that iTunes Connect / Application Loader validation is currently only validating that a Distribution profile was used for the app's signature, not that the profile that was used was an App Store profile instead of an AdHoc profile.
这可以归结为版本1（ala 版本块中的plist）唯一的事实AdHoc和App Store分发配置文件之间的区别因素是 ProvisionedDevices 块的存在与否。事实证明，截至今天，这个不是在查询所使用的配置文件时Apple寻找的细节，因此二进制文件传递了应用验证的自动部分。他们肯定会检查配置文件中的AppId是否与App声称的匹配，签名身份与用于签署二进制文件的内容匹配，到期日期以及使用的任何权利与应用程序的自动扫描中找到的权限相匹配，此外您在原始问题中突出显示的项目（iTunes Connect和info.plist之间的版本检查，图标存在，图标尺寸等）
This boils down to the fact that the as of Version 1 (ala Version block in the plist) the only differentiating factor between AdHoc and App Store distribution profiles is the presence or absence of the ProvisionedDevices block. It turns out that as of today, this is not a detail that Apple looks for when interrogating the profile that was used, thus the binary passes the automated portions of app verification. They definitely do check that the AppId in the profile matches what the App claims, that the signing identity matches what was used to sign the binary, expiration dates, and any entitlements used match what is found in the automated scan of the app, in addition to the items you highlighted in your original question (version checks between iTunes Connect and the info.plist, iconography presence, iconography sizes, etc.)
假设，在随后的iTunes Connect / Application Loader更新，他们可以在提交的二进制文件中存在的 embedded.mobileprovision 配置文件中开始检查此密钥的缺席自动拒绝提交，理由是未使用App Store配置文件。同样，如果更新了配置文件格式（例如Version = 2），他们可以添加一个显式调出配置文件类型的新元素，如果它不是App Store类型则自动拒绝。它可能看起来像这样：
Hypothetically, in a subsequent iTunes Connect / Application Loader update, they could start checking for the absence of this key in the embedded.mobileprovision profile that exists within the submitted binary and auto-reject the submission on the grounds that an App Store profile was not used. Similarly, if the provisioning profile format was updated (ex. Version=2) they could add a new element that explicitly calls out the type of profile and auto-reject if it isn't an App Store type. It could perhaps look like this:
<key>ProfileType</key>
<integer>1</integer>
其中整数值可以是1,2或3，具体取决于所使用的配置文件类型，与Info.plist等用于识别支持的设备系列（仅限iPhone，仅限iPad或通用）的格式一致。这将澄清有关识别构建类型的其他问题。
Where the integer value could be 1, 2 or, 3 depending on the type of profile in use, consistent with the formats used in things like Info.plist for identifying supported device families (iPhone-only, iPad-only, or Universal). This would clarify other questions that have been asked about identifying the type of build.
相关阅读：
- 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时，将组装最终包，并删除嵌入的配置文件。
Yes they do! If you look at archived versions of the apps you submitted you'll find that the contents of the app contain embedded.mobileprovision -- if you then go download the same version from the App Store, you'll find that file missing. Apple only uses embedded.mobileprovision to verify the contents of your app during the submission and review process. When the app is 'Processing for App Store' the final package is assembled and the embedded profile is removed.
这篇关于将Ad-hoc应用程序提交到Appstore / iTunesConnect的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
