Les liens universels iOS ne s'ouvrent pas dans l'application

J'ai donc suivi exactement ce tutoriel et utiliser les mêmes valeurs que celles fournies: https://blog.branch.io/how-to-setup-universal-links-to-deep-link-on-apple-ios-9

Le fichier Apple Association est également prêt dans le répertoire des liens:
WEB_PAGE:PORT_NUMBER/apple-app-site-association

Tout semble être mis en place de ce côté.

J'ai ajouté les droits, mis à jour le profil de provisionnement et tout est configuré.

Lorsque j'exécute l'application sur mon appareil et que j'ouvre le lien http://WEB_PAGE:PORT_NUMBER , cela ouvre toujours Safari.

J'ai même des points d'arrêt dans la méthode suivante:

- (BOOL)application:(UIApplication *)application continueUserActivity:(NSUserActivity *)userActivity restorationHandler:(void(^)(NSArray * __nullable restorableObjects))restorationHandler

Mais zilch.

Quelqu'un a-t-il perfectionné cela? Y a-t-il quelque chose qui me manque?

Il y a quelques problèmes possibles.

1. Essayez de coller votre domaine dans ce validateur de lien et assurez-vous qu'il n'y a pas de problème: https://limitless-sierra-4673.herokuapp.com/ (crédit à ShortStuffSushi - voir repo )

2. iOS enregistre un message d'erreur dans les journaux système si TLS n'est pas correctement configuré sur le domaine spécifié dans vos droits. Il est enfoui dans les journaux du système d'exploitation, pas dans les journaux d'application. 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 tiré d' ici , instructions rapides (incomplètes) sur l'utilisation de CloudFlare pour TLS ici .

3. Dans mes tests personnels, cliquer / saisir un lien dans Safari n'a jamais ouvert une seule fois l'application directement. Cliquer depuis d'autres applications (iMessage, Mail, Slack, etc.) a fonctionné. D'autres ont signalé que cliquer sur des liens dans les résultats de recherche Google avait ouvert l'application directement.

