Tous les articles
mobiledeep linksiOSAndroid

Tester les deep links mobile avec un tunnel localhost

Universal Links iOS et App Links Android exigent un fichier JSON servi en HTTPS à la racine de votre domaine. iOS veut /.well-known/apple-app-site-association. Android veut /.well-known/assetlinks.json. Localhost ne peut servir ni l'un ni l'autre sur un hostname que l'OS associera à votre app. Donc tunnel.

L'exigence sur chaque plateforme

iOS Universal Links

L'OS récupère https://votre-domaine.com/.well-known/apple-app-site-association à l'installation. Vérifie le contenu contre l'entitlement associated-domains. HTTPS réel, pas de self-signed, pas de localhost.

Android App Links

Android vérifie via https://votre-domaine.com/.well-known/assetlinks.json. Le fichier liste les fingerprints SHA-256 de votre app. Même contrainte : HTTPS réel, domaine réel.

Pourquoi localhost ne peut pas

Même avec mkcert qui donne un HTTPS reconnu dans le navigateur, l'OS mobile ne fait pas confiance à votre CA locale. Et le domaine dans apple-app-site-association doit matcher l'associated-domain de l'app — un vrai domaine DNS, pas localhost.

Un tunnel localhost donne une URL HTTPS réelle sur un sous-domaine réel.

Câblage

  1. Servez apple-app-site-association et assetlinks.json depuis votre dev server sous /.well-known/.
  2. npx portpreview 3000.
  3. Notez l'hostname tunnel.
  4. Entitlement iOS : ajoutez applinks:abc123.portpreview.dev. Intent filter Android : même host.
  5. Buildez et installez sur un vrai device (les simulateurs ont un comportement Universal Link bizarre).
  6. Ouvrez l'URL depuis une autre app — Notes, Mail, QR code — et regardez-la router vers l'app.

Le piège : le hostname tunnel change entre sessions sauf sous-domaine réservé. Chaque rotation demande un rebuild app.

Content-type pour apple-app-site-association

iOS attend application/json (récent) ou application/pkcs7-mime (ancien, signé). Presque tous les apps modernes utilisent le JSON simple. Vérifiez depuis un navigateur desktop d'abord.

Autres pièges deep link

Entitlement vs JSON

Si l'entitlement dit applinks:abc.portpreview.dev mais le JSON liste def.portpreview.dev, iOS ne fetch pas.

Universal Link depuis Safari

Tap dans Safari ouvre parfois dans Safari plutôt que l'app — by design. Testez depuis Notes ou Mail.

URL schemes custom Android

Android supporte aussi custom URL schemes (monapp://path) sans HTTPS. Plus simples mais moins sûrs (n'importe quelle app peut enregistrer le même scheme). App Links pour la qualité production.

Notre flow mobile

  1. Backend qui sert les fichiers .well-known.
  2. Tunnel avec npx portpreview 3000.
  3. URL stable (ou sous-domaine réservé) → entitlements et build.
  4. QA sur devices physiques — fresh installs et updates.
  5. OAuth + deep link : combinez avec test OAuth en local.

Voir aussi tests mobile avec tunnel. Rejoignez la waitlist PortPreview.

Questions fréquentes

Peut-on tester les Universal Links iOS sur localhost ?
Pas directement. Universal Links exigent qu'iOS récupère apple-app-site-association en HTTPS réel depuis un vrai domaine. localhost ne convient pas. Un tunnel donne une URL HTTPS sur un sous-domaine qu'iOS associera à votre app si listé dans l'entitlement.
Quel content-type pour apple-app-site-association ?
iOS moderne attend application/json. Les anciennes versions acceptaient aussi application/pkcs7-mime pour les fichiers signés. La plupart des apps utilisent JSON simple. Si iOS ne prend pas le fichier, vérifiez le content-type depuis un navigateur desktop.
Les App Links Android nécessitent-ils un tunnel en local ?
Oui pour la vérification App Links complète (pas les custom URL schemes). Android récupère assetlinks.json en HTTPS réel depuis le domaine de votre intent filter. Un tunnel fournit cette URL. Les custom schemes n'en ont pas besoin mais sont moins sécurisés.