iOS9: Universal Links ne fonctionne pas
J'ai donc suivi le tutoriel https://blog.branch.io/how-to-setup-universal-links-to-deep-link-Apple-ios-9 et utilise exactement les mêmes valeurs que un fourni.
Le fichier Apple Association est également prêt dans le répertoire de liens: WEB_PAGE: PORT_NUMBER/Apple-app-site-association
Tout semble être configuré de ce côté.
J'ai ajouté les droits, mis à jour le profil de provisioning et tout est configuré.
Lorsque je lance l'application sur mon appareil et que j'ouvre le lien http: // WEB_PAGE: PORT_NUMBER , Safari est toujours ouvert.
J'ai même des points d'arrêt dans les méthodes suivantes:
- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void(^)(NSArray * __nullable restorableObjects))restorationHandler
Mais zilch.
Quelqu'un at-il perfectionné cela? Y a-t-il quelque chose que j'ai raté?
Il y a quelques problèmes possibles.
Essayez de coller votre domaine dans ce validateur de lien et assurez-vous qu'il n'y a pas de problèmes: https://limitless-sierra-4673.herokuapp.com/ (crédit de ShortStuffSushi - see repo )
iOS enregistre un message d'erreur dans les journaux système si TLS n'est pas configuré correctement sur le domaine spécifié dans vos droits. Il est enfoui dans les journaux du système d'exploitation, pas dans les journaux des applications. Le message d'erreur ressemblera à
Sep 21 14:27:01 Derricks-iPhone swcd[2044] <Notice>: 2015-09-21 02:27:01.878907 PM [SWC] ### Rejecting URL 'https://examplecustomdomain.com/Apple-app-site-association' for auth method 'NSURLAuthenticationMethodServerTrust': -6754/0xFFFFE59E kAuthenticationErr. Message d'erreur extrait de ici , instructions rapides (incomplètes) sur l'utilisation de CloudFlare pour TLS ici .Lors de mes tests personnels, cliquer/saisir un lien dans Safari n'a jamais ouvert l'application directement. En cliquant à partir d'autres applications (iMessage, Mail, Slack, etc.) a travaillé. D'autres ont signalé que les liens en cliquant dans les résultats de recherche Google avaient ouvert l'application directement.
Notez que si un lien universel parvient à ouvrir votre application et que vous cliquez ensuite sur Safari (en appuyant sur votre site dans le coin supérieur droit de la barre de navigation de l'application), iOS arrête d'ouvrir l'application lorsque vous visitez cette URL. Ensuite, dans Safari, vous pouvez afficher une bannière en haut de la page avec "Ouvrir". J'ai perdu beaucoup de temps là-dessus. Notez que cliquer sur le site => désactiver UL semble être spécifique au chemin, en fonction des chemins que vous spécifiez dans le fichier d'association de site Apple-app-site . Ainsi, si vous avez des itinéraires distincts,
yoursite.com/a/*etyoursite.com/b/*, si vous cliquez suryoursite.com/a/*et que celui-ci ouvre directement votre application, vous avez alors la possibilité, dans le coin supérieur droit de celle-ci, de cliquer suryoursite.com/a/*. Si vous faites cela, les visites suivantes àyoursite.com/a/*s'ouvriront dans le navigateur, pas dans l'application. Cependant,yoursite.com/b/*ne doit pas être affecté et continue à ouvrir votre application directement.
Faites-moi savoir si vous découvrez le problème. Personnellement, je suis très curieux de savoir comment fonctionnent les liens universels et quels cas Edge existe. Bonne chance.
Il y a beaucoup de façons que cela peut aller mal. Deux points m'ont causé des ennuis:
Dans Xcode, lorsque vous ajoutez le droit de domaines associés, chaque entrée doit commencer par
applinks:, puis votre nom de domaine. Par exemple.applinks:www.Apple.com.Bien que Xcode ait créé un fichier de droits pour moi, il n’incluait pas ma construction: je devais cliquer manuellement sur cette case.
Et oui, après cela, il n'était pas nécessaire de signer le fichier Apple-app-site-association: il s'agissait simplement de texte brut et cela fonctionnait, tant qu'il était diffusé via HTTPS. (Vous devrez quand même le signer si vous utilisez iOS 8, cependant.)
Il y a apparemment une erreur dans la documentation lors de la création du fichier d'association pour Universal Links .
Où il est dit:
La valeur de la clé appID correspond à l'ID de l'équipe de l'application et à l'ID de l'ensemble.
il devrait dire
La valeur de la clé appID est le préfixe de l’application et l’ID du paquet.
Pour la plupart des applications, il semble que l'ID de l'équipe et les préfixes de l'application soient les mêmes, mais si votre application est dans le magasin depuis de nombreuses années, ces valeurs peuvent être différentes.
Pour trouver cette valeur, ouvrez le centre des membres sur https://developer.Apple.com et consultez "Certificats, identifiants et profils", cliquez sur "Identifiants", puis sur "Identifiants d'application" dans le tableau sous "Identifiants ". Recherchez votre application et utilisez-y la valeur de préfixe et l'ID d'ensemble pour créer votre identifiant d'application pour le fichier d'association.
St.derrick's Answer est informatif.
Mais pour permettre à nouveau aux liens universels de s'ouvrir dans l'application au lieu de safari, nous devons procéder comme suit.
- Appuyez longuement sur le lien universel dans Mail ou iMessage, vous verrez alors les options pour ouvrir dans Safari ou dans App.
Pour valider Apple-app-site-association côté serveur, vous pouvez utiliser le validateur officiel d’Apple.
https://search.developer.Apple.com/appsearch-validation-tool/
Pour faciliter le débogage de ce problème, recherchez "swcd" dans la sortie de la console de votre appareil lors de l'installation de votre application pour voir si l'enregistrement de votre lien universel a fonctionné ou a échoué.
- Utilisez un appareil réel, pas le simulateur.
- Supprimer l'application de votre appareil.
- Connectez le périphérique à votre ordinateur et affichez la sortie de la console du périphérique au format xcode. (fenêtre -> périphériques -> [votre périphérique] -> afficher les journaux du périphérique). Gardez cette fenêtre ouverte.
- Installez votre application et laissez-la se lancer.
- Filtrez la sortie de la console sur "swcd". Si cela réussit, vous verrez quelque chose comme la capture d'écran suivante. Si cela échoue, vous verrez autre chose. Si vous ne voyez rien, vous vous êtes plié à quelque chose de fondamental comme l'ajout du droit associé aux domaines associés.
Je me suis rendu compte que le problème pour moi était que les liens vers le répertoire racine a (par exemple, http://example.com/) n’ouvraient pas mon application, mais si j’ ajoutais un chemin (par exemple, http://example.com/mypath), cela fonctionnait. Ajouter "/" à la liste des chemins l’a modifié:
{
"applinks": {
"apps": [],
"details": [
{
"appID": "TEAM_ID.BundleIdentifier",
"paths": [ "*", "/" ]
}
]
}
}
Répondu par slutsker dans le fil this Apple Developer Forums.
Étapes rapides pour vérifier si vous avez correctement implémenté Universal Link.
Tapez et maintenez sur le lien que vous prévoyez de lancer l'application. Vous devriez voir un "Ouvrir dans [nom de votre application]" dans le menu contextuel.
Ouvrez l'application Notes, tapez le lien que vous souhaitez ouvrir. Appuyez sur Terminé. Le lien deviendra jaune et en tapant sur le lien devrait ouvrir votre application, et non Safari.
Si le lien http://votreDomain.com ne lance pas l'application, essayez http://votreDomain.com/votreDossier/
Dans Safari, si le menu contextuel indique "Ouvrir dans [nom de votre application]" dans safari, mais si vous appuyez sur le lien, le lien s'ouvre dans le safari lui-même au lieu de lancer l'application,
une. Essayez de tirer sur la page de safari qui s’est ouverte lorsque vous avez cliqué sur le lien, comme si vous aviez cliqué sur le lien pour l'actualiser. Une bannière devrait apparaître pour pouvoir ouvrir votre application. Appuyez sur la bannière pour ouvrir l'application, fermez l'application en appuyant sur le bouton d'accueil, revenez à safari et essayez de lancer l'application en appuyant de nouveau sur le lien. Cette fois, l'application devrait être lancée car taper sur la bannière aurait dû enregistrer la préférence pour ouvrir le lien dans l'application.
b. Si l'application ne démarre toujours pas après l'étape a., Essayez d'envoyer le lien par courrier à un courrier Web tel que gmail, ouvrez le site de messagerie Web dans safari et cliquez sur le lien. Si cela fonctionne, vous avez peut-être tenté de lancer l'application à partir du même domaine que le lien. D'après ce que j'ai vu, le lancement de l'application à partir du même domaine échoue la plupart du temps. Il est probable que Safari ne voudra pas vérifier si l'URL de destination est un lien universel, lorsque le lien se trouve dans le même domaine que celui où se trouve l'utilisateur. Alors essayez de lancer l'application depuis un autre domaine.
Il est également extrêmement important d'incrémenter la version du projet ou le numéro de build après l'intégration des liens universels. Même si vous supprimez/réinstallez, iOS ne récupérera pas les liens, sauf si la version est modifiée.
Les liens universels ne fonctionneront pas si vous collez le lien dans le champ URL du navigateur.
Liens universels work avec un élément
<a href="...">piloté par l'utilisateur, cliquez sur à travers les domaines. Exemple: s'il existe un lien universel sur google.com pointant vers bnc.lt, l'application sera ouverte.Les liens universels ne fonctionneront pas avec un élément
<a href="...">piloté par l'utilisateur, cliquez sur sur le même domaine. Exemple: s'il existe un lien universel sur google.com pointant vers un autre lien universel sur google.com, l'application ne s'ouvrira pas.Les liens universels ne peuvent pas être déclenchés via Javascript (dans window.onload ou via un appel .click () sur un élément
<a>), à moins que cela ne fasse partie d'une action de l'utilisateur.
La 3ème balle m'a coûté environ un jour pour comprendre.
Si les gens ici recherchent d’autres solutions, nous avons mis au point un processus complet de débogage des liens universels, car nous avons vu beaucoup de problèmes surgir, qui causaient BEAUCOUP de maux de tête.
Vérifiez-le:
Guide de débogage Universal Links
Si vous souhaitez simplement configurer des liens universels, ce guide est très utile:
Guide de configuration iOS Deep Linking
J'espère qu'ils sont utiles!
La cause la plus fréquente survient lorsque l'utilisateur appuie en haut à droite, invitant iOS à NE PAS ouvrir l'application (dans ce cas, Uber) à l'avenir.
Pour résoudre ce problème, déroulez-le pour afficher la bannière intelligente et appuyez sur OUVRIR:
Ce sera ensuite "se souvenir" pour ouvrir l'application.
Je pensais que j'ajouterais certaines choses que j'ai découvertes au cas où plus de personnes rencontreraient les mêmes problèmes que moi à l'avenir. Celles-ci sont principalement liées aux erreurs d'authentification.
Même si Apple ne l'indique pas explicitement, le fichier Apple-app-site-association doit être servi sur https, même s'il est signé. Le certificat utilisé pour https doit également être approuvé par Apple. Ainsi, même si un certificat ajouté au périphérique dans Paramètres -> Général -> Profils autorise https dans safari, il ne permet pas aux liens universels de fonctionner.
Dans les journaux du périphérique, en cas d'erreur d'authentification entre le périphérique et le serveur, une valeur telle que "TrustResultValue" : 4 sera imprimée. Un TrustResultValue sur 5 signifie que le certificat correspond au mauvais domaine (par exemple, test.com servi à partir de www.test.com). Une TrustResultValue sur 4 signifie que le certificat n'est pas approuvé pour cet usage.
Il peut y avoir des étapes utiles pour le débogage ici . La section "Test de l'accès à l'association Apple-app-site-association" décrit étape par étape comment s'assurer que le périphérique reçoit le fichier Apple-app-site-association. Les étapes se résument à:
Désinstallez l'application. Cela est nécessaire car le fichier est téléchargé lors de l'installation.
Arrêtez le serveur de servir correctement
Apple-app-site-association.Dans xcode, ouvrez Window -> Devices puis sélectionnez votre appareil.
Ouvrez les journaux du périphérique en cliquant sur le triangle en bas de la fenêtre.
Effacez les journaux en cliquant sur la corbeille pour effacer tous les journaux précédents éventuellement associés.
Réinstallez l'application avec xcode en cliquant sur le bouton de lecture.
Après le lancement de l'application, si l'appareil demande correctement le fichier, les journaux de l'appareil doivent contenir une erreur qui peut être trouvée en recherchant "Apple-app-site-association".
Si le fichier Apple-app-site-association est correctement servi (l'étape 2 est omise), il ne devrait y avoir aucune erreur. Une erreur d'authentification peut à la place être affichée si tel est le problème.
Pour tous ceux qui ont besoin de tester facilement l’ouverture de liens (universels), vous pouvez également ouvrir le lien dans votre simulateur à partir du terminal à l’aide de cette commande:
xcrun simctl openurl booted yourapp_or_http://yourlink
par exemple:
xcrun simctl openurl booted https://www.google.com
Il m’a fallu près d’un jour pour comprendre cela ... Le problème que j’avais était de ne pas télécharger les profils d’approvisionnement mis à jour dans XCode (j’ai également redémarré XCode après cela).
(Préférences> Comptes> Afficher les détails> Tout télécharger)
Vous pouvez tester des liens universels dans le simulateur
Dans le Guide de programmation des applications de recherche: Liens universels d'assistance
Si vous hébergez votre Apple-app-site-association sur Firebase, assurez-vous de le placer dans le sous-répertoire /.well-known/! Il semble que Xcode commence par interroger cette URL et que, si l'opération réussit, elle ne tente pas d'interroger le Apple-app-site-association dans le répertoire racine. Pour une raison quelconque, les ingénieurs de firebase ont obligé les sites Web hébergés à répondre automatiquement à /.well-known/Apple-app-site-association avec un fichier d'association vide (mais correctement formé) qui remplace votre fichier personnalisé, vous laissant ainsi la moindre idée de pourquoi rien ne fonctionne!
Accédez à developer.Apple.com et modifiez l'un de vos profils de distribution. Dans la page d'édition, vous pouvez ouvrir un contextuel pour les identifiants d'application qui affichera une liste des noms de vos applications et entre () entre parenthèses derrière le nom de l'application it révèle tous vos real identifiants d'application . Certaines applications peuvent avoir votre identifiant d’équipe comme préfixe mais d’autres pas. Veillez à utiliser exactement ce que vous voyez dans ce menu contextuel à l'intérieur de la () et à le placer dans le champ appID du champ des détails d'association Apple-app-site-association. J'ai eu exactement ce problème avec une application et ses liens universels.
Je n'ai pas vraiment vu le même combo problème/solution qui a fonctionné pour moi, alors autant ajouter le mien au cas où quelqu'un aurait le même problème!
Pour mon application, j'utilise un modèle d'URL personnalisé (défini dans APP_TARGET > Info > URL Types) et configure le modèle d'URL à partir d'ici dans la console Firebase afin qu'il corresponde, mais ne fonctionnait toujours pas.
Mon problème était en fait deux problèmes:
Attention si cocher Gérer automatiquement la signature
Si vous vérifiez le paramètre "Gérer automatiquement la signature" de Xcode comme je le faisais, étant donné que j'essayais simplement de créer une application de démonstration rapide, vous voudrez vous assurer que le TeamID utilisé correspond à celui de votre console Firebase. À l'origine, je suis allé sur mon compte de développeur Apple et j'ai copié l'ID de l'équipe de ma page d'adhésion, mais j'ai ensuite constaté que l'ID utilisé par Xcode était différent. (Vous pouvez le trouver dans APP_TARGET > General > Signing > Signing Certificate. Pour moi, cela ressemblait à iPhone Developer: My Name (TEAM_ID)).
Préfixez votre identifiant TeamID avec votre identifiant de paquet dans vos types d'URL
Après avoir vérifié la correspondance de ces éléments dans ma console Firebase et Xcode, le problème suivant était l’identificateur de mon schéma d’URL. Il est courant d’utiliser votre identifiant de bundle ici, mais Firebase le préfixe avec l’ID d’équipe que vous avez donné dans votre console Firebase;
Après ces deux corrections et le téléchargement du fichier GoogleService-Info.plist, je n’ai eu aucun problème à ouvrir mes liens dynamiques.
Nous avons ajouté le fichier Apple-app-site-association à cet emplacement:
https://example.com/Apple-app-site-association
Sur iOS 9, cela fonctionnait bien, mais sur iOS 10, cela ne fonctionnait pas.
Il est apparu que le problème était lié au chemin .bien-connu:
https://example.com/.well-known/Apple-app-site-association
En raison de https://exemple.com/.well-known/Apple-app-site-association chemin redirigé vers https://exemple.com
<Notice>: Allowing redirect 'https://example.com/.well-known/Apple-app-site-association' -> 'https://example.com/'
<Notice>: ### Rejecting AASA file size 154466 for URL https://example.com/.well-known/Apple-app-site-association
À mon avis, si un chemin bien connu ne fonctionne pas correctement, il rompt les liens universels.
Pour moi, mon erreur était que notre site redirige www.domain.com vers domain.com, donc tous les www.domain.com/* échoueront à cause de cela. J'espère que cela pourra aider.
Après deux jours de désespoir total, je pense que j'ai finalement résolu le problème. Voici ma solution:
Il semble que les anciennes applications utilisent un préfixe différent de celui des nouvelles applications. Les applications les plus récentes utilisent uniquement l'ID de l'équipe à cette fin. Si le préfixe de l'application et l'ID de l'équipe ne sont pas identiques, il semble que vous deviez spécifier le champ de continuation d'activité dans le fichier d'association de site d'application Apple:
{
"activitycontinuation": {
"apps": [
"YOUR_APP_PREFIX.de.company.app"
]
},
"applinks": {
"apps": [],
"details": [
{
"appID": "YOUR_APP_PREFIX.de.company.app",
"paths": ["/*"]
}
]
}
}
Une autre chose que j'ai expérimentée au cours de mon enfer, c'est que supprimer l'application et redémarrer l'appareil semble être le seul moyen de forcer l'actualisation de ce fichier.
Après deux jours, il m'est apparu que ce genre de liens (de branche)
applinks: xxxx.app.link
ne fonctionne qu'après avoir archivé (également ad-hoc) l'application et l'avoir installée sur le téléphone.
Le problème pour moi s’est avéré être le fichier Apple-app-site-association. Selon la documentation d'Apple, seul le paramètre applinks est requis. J'ai ajouté le paramètre activitycontinuation et cela a fonctionné.
{
"activitycontinuation": {
"apps": [
"9JA89QQLNQ.com.Apple.wwdc"
]
},
"applinks": {
"apps": [],
"details": [{
"appID": "9JA89QQLNQ.com.Apple.wwdc",
"paths": [ "/wwdc/news/", "/videos/wwdc/2015/*" ]
}]
}
}
J'ai pu tester les liens universels dans le simulateur iOS à l'aide de l'application Calendrier.
Je viens de créer un événement et d'ajouter l'URL que je voulais tester dans le champ URL de l'événement. Ensuite, lors de la visualisation de l'événement créé, vous pouvez simplement appuyer sur le lien URL et votre application devrait s'ouvrir.
Pour les futurs lecteurs qui trouveront cette page ...
J'ai eu une situation similaire. Cependant, dans ma situation, iOS10 fonctionnait sous AOK et, quoi que j’ai fait (numéros de construction en bloc, suppression/réinstallation, etc.), iOS9 semblait refuser de fonctionner.
J'y arrivais depuis iOS10 et devais prendre en charge iOS9. À l'époque, la documentation ici - https://developer.Apple.com/library/content/documentation/General/Conceptual/AppSearch/UniversalLinks.html - indique clairement que le fichier peut être placé à la racine de le serveur Web (par exemple, /Apple-app-site-association) ou dans le dossier .well-connu (par exemple, /.well-known/Apple-app-site-association). Étant donné que je prends également en charge Android, qui utilise également le dossier .well pour un fichier similaire, j'ai décidé de mettre les deux à la place.
Pour les nouvelles installations sur iOS10, il demande clairement le fichier racine, échoue, puis demande le fichier .well-connu et réussit.
Pour iOS9, il a clairement demandé le fichier racine, a échoué et ne fait rien d’autre.
Solution: si vous prenez en charge iOS9, mettez le fichier à /Apple-app-site-association.
Dans mon cas, la demande du fichier AASA à l'adresse: https://example.com/Apple-app-site-association
A été redirigé vers: https://www.example.com/Apple-app-site-association
Le kicker est - cela fonctionne bien sur iOS 11, mais échoue sur iOS 9.3.5. Allez comprendre.
Solution: le fichier Apple-app-site-association NE DOIT PAS se trouver derrière une redirection 302 ou 301 pour iOS 9. (Pour être juste, cela est indiqué sur la page de dépannage UL .)
J'espère que cela aide quelqu'un parce que cela m'a pris environ deux jours pour comprendre.
Nous avons dû ajouter www. à notre associated-domains dans notre fichier .entitlements.
<string>applinks:www.yourdomain.com</string>
<string>activitycontinuation:www.yourdomain.com</string>
Parce que si nous utilisions yourdomain.com au lieu de www.yourdomain.com, nos serveurs effectuaient une redirection -> 304 et n'incluaient pas le content-type: application/json du Apple-app-site-association file.
NB: les liens universels fonctionnent toujours pour yourdomain.com et www.yourdomain.com
Dans mon cas, mon erreur était de mettre des paramètres de requête dans des chemins:
{
"applinks": {
"apps": [],
"details": [
{
"appID": "TEAM_ID.BundleIdentifier",
"paths": [ "/auth-ui/hub?target=confirm&*" ]
}
]
}
}
quand je supprime '? target = confirm & *' des chemins, il commence à fonctionner
Je n'ai pas vu quelqu'un fournir une solution pour Flask.
Cela a fonctionné pour moi.
Si vous utilisez Flask, placez l'association "Apple-app-site-association" dans votre dossier statique, puis ajoutez-la à votre fichier app.py.
@application.route('/Apple-app-site-association', methods=['GET'])
def Apple_app_site_association():
return application.send_static_file('Apple-app-site-association')
Pour moi, après avoir mis en œuvre toutes les réponses ci-dessus et testé que le fichier AASA était bien en cours de téléchargement avec la réponse de mpoisot, mon problème était que, dans Xcode, j'avais ajouté le domaine associé en tant que:
applinks:example.com
et dans mes notes, j'essayais d'utiliser:
Https://example.com
parce que mon AASA n'est pas signé et que je voulais m'assurer de le servir via HTTPS. Cela a donc fonctionné lorsque, dans l'application Notes, j'ai essayé d'utiliser:
example.com
Cela fonctionne pour moi sur un périphérique physique, utilisant iOS 12.1.2 avec une version de développement à partir de Xcode ou une version de distribution à partir de Testflight.
Je vais aussi mettre mes notes sur le dépannage.
Fondamentalement, nous avons 2 parties, qui devraient être liées entre elles: 1) site Web et 2) un iOS app.
Pour le site Web , un seul problème se posait: le type MIME du fichier
Apple-app-site-associationn'était pasapplication/json.Aussi API Validation Tool ne nous aidait pas. Pour les environnements
test, il disait
Erreur aucune application avec des droits d'accès au domaine Les données de droits utilisées pour vérifier l'authentification double par lien profond proviennent de la version actuelle de votre application. La mise à jour de ces données peut prendre 48 heures.
mais à la fin, le site Web était ok.
Nous avons vérifié les journaux Web, vu la requête GET concernant le fichier Apple-app-site-association et décidé de passer à l'application iOS.
- Pour traiter avec la configuration de l'application iOS , il est conseillé de lancer l'application
Console, avec filtrage pour afficher uniquement le processusswcd, a déjà été mentionné dans ce fil.
Dans notre cas, le problème était que nous nous basions sur une URL générique, sous la forme: applinks:*.prod_site_name.com, pensant que * couvrirait toutes les prépositions pour l'environnement de test, comme https://test_env.num4.prod_site_name.com, mais cela ne fonctionnait pas. La console montrait:
Demande lancée pour le domaine '* .prod_site_name.com', URL ' https://nom_produit_site.com/.well-known/Apple-app-site-association '
La solution dans notre cas était donc de fournir des applinks spécifiques au test pour la cible de test de l'application, tels que: applinks:test_env.num4.prod_site_name.com