Universal Link — définition, principe de fonctionnement et configuration

Qu'est-ce qu'Universal Link

Universal Link est un lien HTTPS standard comme https://example.com/page qui, lorsqu'il est tapé sur un appareil iOS, ouvre l'application installée au lieu de Safari. La principale différence avec Custom URL Scheme : Universal Link ne nécessite pas d'enregistrer un schéma personnalisé (myapp://) — il utilise un domaine normal. Cela élimine le problème de détournement de schéma URL (URL Scheme hijacking), où n'importe quelle application peut enregistrer le même schéma.

Apple a présenté Universal Link à la WWDC 2015 dans le cadre d'iOS 9. Le mécanisme est devenu partie intégrante de l'écosystème Handoff et Spotlight : Universal Link fonctionne non seulement dans le navigateur, mais aussi dans les résultats de recherche Spotlight, Mail, Messages et d'autres applications système. De plus, Universal Link est pris en charge sur watchOS et macOS — l'utilisateur peut ouvrir une application sur l'iPhone via un lien sur le Mac.

L'avantage clé : URL unique. Le développeur ne gère pas deux liens différents (un pour le web, un pour l'application). Universal Link est le même lien https. Si l'application est installée — elle s'ouvre. Sinon — le même lien s'ouvre dans Safari comme une page web normale. Cela offre un fallback idéal sans perte de trafic.

Comment fonctionne Universal Link

Le mécanisme d'Universal Link comprend trois étapes : vérification d'association, traitement du lien et fallback vers le navigateur. Chaque étape est critique pour le bon fonctionnement. Si l'association n'est pas configurée, iOS traite le lien comme une redirection normale vers Safari. Examinons chaque étape en détail.

Vérification d'association (Association Verification)

Au premier tap sur un lien, iOS télécharge le fichier apple-app-site-association depuis le serveur à l'adresse https://example.com/.well-known/apple-app-site-association. Le fichier contient du JSON avec le Team ID et le Bundle ID de l'application, ainsi qu'une liste de chemins que l'application doit ouvrir. iOS met ce fichier en cache et vérifie périodiquement sa fraîcheur (lors de la mise à jour de l'application, du redémarrage de l'appareil).

Le fichier JSON apple-app-site-association doit être accessible via HTTPS sans redirections. Le serveur doit retourner Content-Type : application/json. Il est important que le fichier n'ait pas d'extension .json — iOS le cherche strictement à /.well-known/apple-app-site-association. Apple recommande également d'ajouter la prise en charge d'Universal Link dans le CDN et de vérifier que le fichier n'est pas bloqué par robots.txt.

// apple-app-site-association — configuration minimale
{
    "applinks": {
        "apps": [],
        "details": [
            {
                "appID": "TEAMID.com.example.app",
                "paths": ["/product/*", "/profile/*", "/search"]
            }
        ]
    }
}

appID est formé comme Team ID + Bundle ID (TEAMID.com.example.app). paths est un tableau de motifs d'URL que l'application doit traiter. On peut utiliser *, ? et la notation NOT : ["NOT /admin/*", "/product/*"]. Les chemins sont vérifiés dans l'ordre d'énumération : la première correspondance détermine le comportement. Si le chemin ne correspond pas — le lien s'ouvre dans Safari.

Traitement du lien (Link Handling)

Après une vérification d'association réussie, iOS transmet le lien à l'application. Le traitement est effectué dans AppDelegate via la méthode application(_:continue:restorationHandler:) pour NSUserActivity, ou dans SceneDelegate via scene(_:continue:). Le développeur reçoit un objet NSUserActivity de type NSUserActivityTypeBrowsingWeb, extrait l'URL et navigue vers l'écran correspondant.

// Traitement d'Universal Link dans AppDelegate
func application(
    _ application: UIApplication,
    continue userActivity: NSUserActivity,
    restorationHandler: @escaping UIUserActivityRestorationHandler
) -> Bool {
    guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,
          let url = userActivity.webpageURL
    else { return false }

    // Naviguer vers l'écran selon l'URL
    DeepLinkRouter.navigate(to: url)
    return true
}

DeepLinkRouter dans l'exemple ci-dessus est une classe personnalisée qui analyse l'URL et appelle le coordinateur de navigation correspondant. Pour SwiftUI, le traitement est effectué via la méthode onOpenURL ou le modificateur environment(\.openURL). Il est important de traiter non seulement le démarrage au premier plan, mais aussi le cas où l'application n'était pas en cours d'exécution (démarrage à froid) : Universal Link ouvre l'application via les options de lancement dans ce cas.

Fallback vers le navigateur (Browser Fallback)

Si l'application n'est pas installée, iOS ouvre automatiquement Universal Link dans Safari. C'est une différence clé avec Custom URL Scheme : l'utilisateur ne voit pas d'erreur. Le fallback est la page web standard du même domaine. Le développeur peut placer un lien vers l'App Store, des informations sur le produit ou un contenu alternatif sur cette page.

