Appy

Outil dev gratuit

Validateur de liens universels

Assurez-vous que vos liens ouvrent votre application. Collez un domaine pour vérifier les Universal Links iOS et les App Links Android, puis obtenez un résultat clair avec les étapes de correction à transmettre à l’équipe technique.

Lancer une validation
Collez un domaine ou une URL et validez votre configuration d’ouverture d’app.

Fonctionnement

Ce qui se passe quand quelqu’un touche votre lien

Aucune des deux plateformes ne consulte votre domaine au moment du toucher. Elles le vérifient à l’installation de l’app, mémorisent la réponse et s’en servent quand un lien est touché. C’est pour cela qu’un fichier cassé peut passer inaperçu pendant des jours, et qu’un fichier corrigé ne change rien tout de suite.

iPhone et iPad

apple-app-site-association
  1. À l’installation

    Lit Associated Domains

    iOS consulte les entrées applinks: de l’entitlement Associated Domains de l’app.

  2. À l’installation

    Passe par le CDN d’Apple

    Le CDN d’Apple télécharge le fichier sur votre domaine et remet à l’appareil sa copie en cache.

  3. Au toucher

    Compare le lien

    iOS compare le domaine et le chemin touchés avec les app IDs et les règles paths ou components de ce fichier.

  4. Résultat

    Correspondance : votre app s’ouvre

    Pas de correspondance ou pas de fichier : Safari ouvre la page

Android

assetlinks.json
  1. À l’installation

    Lit les intent filters

    Android repère les intent filters marqués autoVerify pour votre domaine.

  2. À l’installation

    Récupère assetlinks.json

    Il demande le fichier dans /.well-known/ sur chaque hôte déclaré. Une redirection compte comme un échec.

  3. À l’installation

    Vérifie le certificat de signature

    Le package name et l’empreinte SHA-256 du fichier doivent correspondre au certificat qui a signé l’app installée.

  4. Résultat

    Vérifié : votre app s’ouvre

    Non vérifié : le navigateur s’ouvre, ou un sélecteur d’apps sur les anciennes versions d’Android

Le validateur couvre la partie serveur des deux chaînes : chaque fichier se trouve-t-il là où iOS et Android le cherchent, et contient-il ce qu’ils doivent y lire.

Vérifications

Ce que vérifie cet outil

Chaque analyse envoie jusqu’à dix requêtes : les deux fichiers d’association sur votre domaine et sur son jumeau avec ou sans www, la copie du CDN d’Apple et la Digital Asset Links API de Google. Voici ce qu’il regarde.

  • Deux emplacements, deux hôtes

    Cherche apple-app-site-association dans /.well-known/ et à la racine, et assetlinks.json dans /.well-known/, sur votre domaine comme sur sa version www.

  • HTTPS et un 200

    Indique le code HTTP de chaque requête, ainsi que les délais dépassés et les erreurs de connexion qui empêchent un fichier de se charger.

  • Redirections

    Suit les redirections, montre où chaque requête a abouti et signale une URL finale sur un autre hôte ou en HTTP simple.

  • Du HTML à la place du JSON

    Repère une page de connexion, un modèle d’erreur ou un challenge anti-bot de Cloudflare, Akamai ou d’un service similaire, et affiche l’en-tête Content-Type reçu.

  • JSON valide

    Analyse chaque fichier et cite l’erreur du parseur en cas d’échec, pour que vous sachiez quoi corriger.

  • applinks et app IDs

    Vérifie que applinks.details existe et liste tous ses app IDs. Ajoutez votre App ID dans Avancé pour contrôler qu’il y figure. Les fichiers signés (PKCS7) sont reconnus, pas décodés.

  • Relation et package names

    Vérifie qu’assetlinks.json est un tableau JSON avec la relation delegate_permission/common.handle_all_urls et liste ses package names. Ajoutez votre package dans Avancé pour le comparer.

  • Empreinte SHA-256

    Collez l’empreinte de votre certificat de signature dans Avancé : le validateur la cherche dans le fichier, avec ou sans deux-points.

  • La copie d’Apple, la vue de Google

    Lit la copie que le CDN d’Apple sert aux iPhone et demande à la Digital Asset Links API de Google ce qu’elle trouve pour votre site, pour comparer les deux avec votre serveur.

