Qu'est-ce qu'un lien universel ? Comment fonctionne le deep linking d'Apple

Avant iOS 9, naviguer entre les sites Web mobiles et les applications iPhone natives était une expérience imprévisible et maladroite. Les développeurs se sont appuyés sur des protocoles URI personnalisés tels que instagram:// ou mybank://. Ces systèmes déclenchaient fréquemment des alertes système discordantes demandant « Ouvrir dans l'application ? », tombaient en panne complètement si l'application était manquante et souffraient de graves failles de sécurité. Pour résoudre ces failles fondamentales, Apple a dévoilé Universal Links. Mais qu'est-ce qu'un lien universel et pourquoi a-t-il transformé l'architecture logicielle mobile ?

À la base, un lien universel est une URL Web HTTPS standard et sécurisée qui achemine de manière transparente vers des contrôleurs de vue spécifiques dans une application iOS installée. Si l'application est installée, iOS la lance instantanément sans ouvrir Safari. Si l'application est manquante, le système d'exploitation charge gracieusement la page Web réactive dans Safari sans afficher de dialogues d'erreur. Dans cette étude technique approfondie, nous examinons le fonctionnement interne d'Apple Universal Links, explorons le fichier de configuration AASA et expliquons pourquoi le routage mobile moderne dépend de ce protocole.

Comprendre les liens universels est crucial pour tout ingénieur iOS ou spécialiste du marketing numérique cherchant à offrir des parcours clients sans friction à partir de campagnes par e-mail, de plateformes sociales et de résultats de moteurs de recherche.

Qu'est-ce qu'un lien universel et pourquoi Apple l'a construit

Pour comprendre l’objectif des liens universels, il faut examiner les lacunes des anciens schémas d’URL personnalisés. Les programmes personnalisés n'avaient pas de registre central. N'importe quel développeur pourrait créer une application utilisant le système paypal://, interceptant les paramètres financiers sensibles destinés à un service légitime, comme indiqué dans notre guide sur les systèmes d'URL mobiles. De plus, si un utilisateur sans l'application cliquait sur un lien de schéma personnalisé dans Safari, iOS affichait une erreur système grave : "Safari ne peut pas ouvrir la page car l'adresse n'est pas valide."

Apple a conçu Universal Links pour établir trois normes opérationnelles critiques :

• Unicité et sécurité : étant donné que les liens universels utilisent des domaines Web standards (par exemple, https://dslink.me/path), aucun autre développeur ne peut revendiquer votre lien à moins de contrôler vos enregistrements DNS et vos certificats SSL vérifiés.
• Retour sans friction : si un utilisateur d'iPhone n'a pas installé votre application, exactement la même URL ouvre automatiquement votre site Web mobile dans Safari. Il n'y a pas de liens rompus ni de messages d'erreur.
• Identité unique : les spécialistes du marketing et les développeurs n'ont besoin de partager qu'une seule URL qui sert à la fois les visiteurs Web sur les ordinateurs de bureau et les utilisateurs d'applications natives sur les appareils mobiles.

Cette conception a également résolu les problèmes où un lien s'ouvrait dans Safari au lieu de l'application en raison de transferts de protocole rompus.

L'architecture de l'Apple App Site Association (AASA)

La base opérationnelle d'Universal Links est une liaison sécurisée entre le système d'exploitation d'Apple et votre serveur Web. Cette poignée de main est médiée par le fichier Apple App Site Association (AASA), un document JSON hébergé sur :

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

Ce fichier définit quels ID d'application sont autorisés à gérer des chemins d'URL spécifiques sur votre domaine. Voici un exemple de formatage AASA JSON moderne :

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appID": "TEAMID1234.com.example.myapp",
        "paths": ["/video/*", "/product/*", "/user/*"],
        "components": [
          {
            "/": "/video/*",
            "comment": "Matches all video detail pages"
          }
        ]
      }
    ]
  }
}

Les principales règles techniques d'hébergement s'appliquent au fichier AASA :

• Il doit être servi via HTTPS avec un certificat SSL de confiance.
• Il doit renvoyer un Content-Type de application/json.
• Il doit renvoyer un code d'état HTTP 200 OK sans aucune redirection HTTP vers HTTPS.
• Apple met en cache ce fichier sur son réseau de diffusion de contenu (CDN) ; les modifications apportées à votre serveur peuvent prendre un certain temps pour se propager sur tous les appareils iOS.

Liens universels et schémas d'URL personnalisés

Comprendre les différences architecturales entre les liens universels et les schémas personnalisés aide les développeurs à concevoir des systèmes de routage multiplateforme résilients, comme l'explique notre comparaison des Liens universels et schémas d'URL :

Bien que les liens universels soient supérieurs en termes de sécurité et d'expérience utilisateur, les schémas personnalisés sont encore fréquemment conservés comme solutions de secours face aux navigateurs intégrés aux applications de réseaux sociaux tenaces, détaillés dans notre guide sur la navigation du navigateur dans l'application.

Comment iOS traite les liens universels au moment de l'exécution

Lorsqu'un utilisateur d'iPhone appuie sur un lien dans Apple Mail, Messages ou une application tierce, iOS exécute un flux de décision précis :

1. Recherche dans la base de données locale : iOS vérifie sa base de données indexée locale des domaines vérifiés stockés lors de l'installation de l'application.
2. Évaluation du chemin : si le domaine correspond, iOS évalue si le chemin de l'URL correspond aux modèles définis dans le document AASA.
3. Vérification des préférences utilisateur : iOS vérifie si l'utilisateur a déjà activé les préférences Safari en appuyant sur le bouton de fil d'Ariane du domaine en haut à droite.
4. Transfert natif : si toutes les vérifications réussissent, iOS lance l'application native et transmet un objet NSUserActivity contenant l'URL cliquée au délégué d'application ou au gestionnaire de cycle de vie SwiftUI.
5. Remplacement Safari : si l'application est manquante, si le chemin ne correspond pas ou si le domaine n'est pas vérifié, iOS lance Safari et récupère la page Web normalement.

Les développeurs peuvent tester ces transitions de routage à l'aide de notre outil de vérification de liens interactif pour vérifier les codes de réponse et les mappages de domaines.

Meilleures pratiques pour la mise en œuvre des liens universels

Pour garantir un routage Universal Link sans faille dans vos campagnes marketing et votre infrastructure de développement, respectez ces bonnes pratiques éprouvées :

• N'encapsulez jamais les liens universels dans des redirections standards : si un lien passe par une redirection 301/302 générique sur un domaine non associé, iOS rompt la chaîne et achemine le clic vers Safari. Apprenez-en davantage dans notre guide des liens profonds et des raccourcisseurs.
• Compte pour les navigateurs sociaux intégrés aux applications : des applications comme Instagram, TikTok et Facebook capturent les clics dans des vues Web en bac à sable. Utilisez des liens profonds intelligents optimisés par DSLink qui détectent la vue Web et déclenchent des poignées de main d'intention pour s'échapper.
• Prise en charge des chemins de contenu universels : assurez-vous que votre application mobile native et votre serveur Web partagent des chemins de routage d'URL cohérents (par exemple, les itinéraires /item/123 vers le même produit sur le Web et dans l'application).
• Validez la syntaxe AASA en permanence : utilisez l'outil de validation de l'API App Search d'Apple pour vérifier que votre fichier AASA reste valide, non corrompu et correctement formaté après chaque déploiement de serveur.

En maîtrisant Apple Universal Links et en les associant à un routage intelligent multiplateforme, vous offrez des expériences mobiles fluides qui maintiennent vos utilisateurs immergés dans votre logiciel natif.

Questions fréquemment posées