I was under the impression that it was impossible to install an app store distribution build directly on a test device (without going through the actual App Store). I found multiple references to the following note by Apple (though I could not find the note itself in the current version of the iOS App Distribution Guide):
"App Store provisioning profiles do not allow for a distribution built application to be installed on an Apple device. To install your distribution ready application on a device, you must create an Ad Hoc provisioning profile."
Now consider the following: I have an Ad Hoc Distribution provisioning profile and an App Store Distribution provisioning profile. The ad hoc profile contains a list of provisioned devices, the app store profile doesn't. My (no jailbrake) device is included in the provisioned devices in the ad hoc profile. My build was signed with the app store profile. The resulting .ipa file was submitted to the App Store (and approved - but it is not publicly available yet). When I view the package contents of the .ipa file, I see that the embedded.mobileprovision is indeed the app store profile (without the provisioned devices list). When I drag this profile to my Xcode Organizer, I get an error that the profile cannot be installed because the device is not included in the profile (as expected). However, when I drag the .ipa file to my Xcode Organizer, the app installs on the device (and can be opened on the device afterwards). I tried this after making sure there were no other copies of the same app installed on the device. The same thing does not work when I use a different device that is not included in the provisioned devices of the ad hoc profile (even though the .ipa contains the app store profile without provisioned devices list).
Does anyone have a possible explanation for this? It seems that somehow a build signed with an app store profile can still be installed on a device included in the corresponding (same app identifier? same team identifier?) ad hoc profile. But if this would be the case, what is the point of making separate ad hoc builds?
I noticed this too and always meant to find out why it worked. It used to be true that you couldn’t install an App Store build but that appears to have changed, I’m guessing either in iOS6 or 5.
I found that I could only install App Store provisioning profile builds when a compatible Ad Hoc profile was already installed. Developer profiles did not work. I did not try wildcard profiles. So it looks like the Ad Hoc rules changed.
I can’t find the rules for installing an Ad Hoc build, but on the topic of launching the “Ad Hoc Provisioning Profiles in Depth” section of Apple’s App Distribution Guide says that
The app successfully launches if the app’s bundle ID matches the App ID, the signature matches the distribution certificate, and the device is in the device list of the ad hoc provisioning profile.
So I guess technically an AppStore builds meet these Ad Hoc requirements because it too is signed with the same distribution certificate. The use of “the” is misleading here because it makes it sound like iOS consults your embedded.mobileprovision
, which is untrue. It should read “an” ad hoc profile.
NB: The install only worked when the Ad Hoc profile was already installed on the device, so that’s one reason to make separate ad hoc builds.
NB: This is all conjecture, another explanation could be that Xcode handles the installation of the embedded.mobileprovision
and now continues when the AppStore profile installation fails.
This raises another question for me: why does iOS DWIM for App Store builds yet refuses to launch Ad Hoc builds with expired provisioning profiles when a perfectly valid replacement is installed?