Pas encore de fichier, ou un JSON qui ne passe pas ?Créez-le avec le générateur AASA et assetlinks.json

Ce qu’il ne voit pas

Le côté app : l’entitlement Associated Domains, les intent filters, la correspondance d’un chemin donné avec vos règles paths ou components, et le comportement de tel ou tel navigateur in-app. Testez-les sur un vrai appareil avant un lancement.

Dépannage

Pourquoi les liens ouvrent encore le navigateur

La plupart des cas se ramènent à l’une de ces huit causes. Celles côté serveur apparaissent dans le validateur ; les autres ne se voient que sur un vrai téléphone.

  1. 01iOS + Android

    Le toucher a lieu dans Instagram, Facebook ou TikTok

    Ça marche depuis Notes ou Messages, mais la bio ou une pub ouvre une page web.

    Correctif

    Ces apps ouvrent les liens dans leur propre navigateur in-app, qui garde souvent l’URL au lieu de la passer à iOS ou Android. Testez chaque canal séparément et assurez-vous que le lien mène quelque part d’utile même si l’app ne s’ouvre pas, comme la fiche du store ou votre site web.

    À tester sur un appareilDeep links sur Instagram et TikTok
  2. 02iOS + Android

    Le fichier d’association redirige

    Le fichier s’ouvre bien dans le navigateur, mais la vérification échoue.

    Correctif

    Apple et Android attendent un 200 direct sur l’URL exacte. Supprimez sur /.well-known/ les redirections http vers https, domaine nu vers www ou par langue.

    Visible dans le validateurVos liens universels ouvrent Safari ?
  3. 03iOS + Android

    Mauvais Content-Type

    Le fichier se charge, mais la plateforme l’ignore.

    Correctif

    Servez les deux fichiers en application/json. Le fichier AASA n’a pas d’extension, donc beaucoup de serveurs envoient application/octet-stream ou text/plain.

    Visible dans le validateurVos liens universels ouvrent Safari ?
  4. 04iOS

    Le CDN d’Apple garde l’ancien fichier

    Vous avez corrigé le fichier, mais les iPhone ouvrent toujours Safari.

    Correctif

    Le CDN d’Apple sert une copie en cache qui a du retard sur votre serveur ; le validateur affiche les deux. Pendant les tests, ajoutez ?mode=developer à l’entitlement et activez Associated Domains Development dans les réglages développeur de l’appareil.

    Visible dans le validateurGuide complet des liens universels
  5. 05Android

    La clé Play App Signing manque

    Vos builds ouvrent l’app, les installations depuis le Play Store ouvrent le navigateur.

    Correctif

    Avec Play App Signing, c’est Google qui signe l’app installée. Ajoutez le SHA-256 indiqué dans la Play Console, sous Intégrité de l’application, certificat de la clé de signature d’application. Gardez aussi la clé d’importation si vous distribuez des builds hors du Play Store.

    Visible dans le validateurAndroid App Links non vérifiés
  6. 06iOS

    Le lien pointe vers le domaine de la page

    Les boutons de votre site ouvrent d’autres pages web au lieu de l’app.

    Correctif

    iOS garde l’utilisateur dans Safari quand il touche un lien universel vers le domaine sur lequel il se trouve déjà. Placez les liens d’app sur un sous-domaine distinct, ou utilisez une Smart App Banner sur le site.

    À tester sur un appareilGuide complet des liens universels
  7. 07iOS

    L’utilisateur a choisi Safari une fois

    Le lien marche sur votre téléphone, pas sur celui d’un collègue.

    Correctif

    Toucher le domaine en haut à droite après l’ouverture de l’app indique à iOS de préférer Safari pour ce domaine. Pour revenir en arrière, appuyez longuement sur le lien et choisissez de l’ouvrir dans l’app.

    À tester sur un appareilVos liens universels ouvrent Safari ?
  8. 08iOS

    L’App ID ne correspond pas au build

    Ça marche sur le build de staging, pas sur le build de production.

    Correctif

    L’entrée doit combiner votre Team ID et le bundle ID exact de l’app publiée, par exemple ABCDE12345.com.example.app. Saisissez-le dans Avancé et le validateur le contrôle.

    Visible dans le validateurGuide complet des liens universels

