Connecting to existing iPerf3 servers from iOS
The most common workflow is to point the iOS client at an iperf3 server you already control. That can be a Linux VM in your home lab, an iperf3 daemon on a Raspberry Pi, a public test server like the iperf.fr or speedtest.serverius.net endpoints, or another iPhone running this same app in Server mode. The client accepts hostnames or IP addresses, IPv4 or IPv6 (use bracketed form for IPv6 hosts), and any port above the system reserved range. If you maintain a list of frequently-used servers, save them as profiles so you don't re-type host and port for every spot-check.
Choosing TCP vs UDP for client tests
For peak throughput numbers run TCP. That's what most ISPs and routers advertise, and it's the protocol Wi-Fi vendors quote against. For real-world quality of service measurements run UDP at a fixed bandwidth (`-b 100M` style) and watch jitter and packet loss; that's what tells you whether VoIP, RTP, or game traffic will actually arrive intact. UDP results above 1 % packet loss on a wired LAN almost always indicate router or NIC pressure rather than capacity. Bidirectional tests with `-d` exercise both directions concurrently, which exposes asymmetric uplinks that TCP-only tests would miss.
Reading client-side metrics on iOS
The client reports four metrics worth watching. Throughput is straightforward: bytes per second over the test interval. Retransmits count TCP segments the server failed to acknowledge in time; non-zero values on a wired LAN suggest cable or duplex issues, while elevated retransmits on Wi-Fi point to interference or weak signal. The congestion window (cwnd) reflects how aggressively TCP is allowed to push data; a small cwnd means latency or loss is throttling the connection. Round-trip time tracks per-packet latency. For Wi-Fi 5 expect 100 to 500 Mbit/s, Wi-Fi 6/6E pushes that to 800 to 1500 Mbit/s on a clean band, LTE typically delivers 30 to 150 Mbit/s, and 5G can hit 200 to 1000 Mbit/s under good conditions.