Important : le fallback ne peut pas être personnalisé au niveau d'iOS. iOS ouvre simplement l'URL dans Safari. Pour afficher un contenu différent pour les utilisateurs avec et sans l'application installée, utilisez la Smart App Banner (une balise méta pour Safari qui propose d'ouvrir l'application) ou la détection d'installation par JavaScript. Apple fournit également SKAdNetwork pour l'attribution d'installations via Universal Link.

Universal Link vs Deep Link

Universal Link et le Deep Link traditionnel (Custom URL Scheme) résolvent le même problème, mais diffèrent fondamentalement par leur architecture et leur sécurité. Custom URL Scheme est un protocole personnalisé (myapp://) enregistré dans Info.plist. N'importe quelle application peut enregistrer le même schéma (myapp://), et iOS ne peut pas déterminer lequel est le “vrai”. C'est ce qu'on appelle le détournement de schéma URL.

Universal Link résout le problème de détournement grâce à la vérification de domaine. Seul le propriétaire du domaine peut placer apple-app-site-association sur son serveur, confirmant la connexion avec un Bundle ID spécifique. Deux applications ne peuvent pas enregistrer le même Universal Link : si un conflit survient, iOS donne la priorité à la dernière application installée ou ouvre Safari.

Une autre différence : Fallback. Custom URL Scheme n'a pas de fallback — si l'application n'est pas installée, le navigateur affiche une erreur. Universal Link ouvre le site web. Une URL unique signifie que la valeur SEO du lien est préservée (Google indexe le lien) et qu'un utilisateur avec n'importe quel appareil reçoit un contenu pertinent. Universal Link est une étape évolutive du deep link vers le lien unifié.

Configuration d'Universal Link

La configuration d'Universal Link comprend la partie serveur et la partie cliente. La partie serveur — placer le fichier apple-app-site-association à https://domain/.well-known/apple-app-site-association. La partie cliente — enregistrer le domaine dans Associated Domains dans Xcode (Capabilities → Associated Domains → applinks:example.com). Après cela, l'application reçoit automatiquement tous les Universal Links pour le domaine spécifié.

Étapes de configuration :

1. Créer apple-app-site-association avec le bon appID (TeamID.BundleID) et paths
2. Placer le fichier sur le serveur dans /.well-known/ sans extension .json
3. Vérifier la disponibilité : curl https://domain/.well-known/apple-app-site-association
4. Ajouter le domaine dans Associated Domains (Xcode Capabilities)
5. Implémenter le traitement via NSUserActivity (AppDelegate ou SceneDelegate)
6. Tester sur un appareil réel (le simulateur ne vérifie pas l'association)

Le débogage d'Universal Link est un casse-tête courant pour les développeurs iOS. Les principales causes de liens non fonctionnels : fichier apple-app-site-association inaccessible via HTTPS, appID incorrect, Content-Type différent de application/json, redirection depuis le chemin /.well-known, mise en cache de l'ancienne version (réinitialisation via Settings → Developer → Associated Domains Development). Apple fournit l'outil Validation Checker dans Apple Developer Console pour tester l'association.

Branch et d'autres plateformes MMP simplifient la configuration d'Universal Link : ils génèrent apple-app-site-association automatiquement et l'hébergent sur leur propre domaine. Le développeur doit simplement ajouter le domaine Branch à Associated Domains et intégrer le SDK. C'est particulièrement pratique pour les startups qui n'ont pas leur propre infrastructure serveur pour héberger le fichier AASA.

Limitations et compatibilité

Universal Link a plusieurs limitations. Premièrement : le fichier apple-app-site-association doit être accessible strictement via HTTPS (HTTP n'est pas pris en charge). Deuxièmement : le lien doit pointer vers le même domaine que celui spécifié dans Associated Domains. Les Universal Links inter-domaines ne fonctionnent pas — chaque domaine nécessite une entrée séparée dans Capabilities et un fichier AASA séparé. Troisièmement : Universal Link ne fonctionne pas dans WKWebView — seulement dans Safari et les composants système.

Compatibilité : iOS 9.0+ (Universal Link), watchOS 6.0+ (Handoff Universal Link), macOS 10.15+ (Catalyst et applications Mac). Sur les versions antérieures d'iOS, le lien s'ouvre dans Safari. Cela signifie que sur iOS 8 (moins de 1% des appareils), Universal Link ne fonctionnera pas. Il est recommandé de également prendre en charge Custom URL Scheme comme fallback pour les appareils plus anciens si votre public inclut des utilisateurs avec des versions obsolètes.

Changements dans iOS 16+ : Apple a amélioré le traitement d'Universal Link pour SwiftUI. Un nouveau modificateur environment(\.openURL) avec capacité de traitement différé a été introduit. iOS 16 permet également d'ouvrir les Universal Links dans l'application même via SFSafariViewController. Pour les utilisateurs d'iOS 16, il est recommandé de migrer complètement vers le traitement d'Universal Link avec SwiftUI, en laissant le code AppDelegate uniquement pour la rétrocompatibilité.