Comparison
NetPeek vs Desktop Charles Proxy: On-Device Tunnel or HTTP Proxy
This page compares NetPeek with desktop Charles Proxy’s HTTP-proxy workflow (phone pointed at a Mac)—not Charles for iOS’s on-device tunnel mode. Desktop Charles waits for apps to send traffic to a proxy; NetPeek takes over the network interface on the phone with an on-device tunnel, so it sees SDKs that ignore the system proxy. If you already debug on a Mac, Charles’s large desktop screen and mature proxy workflow remain strong.
| NetPeek | Desktop Charles Proxy (HTTP proxy) | |
|---|---|---|
| Capture layer | On-device tunnel / virtual NIC — packets are taken over on the phone | Desktop HTTP proxy — apps must opt in via system proxy settings |
| Coverage | Any app’s traffic through the tunnel, including proxy-unaware SDKs | Only clients that honour system HTTP proxy settings (desktop proxy path) |
| Setup | Install profile, trust the CA, tap record | Mac on the same network, manual proxy IP/port, CA install |
| Proxy host reachability | On-device tunnel — no separate relay host required | Desktop proxy sessions need the proxy host reachable on the network (relative to desktop HTTP proxy) |
| Where data lives | Captures stay on device; crash and analytics sharing off by default | On the Mac that relays the desktop proxy session (desktop proxy path) |
| AI analysis | Built-in MCP endpoint for an AI client you connect | No built-in MCP |
The core difference: on-device tunnel, not a desktop proxy opt-in
Desktop Charles Proxy is an HTTP proxy server running on a Mac. Your iPhone only reaches it because you point the system HTTP proxy at that machine, and only clients that respect that setting ever show up in the session. NetPeek runs a tunnel / virtual network interface on the phone itself, so traffic is taken over at the network layer before any app decides whether to use a proxy. Charles for iOS also has an on-device tunnel mode; that shape is out of scope here.
What you see beyond the system HTTP proxy path
- Apps and SDKs that ignore the system HTTP proxy — analytics, ad, crash, and payment SDKs that dial out directly.
- 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.
- No need to drag a Mac running a proxy just to debug this phone: start capture on device.
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 HTTP-proxy workflow is fine. NetPeek is for the case where the phone is the thing you’re debugging and dragging a laptop in to run a proxy is the bottleneck.
Feature parity where it matters
After you leave the desktop proxy path for an on-device tunnel, rewrite, replay, HTTPS decryption, and optional MCP analysis are still there—see the capture, HTTPS, and MCP manuals plus the FAQ.
- 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 a desktop proxy setup
- Clear the system HTTP proxy on the iPhone that pointed at your Mac—you’re leaving the desktop proxy workflow; NetPeek does not use that path.
- Install the NetPeek profile and trust its CA in Settings → General → About → Certificate Trust Settings.
- Recreate Charles breakpoints and Map Local rules as NetPeek rewrite rules.
- Start a capture on the phone and drive the app; no proxy host has to be running beside you.