Sans la tuyauterie

Des liens qui fonctionnent, tout simplement

Un lien Appy examine chaque toucher et l’envoie au bon endroit : l’App Store sur iPhone, Google Play sur Android, votre site sur un ordinateur. Activez les deep links avec Pro et ceux qui ont déjà l’app y arrivent directement.

  • Offre gratuite
  • Sans carte bancaire
  • Clics illimités sur toutes les offres
  • Vos liens continuent de marcher si vous résiliez

Avec Enterprise, votre app reçoit son propre domaine de liens, et Appy y héberge apple-app-site-association et assetlinks.json pour vous. Comment fonctionne le SDK

Questions fréquentes

Qu’est-ce que le fichier apple-app-site-association (AASA) ?

Un fichier JSON placé sur votre domaine qui indique à iOS quelles apps peuvent ouvrir quels liens. Il se trouve à https://votre-domaine/.well-known/apple-app-site-association, sans extension .json, et liste vos app IDs (Team ID plus bundle ID) avec les règles paths ou components qu’ils prennent en charge.

Où les fichiers d’association doivent-ils se trouver ?

iOS lit /.well-known/apple-app-site-association et Android lit /.well-known/assetlinks.json, sur chaque hôte utilisé dans vos liens. Les deux doivent se charger en HTTPS avec un 200 direct, sans redirection, et avec le content type application/json.

Pourquoi les liens universels ouvrent-ils Safari au lieu de mon app ?

Soit la vérification a échoué (fichier absent, redirigé ou invalide, ou app ID qui ne correspond pas au build), soit iOS a choisi Safari exprès : le toucher venait d’un navigateur in-app ou d’une page du même domaine, ou l’utilisateur a déjà choisi Safari. Lancez d’abord le validateur ; s’il ne signale rien, testez ces cas sur un appareil.

Comment vérifier mon assetlinks.json ?

Saisissez votre domaine plus haut et ouvrez Avancé pour ajouter votre package name et votre empreinte SHA-256. Sur un téléphone de test, adb shell pm get-app-links com.example.app indique si Android a marqué chaque domaine comme vérifié.

Pourquoi Android indique-t-il que la vérification des App Links a échoué ?

Le plus souvent, l’empreinte d’assetlinks.json est celle de votre clé d’importation, alors que les installations depuis le Play Store sont signées avec la clé de signature de Google. Viennent ensuite les redirections, un mauvais content type et une protection anti-bot sur /.well-known/. Après correction, lancez adb shell pm verify-app-links --re-verify com.example.app.

Combien de temps faut-il à Apple pour prendre en compte un AASA modifié ?

Il n’y a pas de rafraîchissement immédiat. Les appareils reçoivent le fichier du CDN d’Apple, qui sert une copie en cache ; une correction sur votre serveur met donc du temps à arriver. Le validateur affiche la copie du CDN à côté de la vôtre. En développement, ?mode=developer sur l’entitlement permet à l’appareil de lire le fichier directement sur votre serveur.

Les liens universels fonctionnent-ils dans Instagram, Facebook ou TikTok ?

Souvent non. Ces apps ouvrent les liens dans leur propre navigateur in-app, et le fait que le toucher atteigne votre app dépend de l’app et de l’emplacement. Testez chaque canal et vérifiez que votre site web et la fiche du store tiennent la route comme destinations à part entière.

Le validateur vérifie-t-il mon app, mes entitlements ou mes chemins ?

Non. Il lit ce que renvoient votre serveur, le CDN d’Apple et la Digital Asset Links API de Google. Le côté app, c’est-à-dire l’entitlement Associated Domains, les intent filters et la correspondance d’un chemin avec vos règles, demande un test sur un vrai appareil.

Quelle différence entre deep links et liens universels ?

Un deep link est tout lien qui ouvre un écran précis d’une app. Les Universal Links d’iOS et les App Links d’Android en sont la version vérifiée : des URL HTTPS ordinaires qui ouvrent l’app si elle est installée, et une page web sinon.

Faut-il un compte ? Puis-je partager le résultat ?

Aucun compte n’est nécessaire et le validateur est gratuit. Chaque analyse a sa propre URL, à copier et envoyer à votre développeur. Ces pages de résultats ne sont pas indexées par les moteurs de recherche.