J'ai suivi toutes les instructions de Apple et un autre blog posts . J'ai archivé l'application, créé des fichiers .plist et .ipa, je les ai mis sur un serveur et liés à ces fichiers. Je peux très bien installer le profil de provisioning. Mais lorsque je clique sur le lien pour installer l'application (dans Safari sur l'iphone), rien ne se passe. Aucun message d'erreur. Rien. Voici à quoi ressemble le lien:
<a href="itms-services://?action=download-manifest&url=http://mydomain.com/test/myApp.plist">Install the app</a>
Une idée pourquoi ça ne marche pas? Il semble que le protocole itms-services soit tout simplement mort. Les types MIME sont corrects (je peux pointer le fichier plist dans la barre d’adresses et il s’affiche sous forme de texte).
J'avais des symptômes similaires lorsque j'avais un espace dans les noms de fichier du fichier manifeste et du fichier d'archive de l'application. J'ai supprimé tous les espaces et l'installation sans fil a fonctionné pour moi. On dirait que votre manifeste n'a pas d'espace, alors peut-être que votre fichier d'application en a?
La réponse est en réalité très simple: l’URL doit être "double échappée", c’est-à-dire.
itms-services://?action=download-manifest&url=https://example.com/My%2520App.plist
En effet, la valeur obtient unescaped à https://example.com/My%20App.plist
avant d'être traitée comme une autre URL. Cela devient non échappé par le serveur à example.com
dans un espace.
L'analyseur ne traite pas spécialement +: ...&url=https://.../test/a+b
fait apparaître "GET /test/a+b HTTP/1.1"
dans les journaux Apache. (Il est déconseillé de supposer que toutes les chaînes de requête sont application/x-www-form-urlencoded
; ceci n'est normalisé qu'en HTML.)
Incidemment, il semble qu'itms-services utilise +[NSURL URLWithString:]
pour validate URL: url=.../My%20App.plist
n'entraîne aucune demande, car [NSURL URLWithString:@"https://.../My App.plist"]
renvoie nil
. Cependant, NSURL présente un bogue de longue date: il échappera un seul caractère non valide (BMP) à la fin au lieu de renvoyer nil. Mes cas de test
url=.../test/%3c
résulte dans le log "GET /test/< HTTP/1.1"
(HTTP définitivement invalide!)url=.../test/%0a
génère une erreur sur le périphérique mais pas de message de journal (car Apache la traite comme une requête mal formée)url=.../test/%0d
résulte dans le journal "GET /test/\r HTTP/1.1"
itms-services est un identifiant à l'aide duquel Apple/iphone identifiera qu'il doit valider le certificat et qu'il doit être installé.
Pour valider le profil d'approvisionnement avant d'installer le fichier ipa, il se connectera à "ax.init.iTunes.Apple.com" et "ocsp.Apple.com".
Si vous utilisez une connexion intranet, veuillez vérifier si ces liens sont accessibles ou non. sinon, vous ne pouvez pas installer l'application par liaison radio.
& OS minimum sur le périphérique doit être 4.0
J'utilisais IIS 6.0 et la page index.html était en cours de chargement, mais lorsque l'utilisateur a cliqué sur le lien .plist à partir du périphérique Apple (par exemple, l'iphone 4), le message "impossible de se connecter à www.mywebsite.com". Outre l'ajout du type MIME, la solution consistait à partager le partage Web où se trouvait le fichier .plist et le plus important: modifier l'accès de sécurité du fichier manifeste .plist. a donné le contrôle total à l'utilisateur Windows par défaut
réglez correctement les paramètres MIME de votre serveur.
google pour cela, vous trouverez le bon chemin
On dirait que vous avez plusieurs indications sur ce qui pourrait être le problème, pour la prochaine fois: consultez la console du périphérique depuis Xcode Organizer, elle contient généralement des informations utiles concernant l'échec de la distribution OTA.
Assurez-vous que toutes les URL sont pleinement qualifiées. Y compris ceux pour les fichiers png.
J'ai eu le même problème que ci-dessus. Après avoir essayé tout ce qui précède et échoué, j'ai découvert que lorsque j'archivais mon application, je ne mettais pas l'URL de l'application dans les paramètres. Cette URL ne figurait donc jamais dans mon fichier Plist. Assurez-vous que votre fichier plist contient l'URL de l'application.
Comme beaucoup d'autres avant, j'ai également rencontré ce démon d'un problème. Dans mon cas, le problème était que le fichier plist n'était pas correctement formaté. Assurez-vous que le fichier respecte le modèle exact décrit dans la documentation: http://developer.Apple.com/library/ios/#featuredarticles/FA_Wireless_Enterprise_App_Distribution/Introduction/Introduction.html
Pour ceux qui sont intéressés par la génération dynamique de leur plist, cet exemple est 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'];
Assurez-vous également que le type mime est renvoyé sous la forme application/xml
.
Si vous envoyez le lien à partir d'un email, vous NE POUVEZ PAS utiliser le formatage HTML dans l'email. Vous devez utiliser un formatage "texte enrichi"
Aucune idée pourquoi mais c'est comme ça (du moins avec Outlook)
J'ai rencontré des problèmes similaires lors de la distribution de mon application à l'aide du profil d'approvisionnement AdHoc. J'ai essayé de supprimer d'anciens profils, de générer de nouveaux profils, de redémarrer Xcode, de nettoyer et de reconstruire, de vérifier les noms de chemins d'URL, etc. L'application s'installerait sur certains appareils mais pas sur d'autres.
Ce qui a fonctionné pour moi a été de changer la version de l'application et de construire un nouveau numéro.
La solution appropriée consiste à remplacer les espaces par "+" (plus), car ... url = ... signifie qu'il s'agit d'un paramètre de chaîne de requête et qu'ils doivent être codés en tant que paramètres de données de formulaire lorsqu'ils sont codés pour les URL.
À partir d'ici W3.org - Formulaires dans les documents HTML :
"Les noms de contrôle et les valeurs sont échappés. Les caractères d'espacement sont remplacés par '+', puis les caractères réservés sont échappés comme décrit dans [RFC1738]"
P.S. Cela a résolu le même problème que nous avons rencontré lors du développement de icenium.com. Vous pouvez vérifier la signature de la disposition ad hoc ici et voir comment elle fonctionne pour les projets avec des espaces dans les noms.
J'ai trouvé que «ne peut pas utiliser index.html» pour ios 6 pour installer l'application. Correction du changement de 'index.html' à 'dev.html'. l'espoir aidera quelqu'un
J'ai rencontré ce problème exactement comme vous l'avez décrit, et mon problème s'est avéré être "J'ai raté" http: // "dans l'URL Après avoir ajouté cette partie dans le champ URL du fichier .plist, tout a bien fonctionné. J'espère que ça aide!
J'ai essayé certains en même temps, donc je ne suis pas sûr de savoir lequel était le bon.
Création d'un identifiant d'application générique (nom générique, identifiant bunde *), création d'un profil pour cette application et signature de l'ipa avec ce profil.
Enregistré un périphérique sur le portail d'approvisionnement.
nommé le fichier où j'ai lié l'application dev.html à la place index.html