Skip to content
RECDiagnosticSDK
Theme
RECDiagnosticSDK
01 / LIVE

Every request, as it happens.

A real-time list of your app’s requests, grouped by the screen on display when they started. Search, filter by status class and method.

Observation, not interception

Your request stays yours.

Many in-app debuggers take your request, stop it before it leaves, send a copy from their own session to get the response, then hand that response back to your app. DiagnosticSDK listens to your session instead.

Classic interceptor

  1. 1Stops your request before it leaves
  2. 2Sends a copy from its own URLSession
  3. 3Hands the response back to your app
  • Your URLSessionConfiguration: headers, timeouts, cookies, cache, proxy
  • Your delegate and its SSL pinning, mTLS certificates and authentication challenges

If your backend needs this configuration (an mTLS certificate, pinning, a proxy, session headers), your app stops working with such a debugger. It only works again once you hand that configuration to the debugger, so it can rebuild it in its own URLSession.

DiagnosticSDK

  • Your configuration is used as it is
  • Your delegate runs: SSL pinning, mTLS, authentication challenges
  • No proxy, no certificate to install

The request is the one your app sends, so it works wherever your app works.

How it works

One request, three moments.

Follow one request. At each moment, the SDK reads one more piece of it. It never changes the request.

  1. 1 · Start

    Your code calls resume()

    The SDK notes the start time and the screen on display.

    request
    GET /v1/accounts
    screen
    HomeViewController
    started
    10:32:04.412
  2. 2 · On the way

    iOS sends the request as usual

    Each callback reaches your delegate first, unchanged. Then the SDK reads the status and the response.

    request
    GET /v1/accounts
    status
    200
    response
    { "accounts": [ … ] }
  3. 3 · Done

    The request shows up in Live

    iOS hands over its own timing measurements. The request appears under its screen, complete.

    request
    GET /v1/accounts
    network
    124 ms
    app
    151 ms · h2

What stays exactly as it was

  • The request leaves once, from your own session.
  • Your delegate receives every call, unchanged.
  • Pinning, mTLS, cookies, cache and timeouts keep working.
  • The timings are those of the real request.

Timing measured by iOS

Where did the 124 ms go?

Live does not time the request from the outside. It reads the measurements iOS takes during the exchange (URLSessionTaskMetrics) and splits them into steps.

Networkmeasured by iOS

124 ms

Felt by your appfrom resume() to your code

151 ms

The striped 27 ms: the request waited before leaving, or the response waited before reaching your code, for example on a busy queue.

  1. DNS lookup9 msFinding the server address. Long? Slow DNS, or the first call to this domain.
  2. Connection18 msOpening the connection. It disappears when a connection is reused.
  3. TLS handshake27 msSetting up encryption. On every request? Connections are not being reused.
  4. Request sent2 msThe request and its body leave the phone. Long? Large upload or slow network.
  5. Server wait56 msYour backend prepares the response (time to first byte). Long? Look at the server.
  6. Download12 msThe response arrives. Long? Heavy response or slow network.
Protocol
h2
Reused connection
No
Served from cache
No
Redirects
0
Received
18 kB

When iOS gives no measurements, Live says so (source: Clock) and only shows the duration felt by your app.

Example values.

Screen attribution

Each request, under its screen.

Live files every request under the screen on display when it started, so you read the traffic in the order of the navigation.

How Screen Map builds it

Reading a request

Find the right request, read it without effort.

  • Search and filter

    Search by URL, filter by status class and method.

  • Readable JSON

    Bodies are indented and colored, ready to copy.

  • Decoded tokens

    A JWT in a header or a body? Live shows what it contains.

What Live does not see

The limits, stated clearly.

  • WKWebView

    Pages in a WKWebView load in WebKit’s own process, outside your app. Their requests, including fetch and XHR calls from the page, never go through your URLSession, so Live cannot see them.

    Requests your app makes itself with URLSession, around the web view, are captured.

  • Outside URLSession

    Live sees HTTP and HTTPS requests made with URLSession. WebSockets, Network.framework connections, raw sockets and libraries with their own network stack are not captured.

    Libraries built on URLSession are captured like the rest.

  • Non-JSON bodies

    A body is saved only when its Content-Type contains application/json or +json. Other bodies (HTML, images, form data, plain text, or JSON sent without that header) are not saved: a short note with their type takes their place. Only JSON responses can be replayed.

    URL, method, headers, status, size and timing are still recorded.

How it works, in the docs All known limitations Next: Screen Map