How to debug API calls from an iPhone (the 2026 guide)

It always happens at the worst time. Your iOS app shows the wrong number on the dashboard, a screen renders empty, or a feature flag behaves differently than it did ten minutes ago — and you have no idea whether the bug is in the network, the server, or the local cache. The simulator won’t answer the question for you. It doesn’t do cellular fallback, it doesn’t get the same push payloads, it doesn’t talk to the third-party SDKs that only initialize on a real device, and it doesn’t hit the location-based code paths that make your app interesting. To actually fix this, you need to see what the phone is sending. This is the practical guide to how to debug API calls from an iPhone in 2026 — over Wi-Fi, on HTTPS, with real decryption — without any of the tedious setup that used to come with this territory.

Two real ways to do this

There are two workflows that actually work in 2026, and they answer different questions. Workflow A uses your Mac as the proxy. The iPhone routes Wi-Fi traffic through Traceptor on your Mac, decrypts HTTPS using a trusted CA, and you inspect everything on the bigger screen — with filters, rewriting, Map Local, and the rest of the desktop tools. This is the right flow for almost all day-to-day development, and the rest of this post is about it.

Workflow Buses TraceptorIOS, the companion iOS app. It captures traffic on the device itself using a NetworkExtension PacketTunnel, with no Mac involved. Use it when you’re on a plane, when you’re handing a debug build to a remote tester, or when the phone simply can’t reach your laptop’s network. We’ll cover it briefly at the end.

Image coming soon

Workflow A: Mac as proxy with the friendly setup portal

Traceptor on macOS ships a feature called Mobile Setup. Open it and you get a single, large QR code titled “Scan to Connect” with the subtitle “Opens the setup portal on your phone.” That QR encodes an http URL to a real HTML page that the proxy itself serves, on the default port 9090: http://<mac-ip>:9090/traceptor. There’s no pairing handshake, no “waiting for phone” spinner — the QR is a static link to a web page. When the phone loads it, you get a clean two-tab portal: Manual Proxy and Auto (PAC). The PAC tab has an “EASIER” badge, and it deserves it.

Manual mode is the classic flow you’ve done a hundred times: type an IP, type a port, hope you didn’t fat-finger anything. PAC mode is the 2026 way to do it. You paste a single URL into iOS — no IP, no port, no server fields — and the operating system fetches a proxy auto-config file that decides what to route. If your Mac’s IP changes (and on Wi-Fi it will), the PAC URL stays valid as long as the hostname or IP in it resolves. It also automatically excludes localhost from proxying, which saves you the “wait, why can’t I reach my dev server?” surprise.

Step-by-step: pair an iPhone with Traceptor (PAC mode)

rulehttp://192.168.1.42:9090/traceptor.pac

Verify by opening Safari

With the proxy configured and the cert trusted, open any HTTPS site on the iPhone — your company homepage, your staging API health endpoint, anything. Within a second or two the request appears in the Traceptor list on your Mac, attributed to the phone’s host. If it doesn’t, the usual culprit is the trust step in Step 4: enable it and try again. If the entry shows up but with TLS errors, the device sees the cert but doesn’t trust the root — same fix.

Capturing your own app’s traffic

Rebuild and relaunch your app once the cert is trusted. ATS for HTTPS Just Works™ now — you don’t need any Info.plistchanges for normal TLS endpoints. The only caveats are the ones you’d expect: plain HTTP may still need an ATS exception, and any endpoint that does SSL pinningwill outright refuse the Traceptor cert because, well, that’s the entire point of pinning. Pinned requests show up as TLS handshake failures in the list, which is itself a useful signal. (A future Traceptor feature called the SSL Pinning Detector will flag those automatically; for now you’ll see them as red handshake rows.)

Surprises every iOS dev finds the first time

The first hour of inspecting a real phone is humbling. You thought you knew what your app did on the network. You did not. The things people consistently discover:

• Background analytics chatter the app never advertised in the README — Mixpanel, Adjust, Firebase, AppsFlyer, sometimes all four
• Retry storms on push-notification registration after a token rotation, hammering the same endpoint every few seconds
• Polling intervals you forgot you configured back in a hackathon two years ago, still firing every 30 seconds
• Oversized JSON payloads — a 1 MB user profile because nobody paginated favorites, or a base64 avatar baked into the login response
• Outbound calls from third-party SDKs you can’t see inside and didn’t expect to be talking to anyone

None of this is visible from the simulator with the same fidelity. Real device, real network, real story.

When you’re done — disconnect cleanly

Don’t leave a debug proxy configured on your daily-driver phone. Go back to Settings → Wi-Fi → tap your network → Configure Proxy and set it to Off. If you want to fully clean up, remove the Traceptor CA profile under VPN & Device Management. The Mac side of Traceptor keeps the proxy running for your other devices; only the phone stops routing through it.

Workflow B: TraceptorIOS — on-device capture, no Mac needed

If you can’t (or don’t want to) rely on the Mac, Traceptor ships a companion iOS app called TraceptorIOS. It has its own traffic list, its own detail view, and an in-app VPN built on NetworkExtension’s PacketTunnel — so capture happens entirely on the device. The cert install pattern is the same idea but delivered differently: start the in-app proxy, share the .mobileconfig profile from the cert setup view, install it via Settings → General → VPN & Device Management, then enable full trust at Settings → General → About → Certificate Trust Settings. Reach for it when you’re offline, when you’re traveling, or when you need to ship a debug build to a remote tester who isn’t sitting next to your laptop. For everything else — bigger screen, request rewriting, Map Local, the fuzzer — stick with Workflow A.

Simulator and Catalyst, too

Worth mentioning: the iOS Simulator inherits the Mac’s system proxy settings. Once Traceptor is running, set the Mac’s system-wide proxy to it and the simulator will route through without any QR scanning or PAC URL. Same goes for Mac Catalyst targets — they’re Mac processes, so they pick up the system proxy like any other app. The QR setup portal is purely for the real phone in your hand.