Aller au contenu
RECDiagnosticSDK
Thème
RECDiagnosticSDK
01 / LIVE

Chaque requête, en temps réel.

La liste en direct des requêtes de votre app, regroupées par l’écran affiché quand elles sont parties. Recherche et filtres par classe de statut et par méthode.

Observer, pas intercepter

Votre requête reste la vôtre.

Beaucoup de débogueurs intégrés prennent votre requête, l’arrêtent avant qu’elle parte, envoient une copie depuis leur propre session pour obtenir la réponse, puis rendent cette réponse à votre app. DiagnosticSDK, lui, écoute votre session.

Intercepteur classique

  1. 1Arrête votre requête avant qu’elle parte
  2. 2Envoie une copie depuis sa propre URLSession
  3. 3Rend la réponse à votre app
  • Votre URLSessionConfiguration : en-têtes, timeouts, cookies, cache, proxy
  • Votre délégué, avec son SSL pinning, ses certificats mTLS et ses challenges d’authentification

Si votre backend a besoin de cette configuration (certificat mTLS, pinning, proxy, en-têtes de session), votre app ne marche plus avec ce genre de débogueur. Elle ne remarche qu’une fois cette configuration passée au débogueur, pour qu’il la reconstruise dans sa propre URLSession.

DiagnosticSDK

  • Votre configuration est utilisée telle quelle
  • Votre délégué s’exécute : SSL pinning, mTLS, challenges d’authentification
  • Pas de proxy, pas de certificat à installer

La requête est celle que votre app envoie : elle marche partout où votre app marche.

Comment ça marche

Une requête, trois moments.

Suivez une requête. À chaque moment, le SDK en lit un peu plus. Il ne modifie jamais la requête.

  1. 1 · Départ

    Votre code appelle resume()

    Le SDK note l’heure de départ et l’écran affiché.

    requête
    GET /v1/accounts
    écran
    HomeViewController
    départ
    10:32:04.412
  2. 2 · En route

    iOS envoie la requête normalement

    Chaque appel arrive d’abord à votre délégué, inchangé. Ensuite, le SDK lit le statut et la réponse.

    requête
    GET /v1/accounts
    statut
    200
    réponse
    { "accounts": [ … ] }
  3. 3 · Arrivée

    La requête apparaît dans Live

    iOS transmet ses propres mesures de temps. La requête s’affiche sous son écran, complète.

    requête
    GET /v1/accounts
    réseau
    124 ms
    app
    151 ms · h2

Ce qui reste exactement comme avant

  • La requête part une seule fois, depuis votre propre session.
  • Votre délégué reçoit tous ses appels, inchangés.
  • Pinning, mTLS, cookies, cache et timeouts continuent de fonctionner.
  • Les temps sont ceux de la vraie requête.

Des temps mesurés par iOS

Où sont passées les 124 ms ?

Live ne chronomètre pas la requête de l’extérieur. Il lit les mesures qu’iOS prend pendant l’échange (URLSessionTaskMetrics) et les découpe en étapes.

Réseaumesuré par iOS

124 ms

Ressenti par votre appde resume() à votre code

151 ms

Les 27 ms hachurées : la requête a attendu avant de partir, ou la réponse a attendu avant d’atteindre votre code, par exemple sur une file occupée.

  1. Recherche DNS9 msTrouver l’adresse du serveur. Long ? DNS lent, ou premier appel vers ce domaine.
  2. Connexion18 msOuvrir la connexion. Elle disparaît quand une connexion est réutilisée.
  3. Négociation TLS27 msMettre en place le chiffrement. À chaque requête ? Les connexions ne sont pas réutilisées.
  4. Envoi2 msLa requête et son corps quittent le téléphone. Long ? Gros envoi ou réseau lent.
  5. Attente serveur56 msVotre backend prépare la réponse (time to first byte). Long ? Regardez côté serveur.
  6. Téléchargement12 msLa réponse arrive. Long ? Réponse lourde ou réseau lent.
Protocole
h2
Connexion réutilisée
Non
Depuis le cache
Non
Redirections
0
Reçu
18 ko

Quand iOS ne fournit pas de mesures, Live l’indique (source : Clock) et affiche seulement la durée ressentie par votre app.

Valeurs d’exemple.

Rattachement aux écrans

Chaque requête, sous son écran.

Live range chaque requête sous l’écran affiché quand elle est partie : vous lisez le trafic dans l’ordre de la navigation.

Comment Screen Map le construit

Lire une requête

Trouver la bonne requête, la lire sans effort.

  • Rechercher et filtrer

    Recherche par URL, filtres par classe de statut et par méthode.

  • JSON lisible

    Les corps sont indentés et colorés, prêts à copier.

  • Jetons décodés

    Un JWT dans un en-tête ou un corps ? Live montre ce qu’il contient.

Ce que Live ne voit pas

Les limites, dites clairement.

  • WKWebView

    Les pages d’une WKWebView se chargent dans le processus de WebKit, en dehors de votre app. Leurs requêtes, y compris les appels fetch et XHR de la page, ne passent jamais par votre URLSession : Live ne peut pas les voir.

    Les requêtes que votre app fait elle-même avec URLSession, autour de la web view, sont capturées.

  • Hors URLSession

    Live voit les requêtes HTTP et HTTPS faites avec URLSession. Les WebSockets, les connexions Network.framework, les sockets bruts et les bibliothèques qui ont leur propre pile réseau ne sont pas capturés.

    Les bibliothèques construites sur URLSession sont capturées comme le reste.

  • Corps non JSON

    Un corps n’est enregistré que si son Content-Type contient application/json ou +json. Les autres corps (HTML, images, formulaires, texte, ou JSON envoyé sans cet en-tête) ne sont pas enregistrés : une courte note avec leur type les remplace. Seules les réponses JSON peuvent être rejouées.

    L’URL, la méthode, les en-têtes, le statut, la taille et les temps restent enregistrés.

Comment ça marche, dans la doc Toutes les limites connues Suivant : Screen Map