Triage par couches · ssh -L minimal · ATS et trousseau · tableau de scénarios · validation en cinq étapes
Windows au quotidien plus un Mac cloud loué est un duo iOS très courant en 2026. Le motif support récurrent : compilation OK, Simulateur lancé, mais chaque appel réseau expire ou TLS échoue. La cause est rarement Swift : c’est la sémantique de localhost — le Simulateur tourne sur le Mac distant, donc 127.0.0.1 désigne ce Mac, pas votre PC. L’article propose un modèle de triage en couches, une redirection locale OpenSSH minimale (ssh -L) avec garde-fous, des repères sur ATS, confiance auto-signée et dialogues système qui exigent encore une session VNC, une matrice scénarios → forward / bastion / VNC et une checklist en cinq étapes à coller dans les tickets. À lire avec réseau d’entreprise & tunnel SSH (joindre le bureau), Git vs SFTP et la checklist première utilisation. Les équipes confondent souvent « le bureau répond » et « l’API sur mon PC répond » : séparer ces deux preuves évite les doubles tickets pare-feu / appli.
Découpez avant de toucher au code. Couche A : le Mac distant n’a pas de sortie Internet — revenez au guide entreprise. Couche B : la sortie marche, mais l’app pointe vers un service qui n’existe que sur le localhost du portable — il faut rediriger ou déplacer l’API. Couche C : API sur segment RFC1918 — VPN puis forward. Couche D : TLS, ATS ou trousseau — souvent une validation GUI unique. La liste ci-dessous regroupe les erreurs de diagnostic les plus fréquentes. Vérifiez aussi si le proxy d’entreprise sur le Mac applique des règles différentes du PC : le ping peut réussir pendant qu’URLSession échoue.
Accuser l’appli en premier : sur l’hôte distant lancez curl -v http://127.0.0.1:PORT/health. Si ça échoue, corrigez le transport avant Swift.
Traiter le Simulateur comme un périphérique USB : pas de lien direct vers la carte réseau du PC ; toute la pile est sur le Mac cloud.
« Forwarding actif » sans adresse de bind : si le backend n’écoute qu’une interface ou qu’IPv6 intervient, le tunnel reste vide — vérifiez le triplet.
Désactiver ATS globalement : exceptions par domaine dans Info.plist ; pas de NSAllowsArbitraryLoads permanent pour les builds publiables.
SSH seul : certificats client, ancres Safari et invites « réseau local » exigent souvent la même session interactive qu’Xcode — SSH texte ne clique pas.
À retenir : mettez dans le titre du ticket « quel machine possède localhost ? » — cela évite un aller-retour complet.
Objectif : un service Node ou Spring sur Windows à 127.0.0.1:3000 doit être joignable depuis le Mac distant comme s’il vivait sur sa boucle locale. Ouvrez SSH depuis Windows vers l’hôte cloud et liez un port côté distant au service local. Schéma courant :
ssh -N -L 127.0.0.1:19000:127.0.0.1:3000 [email protected]
-N évite le shell distant ; le trafic vers 127.0.0.1:19000 sur le Mac distant traverse le tunnel vers 127.0.0.1:3000 sur Windows. Pointez la baseURL de debug sur http://127.0.0.1:19000. Si l’API est sur un autre hôte intranet, remplacez le membre de droite — le portable doit déjà router (VPN). Documentez des plages de ports (ex. 19xxx pour le pair programming). Pour WebSocket/gRPC, vérifiez en-têtes et chemins : certains proxys réécrivent ce que le TCP seul ne montre pas.
Sécurité : lier à la loopback, pas à 0.0.0.0 sans analyse d’exposition ; le tunnel meurt avec la session — veille, roaming Wi‑Fi ; certains hébergeurs restreignent AllowTcpForwarding ; validez avec la sécurité si les tunnels inverses sont interdits. En exigence de conformité, remplacez les forwards ad hoc par un petit nginx sur le Mac distant ou une passerelle API contrôlée.
La redirection prouve la livraison TCP. App Transport Security, confiance serveur et certificats client décident si URLSession accepte la réponse. Les équipes ajoutent NSExceptionDomains, importent une AC maison dans le trousseau de session ou règlent le proxy — opérations naturelles dans Réglages système et Accès au trousseau en session graphique. SSH seul ne reproduit pas les clics de confiance ni la preuve que le même utilisateur qu’Xcode possède l’identité. Charles ou Proxyman exigent aussi une première validation GUI. Dans les environnements réglementés, notez qui importe quel certificat et quand.
Considérez VNC comme le lieu des acceptations ponctuelles : confidentialité réseau local, micro qui bloque parfois la pile réseau, pièces jointes Safari Web Inspector. SSH reste le plan de contrôle pour redirections et automatisation. Combiner les deux réduit le temps moyen de diagnostic. Les builds sans tête restent séparées ; le debug interactif vit sur un bureau traçable — d’où les Mac cloud exposant SSH et VNC.
La redirection dit si les paquets arrivent ; ATS et le trousseau disent si iOS leur fait confiance — souvent un sujet VNC.
Servez-vous du tableau en revue de conception pour séparer « joindre le bureau » et « raccrocher le trafic API ». Cela évite les doublons tickets pare-feu / appli.
| Scénario | Chemin préféré | VNC encore pour |
|---|---|---|
| API sur loopback Windows | ssh -L vers loopback distant ; app sur le port mappé | Exceptions ATS, ancres de confiance, proxy |
| API intranet | VPN portable puis forward ; double saut bastion si besoin | Inscription certificat client, confiance navigateur |
| Host header ou mTLS | nginx inverse sur le Mac distant avec server_name | Import d’identités dans le trousseau |
| CI headless seulement | Scripts SSH, pas d’UI | Souvent rien sauf échec de signature Organizer |
| Nœud loué partagé | Plages de ports par ingénieur ; pas de scan croisé | Séparation de comptes, profils de provisioning |
Ergonomie tunnel et compression : notes SSH ; cet article cible la couche application avec ATS.
Sonde loopback distante : curl sur le port mappé depuis le Mac cloud ; copier statut HTTP et erreurs TLS.
Aligner baseURL : contrôler Debug/Staging sur Swift, React Native ou Flutter pour une seule vérité sur l’hôte.
Instantané ATS : joindre le bloc d’exceptions Info.plist au ticket pour éviter les régressions de fusion.
Santé SSH : keepalive, politique de veille, tunnel coupé la nuit — comparer avec reprise de session si les coupures reviennent.
VNC une fois : Safari ou Réglages pour aligner proxy, confiance et journaux serveur, puis clôturer.
Accès direct ou tunnel SSH quand le bureau est difficile à joindre.
Lire →Comment le code arrive sur le Mac cloud avant le debug API.
Lire →De l’inscription à une session Xcode fonctionnelle.
Lire →La boucle locale du Mac distant. Redirigez les ports ou hébergez l’API là où l’OS route, puis configurez ATS.
Souvent pour le TCP brut. Certificats, identités trousseau et invites système : prévoir VNC avec le même utilisateur qu’Xcode.
curl depuis le Mac distant, vérifier baseURL, ATS et processus SSH.
Celui-là traite l’accessibilité du bureau. Ici l’accessibilité API depuis le Simulateur une fois le bureau OK.
On perd le plus de temps sur des hypothèses localhost mal placées et des chaînes de confiance jamais bouclées sur la machine qui exécute le Simulateur. SSH seul masque trousseau et ATS ; VNC seul évite les contrats de ports reproductibles. Combiner transport redirigé et courte session GUI journalisée raccourcit les tickets. Ajoutez, en équipe, une ligne sur qui peut ouvrir quels ports sur un nœud partagé.
Posséder un Mac physique pour du pairing occasionnel impose encore veille système, mises à jour, énergie et amortissement. Les portables sous-dimensionnés étouffent quand backend, IDE et tunnel disputent la RAM. Un Mac distant dédié avec disponibilité gérée permet de standardiser plages de ports et images tout en gardant la maîtrise des contrats API et certificats.
Pour moins d’immobilisation matérielle tout en gardant SSH et VNC sur le même mandant, utilisez VNCMac : le bouton principal mène à la page de location ; comparez les offres sur l’accueil.