4. Notez que si un lien universel réussit à 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 faire défiler vers le bas pour révéler 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 spécifique au chemin , en fonction des chemins que vous spécifiez dans le fichier apple-app-site-assocation. Donc, si vous avez des itinéraires séparés, yoursite.com/a/*et yoursite.com/b/*, si vous cliquez sur ouvrira dans le navigateur, pas dans l'application. Cependant, cela ne devrait pas être affecté et ouvrir toujours votre application directement.yoursite.com/a/* et que cela ouvre directement votre application, vous avez alors la possibilité de cliquer dans le coin supérieur droit de l'application yoursite.com/a/*. Si vous faites cela, des visites ultérieures àyoursite.com/a/*yoursite.com/b/*

Faites-moi savoir si vous découvrez quel est le problème. Je suis personnellement très curieux de savoir comment fonctionnent les liens universels et quels cas extrêmes existent. Bonne chance.

Cela peut mal tourner de nombreuses manières. Deux points m'ont causé des problèmes:

• Dans Xcode, lorsque vous ajoutez le droit aux domaines associés, chaque entrée doit commencer par applinks:, puis par votre nom de domaine. Par exemple applinks:www.apple.com.

• Bien que Xcode ait créé un fichier de droits pour moi, il ne l'a pas inclus dans ma construction: j'ai dû cliquer sur cette case manuellement.

Et oui, après cela, il n'était pas nécessaire de signer le apple-app-site-associationfichier: c'est juste du texte brut, et cela fonctionne, tant qu'il est servi via HTTPS. (Cependant, vous devrez toujours le signer si vous prenez en charge iOS 8.)

Il y a apparemment une erreur dans la documentation pour créer le fichier d'association pour Universal Links .

Où il est dit:

La valeur de la clé appID est l'ID d'équipe de l'application et l'ID du groupe

ça devrait dire

La valeur de la clé appID est le préfixe de l'application et l'ID du groupe

Pour la plupart des applications, il semble que l'ID d'équipe et les préfixes d'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 regardez «Certificats, identificateurs et profils», cliquez sur «Identificateurs», puis sur «ID d'application» dans le tableau sous «Identificateurs». Recherchez votre application et utilisez la valeur de préfixe et l'ID de groupe pour créer votre AppID pour le fichier d'association.

Pour vous aider à déboguer 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 échoué.

1. Utilisez un appareil réel, pas le simulateur.
2. Supprimez l'application de votre appareil.
3. Connectez l'appareil à votre ordinateur et affichez la sortie de la console de l'appareil dans xcode. (fenêtre -> appareils -> [votre appareil] -> console ouverte). Gardez cette fenêtre ouverte.
4. Installez votre application et laissez-la se lancer.
5. 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 avez gâché quelque chose de fondamental comme l'ajout du droit aux domaines associés.

La réponse de St.derrick est informative.

Mais pour permettre à nouveau aux liens universels de s'ouvrir dans l'application au lieu de safari, nous devons faire la chose suivante.

• Appuyez longuement sur le lien universel dans Mail ou iMessage, puis vous verrez des options pour ouvrir en safari ou dans l'application.

Pour valider apple-app-site-associationcôté serveur, vous pouvez utiliser le validateur officiel d'Apple.

https://search.developer.apple.com/appsearch-validation-tool/

J'ai réalisé 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. L'ajout "/"à la liste des chemins l'a révélé:

{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "TEAM_ID.BundleIdentifier",
                "paths": [ "*", "/" ]
            }
        ]
    }
}

Comme répondu par slutsker dans ce fil de discussion Apple Developer Forums.

Étapes rapides pour vérifier si vous avez correctement implémenté Universal Link.

• Appuyez 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 prévoyez d'ouvrir l'application. Appuyez sur Terminé. Le lien deviendra jaune et en appuyant sur le lien devrait ouvrir votre application, et non Safari.

• Si le lien http://yourDomain.com ne lance pas l'application, essayez http://yourDomain.com/yourFolder/

• Dans Safari, si le menu contextuel affiche «Ouvrir dans [nom de votre application]» dans safari, mais en appuyant sur le lien, vous ouvrez le lien dans safari lui-même au lieu de lancer l'application,

  une. Essayez de tirer vers le bas sur la page safari qui s'est ouverte lorsque le lien a été cliqué comme la façon dont vous «tirez pour actualiser». Une bannière devrait apparaître pour ouvrir votre application. Appuyez sur la bannière pour ouvrir l'application, fermez l'application en appuyant sur le bouton d'accueil, revenez au safari et essayez de lancer l'application en appuyant à nouveau sur le lien. Cette fois-ci, l'application devrait être lancée car le fait d'appuyer sur la bannière aurait dû enregistrer la préférence d'ouverture du lien dans l'application.

  b. Si l'application ne se lance toujours pas après l'étape a., Essayez d'envoyer le lien vers un webmail tel que gmail et ouvrez le site webmail dans Safari et essayez de cliquer sur le lien. Si cela fonctionne, vous avez peut-être essayé 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 . Safari ne se souciera probablement pas de vérifier si l'URL de destination est un lien universel, lorsque le lien se trouve dans le même domaine que l'utilisateur. Essayez donc de lancer l'application à partir d'un autre domaine.

Il est également très important d'incrémenter la version du projet ou le numéro de build après avoir intégré les liens universels. Même si vous supprimez / réinstallez, iOS ne récupérera pas les liens sauf si vous augmentez la version.

• Les liens universels ne fonctionneront pas si vous collez le lien dans le champ URL du navigateur.

• Les liens universels fonctionnent avec un <a href="...">clic d'élément piloté par l'utilisateur dans les domaines . Exemple: s'il y a un lien universel sur google.com pointant vers bnc.lt, il ouvrira l'application.

• Les liens universels ne fonctionneront pas avec un <a href="...">clic d'élément piloté par l'utilisateur 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 n'ouvrira pas l'application.

• Les liens universels ne peuvent pas être déclenchés via Javascript (dans window.onload ou via un appel .click () sur un <a>élément), sauf si cela fait partie d'une action de l'utilisateur.

source: https://dev.branch.io/getting-started/universal-app-links/support/ios/#appsbrowsers-that-support-universal-links

La troisième balle m'a coûté environ une journée à comprendre.

Pour tous ceux qui ont besoin de tester facilement l'ouverture des liens (universels), vous pouvez également ouvrir le lien dans votre simulateur à partir du terminal avec cette commande:

xcrun simctl openurl booted yourapp_or_http://yourlink

par exemple:

xcrun simctl openurl booted https://www.google.com

Au cas où les gens ici recherchent d'autres solutions, nous avons rassemblé étape par étape le débogage des liens universels car nous avons vu de nombreux problèmes surgir, causant BEAUCOUP de maux de tête.

Vérifiez-le:

Guide de débogage des liens universels

Si vous souhaitez simplement configurer de nouveaux liens universels, ce guide est vraiment utile:

Guide de configuration de Deep Linking iOS

J'espère qu'ils sont utiles!

Je pensais juste que j'ajouterais des choses que j'ai découvertes au cas où plus de gens 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 apple-app-site-association fichier doit être servi sur https, même s'il est signé. Le certificat utilisé pour https doit également être approuvé par Apple. Ainsi, bien qu'un certificat ajouté à l'appareil dans Paramètres -> Général -> Profils autorise https en safari, il ne permettra pas aux liens universels de fonctionner.

Dans les journaux de l'appareil, sur une erreur d'authentification entre l'appareil et le serveur, il y aura une valeur imprimée comme "TrustResultValue" : 4. Un TrustResultValuesur 5 signifie que le certificat est pour le mauvais domaine (par exemple, test.com servi depuis www.test.com). Un TrustResultValuesur 4 signifie que le certificat n'est pas approuvé pour cette utilisation.

Il peut y avoir des étapes utiles pour le débogage ici . La section «Test de l'accès à Apple-app-site-association» est un guide étape par étape pour vous assurer que l'appareil reçoit le apple-app-site-associationfichier. Les étapes se résument à:

1. Désinstallez l'application. Cela est nécessaire car le fichier est téléchargé lors de l'installation.

2. Arrêtez le serveur de servir correctement apple-app-site-association.

3. Dans xcode, ouvrez Fenêtre -> Appareils, puis sélectionnez votre appareil.

4. Ouvrez les journaux de l'appareil en cliquant sur le triangle en bas de la fenêtre.

5. Effacez les journaux en cliquant sur la corbeille pour effacer tous les journaux précédents qui pourraient être liés.

6. Réinstallez l'application avec xcode en cliquant sur le bouton de lecture.

7. Une fois l'application lancée, 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 apple-app-site-associationfichier est correctement servi (l'étape 2 est omise), il ne devrait y avoir aucune erreur. Une erreur d'authentification peut s'afficher à la place si tel est le problème.

La cause la plus courante est lorsque l'utilisateur tape en haut à droite, indiquant ainsi à iOS de NE PAS ouvrir l'application (dans ce cas, Uber) à l'avenir.

Pour réparer, tirez vers le bas pour révéler la bannière intelligente et appuyez sur OPEN:

Cela "se souviendra" par la suite d'ouvrir l'application.

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 venait du chemin .well-known :

https://example.com/.well-known/apple-app-site-association

En raison du chemin https://example.com/.well-known/apple-app-site-association redirigé vers https://example.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 le chemin .well-known ne fonctionne pas correctement, il rompt les liens universels.

J'ai réussi à le faire fonctionner, mais cela a pris du temps et du mal. Notez qu'à moins que vous ne signiez le apple-app-site-association fichier (la signature est facultative!), Appuyer sur un lien dans Safari n'ouvrira pas votre application (cela m'a causé beaucoup de maux de tête).

Cela m'a pris près d'une journée 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 les liens universels dans le simulateur

À partir du guide de programmation de la recherche d'applications: prise en charge des liens universels

Au bout de deux jours, il s'est avéré pour moi que ce genre de liens (de branche)

applinks: xxxx.app.link

ne fonctionne qu'après l'archivage (également ad hoc) de l'application et installez-la sur le téléphone.

Si vous hébergez votre apple-app-site-associationsur Firebase , assurez-vous de le mettre dans un /.well-known/sous-répertoire! Il semble que Xcode interroge cette URL en premier, et s'il réussit, il ne tente pas d'interroger le apple-app-site-associationdans le répertoire racine. Pour une raison quelconque, les ingénieurs de Firebase ont fait en sorte que les sites Web hébergés répondent automatiquement /.well-known/apple-app-site-associationavec un fichier d'association vide (mais correctement formé) qui remplace votre fichier personnalisé, vous laissant sans aucune idée 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 une fenêtre contextuelle pour les identifiants d'application qui affichera une liste des noms de vos applications et entre parenthèses () derrière le nom de l'application, il révèle tous vos vrais identifiants d'application . Certaines applications peuvent avoir votre ID d'équipe comme préfixe, mais d'autres pas . Assurez-vous d'utiliser exactement ce que vous voyez dans ce menu contextuel à l'intérieur du () et placez-le dans le champ appID des détails de l'association apple-app-site-association. J'ai eu exactement ce problème avec une application et ses liens universels.

Le problème pour moi s'est avéré être le apple-app-site-associationfichier. Selon la documentation d'Apple, seul le paramètre applinks est requis. J'ai ajouté le activitycontinuationparamètre et cela a fonctionné.

{
  "activitycontinuation": {
    "apps": [
      "9JA89QQLNQ.com.apple.wwdc"
    ]
  },
  "applinks": {
    "apps": [],
    "details": [{
        "appID": "9JA89QQLNQ.com.apple.wwdc",
        "paths": [ "/wwdc/news/", "/videos/wwdc/2015/*" ]
      }]
  }
}

Je n'ai pas vraiment vu le même combo problème / solution qui l'a fait fonctionner pour moi, alors autant ajouter le mien au cas où quelqu'un aurait le même problème!

Pour mon application, j'utilise un schéma d'URL personnalisé (défini dans APP_TARGET > Info > URL Types) et je définis le schéma d'URL d'ici dans la console Firebase pour qu'il corresponde, mais ne fonctionnait toujours pas.

Mon problème était en fait deux problèmes:

Faites attention si vous cochez la case Gérer automatiquement la signature

Si vous vérifiez le paramètre "Gérer automatiquement la signature" de Xcode comme moi, puisque 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 d'équipe de ma page d'adhésion, mais j'ai vu plus tard que l'ID réel utilisé par Xcode était différent. (Vous pouvez trouver cela dans APP_TARGET > General > Signing > Signing Certificate.Pour moi, cela ressemblait à iPhone Developer: My Name (TEAM_ID)).

Préfixez votre TeamID à votre identifiant de bundle dans vos types d'URL

Après m'être assuré que ceux-ci correspondaient dans ma console Firebase et Xcode, mon problème suivant était l'identifiant de mon schéma d'URL. Il est typique d'utiliser votre identifiant de bundle ici, mais Firebase préfixe en fait celui-ci avec l'ID d'équipe que vous avez donné dans votre console Firebase, j'ai donc dû le préfixer à l'identifiant dans la section des types d'URL dans Xcode également.

Après ces deux correctifs et le re-téléchargement du GoogleService-Info.plistfichier, je n'ai eu aucun problème à ouvrir mes liens dynamiques.

Après deux jours de désespoir total, je pense que j'ai enfin réglé le problème. Voici ma solution:

Il semble que les anciennes applications utilisent un préfixe d'application différent de celui des applications plus récentes. Les nouvelles applications utilisent uniquement l'ID d'équipe à cette fin. Si le préfixe de l'application et l'ID d'é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 vécue pendant mon voyage en enfer est que la suppression de l'application et le redémarrage de l'appareil semblent être le seul moyen de forcer l'actualisation de ce fichier.

Pour moi, mon erreur était que notre site redirige www.domain.com vers domain.com, donc tout le www.domain.com/* échouera à cause de cela. J'espère que cela pourra aider.

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 j'ai ajouté l'URL que je voulais tester dans le URLchamp 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.

Après avoir passé une journée à essayer de faire fonctionner cela, le redémarrage de mon téléphone a résolu le problème.

La désinstallation / réinstallation de l'application n'a pas non plus fonctionné.

Pour ios13, il existe un nouveau format - consultez ici https://developer.apple.com/documentation/safariservices/supporting_associated_domains_in_your_app?language=objc

J'ai mis à jour mon fichier pour qu'il ressemble à ceci:

{
  "applinks": {
      "details": [
           {
             "appIDs": [ "ABCDE12345.com.example.app" ],
             "components": [
               {
                  "/": "/my-link/*",
                  "exclude": true,
                  "comment": "Matches any URL whose path starts with /my-link/ and instructs the system not to open it as a universal link"
               }
             ]
           }
       ]
   },
   "webcredentials": {
      "apps": [ "ABCDE12345.com.example.app" ]
   }
}

Pour les futurs lecteurs qui trouvent cette page ...

J'ai eu une situation similaire. Cependant, dans ma situation, iOS10 fonctionnait AOK, et peu importe ce que je faisais (augmenter les numéros de build, supprimer / réinstaller, etc.), iOS9 semblait refuser de fonctionner.

J'arrivais à cela depuis iOS10 et j'avais besoin de 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 du serveur Web (par exemple /apple-app-site-association) ou dans le dossier .well-known (par exemple /.well-known/apple-app-site-association). Comme je supporte également Android, qui utilise également le dossier .well-known pour un fichier similaire, j'ai décidé de mettre les deux là-dedans.

Pour les nouvelles installations sur iOS10, il demande clairement le fichier racine, échoue, puis demande le fichier .well-known et réussit.

Pour iOS9, il a clairement demandé le fichier racine, échoue et ne fait rien d'autre.

Solution: si vous supportez iOS9, placez le fichier sur /apple-app-site-association.

Dans mon cas, mon erreur a été 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, cela commence à fonctionner