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 in

Answer 1

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

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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!

Answer 6

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"