Enterprise App Update Distribution on iOS 8

I have an enterprise app that I'm distributing via an itms URL:

itms-services://?action=download-manifest&url=itms-services://?action=download-manifest&url=https://$MY_PLIST_URL.plist

On iOS 7, both downloads and updates work fine. On iOS 8, however, I get the error:

LoadExternalDownloadManifestOperation: Ignore manifest download, already have bundleID: com.mycom.MyApp

In my plist, I have

<key>bundle-identifier</key>
<string>com.mycom.MyApp</string>
<key>bundle-version</key>
<string>0.2.2</string>

and on my app on iOS 8, I'm running version 0.2.1

I've also encountered this problem with our app distribution. We were able to fix this issue by 'faking' the bundle identifier inside the .plist using for download distribution, keeping our ipa bundle identifier the same.

For example, in your plist:

<key>bundle-identifier</key>
<string>com.mycom.MyApp</string>
<key>bundle-version</key>
<string>0.2.2</string>

change com.mycom.MyApp to com.mycom.MyApp.ios8fix

The app will be installed using a new app icon, which will disappear after install.

If you already have an install of the app, you will even see a new app icon during install. After the installation this icon disappears, but your already existing version of the app will be updated. With a clean install the installation icon will disappear and the installed application icon will appear in place.

It looks like iOS 8 is caching the bundle identifiers and compares the requested installs with these cached ones. Most of the times you'll only see an popup asking for install, but nothing happens.

As Sean already noticed, this appears with xCode 6 GM and the official iOS 8 version. Devices which never installed your application before will have no problems to install the app.

This worked better for me, no need to touch your manifest or other trickery (perfect for Xcode Server where the plist is auto-generated):

1. Download iExplorer (http://www.macroplant.com/iexplorer/)
2. Plug your device
3. Delete all the files in "Media > Downloads"
4. Restart device

This resets the device caches, now you can install your app as usual.

I am having the same problem. I reproduced it by:

1. Having my application installed while upgrading from iOS 7 to iOS 8 GM

2. Removing it in iOS 8

3. Trying to install it via itms-services: with the same bundle name

When I tried to change the bundle-identifier in the server plist (not in the applications Info.plist), it worked (application was downloaded an no "shadow" icon remained). But it looks like an apple bug.

The accepted solution no longer works on iOS9.

My understanding is that Apple has closed a serious iOS security hole by preventing adhoc binaries from replacing stock apps or apps downloaded from the App Store. See this article for background (CVE-2015-3722/3725 and CVE-2015-3725):

https://www.fireeye.com/blog/threat-research/2015/06/three_new_masqueatt.html

Taken the security implications, I wouldn't expect this behaviour to change in future IOS versions. Alternative options seem to be:

• delete the App Store version before installing the adhoc
• distribute the adhoc as 'new' app by changing the bundle id in both the app and the distribution plist
• use TestFlight

What Gil said seems to be correct, but more specifically, I found that I also needed to increment the bundle-version string in the server.plist:

    <key>bundle-version</key>
    <string>3.2.2</string>

This at least allows you to accomplish an OTA install.

(Sorry... Would've added to comments, but I'm too much a n00b.)

Take a look over this answer and this answer.

You can fix this issue without any hacks, for iOS8 you have to include in the assets key of the manifest .plist file the display-image and full-size-image keys. They were available in Xcode 5 when saving an archive for enterprise and add-hoc deployment, but were not required.

I have created a gist on github with the template for the install-manifet.plist file.

This a bug first found in iOS8 Beta5. And it was still not fixed by Apple in GM seed and official iOS8.0 version. More discussons could be found here

The current workaround being tested by myself:

• If you don't care the contents in your device: do a clean restore in DFU mode of the device
• If you want your things back
  1. Backup your iOS Device in iTunes before restore (without Ad-Hoc/enterprise app)
  2. After restored your device cleanly, install your Ad-Hoc/enterprise app
  3. Restore your backup from iTunes
  4. Now you are free to delete those Ad-Hoc/enterprise apps and reinstall them.

Problem solved by changing the bundle identifier in plist.

Normally, after tapping the itms link, it will shows the desktop which shows the icon installation. However, for my iOS 8.0 device, after tapping the itms link, it will not change to the installation page but installation is already working behind.

This is extreme but if you can't change your bundle identifier, which I couldn't, restoring your iPhone through iTunes to the latest iOS 8 and restoring from a backup fixes the problem.

Same problem exists on iOS 10 beta 1.

>Dec 31 19:01:32 iphone-6s itunesstored[98] : LoadExternalDownloadManifestOperation: Ignore manifest download, already have bundleID: com.***************.ios with phase: SSDownloadPhaseWaiting

One thing that I do not understand here is that the date is December 31st in the XCode device log, however, device has correct date and time configured.

Update: Guys from HockeyApp notified Apple about this problem during WWDC and fix should come in the next seed.

If you build your iOS apps with a build script and you were previously using PackageApplication with the --sign flag then that may be causing problems. The --sign flag doesn't work any longer when building on 10.10 and removing it got all of our iOS apps installing again.

see: https://devforums.apple.com/thread/251624?tstart=0

Make sure you have a full internet access.

I was facing the same problem with OTA installation and IOS8. Because i'm behind a corporate proxy, the solutions above didn't work until I set manual proxy settings (not needed in IOS7) to solve that problem.

I have just encountered this issue on a device running 8.1, upgrading the device to 8.3 has resolved the issue. So either the bug is no longer present in 8.3.... or the act of upgrading cleared the cached data anyway.