Comparison
NetPeek vs Charles Proxy on iOS
Charles waits for apps to send traffic to a proxy. NetPeek takes over the network interface on the phone — so it sees the requests a proxy never gets handed.
| NetPeek | Charles Proxy | |
|---|---|---|
| Capture layer | Virtual network interface — packets are taken over on device | HTTP proxy server — apps must opt in via system proxy settings |
| Coverage | Any app's traffic through the tunnel, including proxy-unaware SDKs | Only clients that honour the Wi-Fi HTTP proxy |
| Setup | Install profile, trust the CA, tap record | Mac on the same Wi-Fi, manual proxy IP/port, CA install |
| Away from Wi-Fi | Works on cellular — nothing to relay to | Needs the desktop machine reachable on the network |
| Where data lives | On the device; exported only when you export it | On the desktop that relays the session |
| AI analysis | Built-in MCP endpoint for an AI client you connect | None |
The core difference: interface takeover, not a proxy opt-in
Charles is an HTTP proxy server running on a desktop. Your iPhone only reaches it because you point the Wi-Fi HTTP proxy setting at that machine, and only clients that respect that setting ever show up in the session. NetPeek runs a virtual network interface on the phone itself, so traffic is taken over at the network layer before any app gets to decide whether it feels like using a proxy.
What that actually lets you see
- Apps and SDKs that ignore the system HTTP proxy — analytics, ad, crash and payment SDKs that dial out directly.
- Traffic while you're on cellular, on a captive network, or anywhere your Mac isn't.
- Background activity from apps you aren't actively driving, captured for the whole session.
- Connection-level detail — host, ports, TLS handshake and timings — not just the HTTP exchange a proxy was handed.
What Charles still does well
Charles is mature, has a big desktop screen behind it, and is a reasonable choice when you're already debugging a web app on that machine. If your work is desktop-first and the target app honours the system proxy, the workflow is fine. NetPeek is for the case where the phone is the thing you're debugging and dragging a laptop into it is the bottleneck.
Feature parity where it matters
- Rewrite headers and bodies, Map Local from files on the device, and return mocked responses.
- Edit and replay any captured request to reproduce a failure.
- JavaScript scripting for conditional debugging logic.
- HTTPS plaintext after you explicitly install and trust the NetPeek CA, per host you allow.
Moving over from Charles
- Remove the manual Wi-Fi HTTP proxy on the device — NetPeek doesn't need it.
- Install the NetPeek profile and trust its CA in Settings → General → About → Certificate Trust Settings.
- Recreate breakpoints and Map Local rules as NetPeek rewrite rules.
- Start a capture and drive the app; nothing else has to be running.