Capture iPhone traffic to a PCAP file from a Mac

iOS does not let you record a packet trace on the phone itself, so Apple's own route runs through a Mac. To capture iPhone traffic you connect the phone by cable, create a remote virtual interface for it with rvictl, and record that interface with tcpdump like any other. The file holds the phone's whole network stack, Wi-Fi and cellular alike, and every packet keeps a note of the interface it used and, where the system knows it, the process behind it. Here is the procedure, what the resulting file contains, and how to read it.

Before you start: Xcode, a cable and trust

The tool comes with Xcode: Apple's troubleshooting notes say Xcode installs rvictl the first time it launches, which is why Terminal answers command not found on a Mac that has only the command line tools. Install Xcode from the App Store and open it once. Then connect the iPhone with a USB cable, unlock it and tap Trust when it asks about this computer. You also need the phone's identifier, its UDID: Xcode shows it under Window, Devices and Simulators. Copy it as it is; the commands below write it as DEVICE_UDID, and the angle brackets some guides put around it must not be typed, because the shell reads them as redirection.

Create the remote virtual interface

rvictl -s DEVICE_UDID
rvictl -l

The first command starts the interface and reports the device with [SUCCEEDED] with interface rvi0. The second lists the devices that have one. Each phone gets its own interface, rvi0 for the first and rvi1 for a second one, so several devices can be recorded side by side. If rvictl stops with bootstrap_look_up(): 1102, the daemon it talks to is not running; Apple's notes suggest sudo launchctl list com.apple.rpmuxd to check that it is installed and loaded. Unlike the capture in the next step, the rvictl commands run without sudo, as in Apple's own examples.

Record rvi0, then take the interface down

sudo tcpdump -i rvi0 -w iphone.pcap
rvictl -x DEVICE_UDID

tcpdump records until you press Ctrl+C, so start it first and then use the app or reproduce the problem on the phone. Keep it short: a phone with a dozen apps talks constantly, and a few minutes of background sync can push the file past the 25 MB public upload limit. Stopping tcpdump with Ctrl+C closes the file cleanly, and rvictl -x removes the interface once you are done. To check the result before an upload, capinfos iphone.pcap gives its packet count and time span, and tcpdump -k -r iphone.pcap prints each packet with its metadata.

What the file holds

Apple describes the remote virtual interface as the device's entire networking stack. One capture therefore mixes Wi-Fi and cellular traffic, and a packet's metadata says which interface carried it, so a request that left over cellular is told apart from one that used Wi-Fi. Depending on the macOS release and the options, tcpdump stores this metadata as pcapng blocks or as Apple's PKTAP header in front of every packet of a classic pcap file. A-Packets reads both and analyzes the packets under the metadata. The interface and process names stay in the file for Wireshark, as pktap.ifname and pktap.cmdname in a PKTAP file or as the Darwin process fields of a pcapng one, which is the quickest way to tie a connection to the app that opened it.

Read the capture in A-Packets

Upload the file as it is; there is nothing to convert. DNS lists the names the phone looked up, which is usually the shortest path from an app to the servers it uses. SSL/TLS shows the server name of every encrypted session, and on TLS 1.2 and older the certificate chain as well; TLS 1.3 sessions show the name but encrypt the certificates. Connections ranks the peers by bytes, so the service behind a drained data plan stands out. A phone's traffic is personal and can carry account names in URLs, push tokens and locations sent to APIs. Read how to sanitize a PCAP before a public upload, or keep it in a private report.

No Mac at hand

Without a Mac the phone can still be recorded, only not from the inside. Put it on a Wi-Fi network whose traffic you can capture: a laptop sharing its connection, a router that runs tcpdump, or a mirror port of the access point, then record there as the tcpdump to a PCAP file guide shows. That capture sees only what crosses the network you control, so switch off cellular data on the phone for the test, and it carries none of the per-packet process names that a recording through rvi0 keeps.