I saw sometimes the http://domanname was added in front of "itms-services://", broke the link and got 404 error. Put "_blank" target in front if you saw this.
<!DOCTYPE HTML PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”
“http://www.w3.org/TR/html4/loose.dtd”>
<html>
<head>
<title>My Cool app</title>
</head>
<body>
<ul>
<!--li><a href=”http://mycoolapp/build/distribution.mobileprovision”>
Install Example Provisioning File</a></li-->
<li><a target="_blank" href="itms-services://?action=download-manifest&url=http://horizonstonetech.com/git/test.plist">
Install Example Application</a></li>
</ul>
</body>
</html>
A good guide to follow with screen shots.
http://blog.markhorgan.com/?p=322
Problem: After executing Build and Archive, Organizer does not automatically open
Solution: Make sure your application identifier matches the id linked to your Ad Hoc provision file
This may not be a pertinent step to a successful distribution, but I include here because the behavior of XCode was affected. Each Ad Hoc build is configured to use an Ad Hoc provision file which in turn is linked to an Application Identifier configured in the program portal. These identifiers are usually reverse domain in the form of "com.yourcompany.*". When creating a new XCode project, the default application id is something like "com.yourcompany.${PRODUCT_NAME:rfc1034identifier}". Modify the identifier to match the configuration set in your program portal. After the "Build and Archive" process completes, Organizer should open automatically with your new "Archived Application" listed below.Problem: Download Application link does not work
Solution: Make sure your web server has the correct MIME type set for both .plist and .ipa files
Property List (.plist) and iPhone Application Archive (.ipa) files are served to the iPhone OS devices from your web server. Most web servers, in my case IIS, do not have a MIME type mapping for these file types. When tapping the "download application" link from the HTML page, the page did not initiate a download. The download does not work. It just sat there as if I did not tap at all. In IIS, when the MIME type is not recognized the web server delivers a 404 Page not Found error. The download will not start because the web server thinks the file does not exist, even though we know it does. Since the "download application link" uses the itms-services protocol, the server error does not get relayed to the user interface. Adding the MIME type to the web server's list corrects this problem and can be verified using a web browser. The MIME types for these files are:
.plist - text/xml
.ipa - application/octet-streamProblem: Download Application link still does not work
Solution: Remove any spaces from your absolute URL's file name and web folder structure
I beat my head against the wall on this for a while. It seems logical that a project file or web folder could have spaces in the name since we have a function of URL Encoding, but URL Encoded resources appeared to be the make it or break your head on the wall factor. I had %20 URL Encoded spaces in my web folder hosting the .ipa and .plist files and also had spaces in the file names. Removing the spaces made that "download application link" WORK. I can't explain it nor did I submit a bug report. Could be by design or an oversight. Just check it out for your own sanity.
No comments:
Post a Comment