wireless iphone app distribution - problem with itms-services protocol

I've followed all the directions from Apple and some other blog posts. I've archived the app, made .plist and .ipa files, put them on a server and linked to them. I can install the provisioning profile just fine. But when I click on the link to install the app (in safari on the iphone), nothing happens. No error message. Nothing. This is what the link looks like:

<a href="itms-services://?action=download-manifest&url=http://mydomain.com/test/myApp.plist">Install the app</a>

Any idea why this isn't working? It seems the itms-services protocol is just dead. MIME type开发者_运维问答s are fine (I can point to the plist file in the address bar and it displays as text).

The answer is actually very simple: The URL needs to be "double-escaped", i.e.

itms-services://?action=download-manifest&url=https://example.com/My%2520App.plist

This is because the value gets unescaped to https://example.com/My%20App.plist before being treated as another URL. This gets unescaped by the server at example.com to a space.

The parser does not treat + specially: ...&url=https://.../test/a+b results in "GET /test/a+b HTTP/1.1" appearing in the Apache logs. (It is unwise to assume that all query strings are application/x-www-form-urlencoded; this is only standardized in HTML.)

Incidentally, it looks like itms-services uses +[NSURL URLWithString:] to validate URLs: url=.../My%20App.plist results in no request because [NSURL URLWithString:@"https://.../My App.plist"] returns nil. However, there's a long-standing bug in NSURL: It will escape a single invalid (BMP) character at the end instead of returning nil. My test cases

• url=.../test/%3c results in the log "GET /test/< HTTP/1.1" (this is definitely invalid HTTP!)
• url=.../test/%0a results in an error on device but no log message (because Apache treats it as a malformed request)
• url=.../test/%0d results in the log "GET /test/\r HTTP/1.1"

I had similar symptoms when I had a space in the filenames of the manifest file and the application archive file. I removed all spaces from them and the wireless install worked for me. It looks like your manifest doesn't have a space, so maybe your app file does?

itms-services is an identifier by which apple/iphone will identify that it should validate the certificate and it should install.

To validate the provisioning profile before installing the ipa file it will connect to "ax.init.itunes.apple.com" and "ocsp.apple.com".

If you are using any intranet connection please check whether these links are accessible or not? if not, you cannot install the application via over the air.

& minimum OS on the device should be 4.0

I was using IIS 6.0 and the index.html page was loading but when the user clicked on the .plist link from the apple device (i.e) iphone 4, I kept getting "cannot connect www.mywebsite.com". The solution besides adding the MIME Type, was to share the Web Sharing where the .plist file was and the most important: change the security access of the manifest .plist file. gave full control to default windows user

make MIME settings of your server correct.

google for it you'll find the right way

http://developer.apple.com/library/ios/#featuredarticles/FA_Wireless_Enterprise_App_Distribution/Introduction/Introduction.html

Seems like you have several pointers here to what might be the problem, for next time: check the device console from Xcode Organizer, it usually contains useful information regarding failed OTA distribution.

Be sure that all the URLs are fully qualified. Including those for the png files.

I had the same problem as above. After trying all of the above and failing, I figured out that when I was archiving my app, I didn't put in the application URL in the settings, thus this URL was never in my plist file. Make sure when you look at your plist file that the application URL is in there.

As many others before, I also encountered this daemon of a problem. In my case the problem was that the plist file was not correctly formated. Be sure that the file follows the exact pattern outlined in the documentation: http://developer.apple.com/library/ios/#featuredarticles/FA_Wireless_Enterprise_App_Distribution/Introduction/Introduction.html

For anyone who is interested in dynamically generating their plist, this example is PHP:

$appUrl='itms-services://?action=download-manifest&url=http://server/iOSpList.php?'.
                'url%3D'.$app['url'].
                '%26bundle%3D'.$app['bundle'].
                '%26version%3D'.$app['version'].
                '%26name%3D'.$app['name'];

Also, make sure the mime type is returned as application/xml.

I met this problem exactly as you described, and my problem turned out to be I missed "http://" in the url. After I added this part into the url field in .plist file, everything worked fine. Hope it helps!

I had similar problems when distributing my app using AdHoc provisioning profile. I tried removing old profiles, generating new profiles, restarting Xcode, cleaning and rebuilding, checking URL path names, etc. The app would install on some devices but not others.

What worked for me was to change the app version and build to a newer number.

I found that 'cannot use index.html' for ios 6 to install the app. Fixed by change from 'index.html' to 'dev.html'. hope will help someone

I tried some at the same time, so I'm not sure which one was the good one.

Created a wildcard app id (name wildcard, bunde identifier *), created a profile for this app and signed the ipa with this profile.

Registered one device on the provisioning portal.

named the file where I linked the app dev.html instead index.html

The proper solution is to replace spaces with "+"(plus) as ...url=... means it is query string parameter and they shall be encoded as form data parameter when encoded for URLs.

From here W3.org - Forms in HTML documents:

"Control names and values are escaped. Space characters are replaced by '+', and then reserved characters are escaped as described in [RFC1738]"

P.S. That solved the same issue we encountered during development of icenium.com. You can check AdHoc provision signing there and see how it works for projects with spaces in names.

If you are sending the link from an email, you CANNOT use HTML formatting in the email. You must use "rich text" formatting

No idea why but thats how it is (At least with Outlook)

I think you also need to make it https, as in https://mydomain