wireless iphone app distribution - problem with itms-services protocol

Question

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 types are fine (I can point to the plist file in the address bar and it displays as text).

Answer 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?

Answer 2

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"