I Switched My iOS API Debugging to Rockxy. Here Is What Changed
Browser DevTools stop at the browser tab. Charles and Proxyman work, but I wanted something I could read, build, and trust on my own Mac…
I Switched My iOS API Debugging to Rockxy. Here Is What Changed
Browser DevTools stop at the browser tab. Charles and Proxyman work, but I wanted something I could read, build, and trust on my own Mac. That is how I ended up on Rockxy, an open source native macOS HTTP debugging proxy (AGPL 3.0, Swift 99.7%, v0.30.0 as of July 2026).
This article is my hands on take after using it for real iOS and backend work: what it captures, what surprised me, and where I still keep a second tool around.
The problem I kept hitting
Every iOS bug that touches the network turns into the same ritual. Reproduce on device. Stare at Xcode console logs. Paste curl commands into Slack. Hope someone remembered which staging host the build was pointing at.
Proxyman and Charles solve a lot of this. I used both. They are polished. But when I wanted to inspect how HTTPS interception actually works, or wire captured traffic into Cursor without copy pasting headers, closed source tools hit a wall.
Rockxy pitches itself as a local first, auditable alternative. That hooked me.
What Rockxy actually is
Rockxy is a native macOS app built with SwiftUI, AppKit, and SwiftNIO. No Electron. No embedded web view pretending to be a desktop app.
At a high level it sits between your apps and the internet:
- You install a root CA (P-256 ECDSA, sealed in Keychain on first launch).
- A helper tool starts the local proxy.
- Your Mac apps, CLI tools, simulators, or a nearby iPhone route traffic through Rockxy.
- You inspect, filter, rewrite, mock, or replay requests in one window.
It handles HTTP, HTTPS, WebSocket, and GraphQL. Recent releases add AI traffic labels, JSON RPC hints for Web3 style calls, and encrypted session transfer from a nearby iPhone into a dedicated iOS workspace.
The first thing that surprised me: setup that does not fight you
Most proxy tools assume you already know where to paste HTTP_PROXY. Rockxy ships a Developer Setup Hub with copy paste snippets for Python, Node.js, Go, Rust, cURL, Docker, and browsers, plus a one click verify step.
For iOS work the flow I use is:
- Build and run Rockxy from the repo (macOS 14+, Xcode 16+, Swift 5.9).
- Walk through the Welcome window for CA trust and helper install.
- Point the simulator or a physical device at the Mac proxy.
- Hit Run Test in the setup hub to confirm traffic shows up before I debug the real bug.
That sounds small. It saved me twenty minutes on every new machine.
Where Rockxy shines for iOS engineers
Traffic capture beyond the simulator
Rockxy can filter by process ID, show a timing waterfall, and keep Mac traffic separate from an iPhone session. v0.30.0 added a Focus Navigator with Browse, Focus, and Library modes so I can isolate slow requests, WebSocket frames, or GraphQL operations without deleting the rest of the capture.
HTTPS without breaking pinned apps
Per host TLS decryption rules with wildcard patterns are table stakes. What I liked more is pinned host passthrough and a bypass list so cert pinned apps and noisy telemetry stay out of the log. My actual API calls stay readable.
Mocking without redeploys
Two features I reach for weekly:
- Map Local serves a saved JSON file instead of a live response.
- Map Remote rewrites production URLs to staging without touching app code or
/etc/hosts.
Breakpoints let me pause a request mid flight, change status or body, and continue. That is the fastest way to answer “what if the backend returns 401?” without asking anyone to deploy a fake error.
MCP: ask your editor about live traffic
This is the feature that felt ahead of the closed source tools I used before. Rockxy exposes a local MCP server so Claude Desktop or Cursor can read captured traffic through stdio, with redaction on by default.
Instead of pasting Authorization headers into chat, I can ask why a 500 happened and keep secrets local. For AI era debugging (LLM endpoints, streaming responses, tool call summaries) the inspector now adds protocol labels and dedicated tabs when it recognizes model traffic.
A quick look under the hood
Rockxy is not a thin UI on top of someone else’s engine. The proxy core uses SwiftNIO. Security sensitive work goes through an XPC helper that validates callers by certificate chain comparison, not just bundle ID.
Scripting hooks run in sandboxed JavaScriptCore with a five second timeout and no filesystem or network access. Credentials get redacted in logs. Sensitive files use 0o600 permissions.
If you clone the repo, the structure tells the story:
Rockxy/ Main SwiftUI + AppKit app
RockxyHelperTool/ Privileged proxy helper
RockxyMCP/ Local MCP bridge for AI clients
Shared/ Models and capture pipeline
That layout matters if you want to audit interception behavior before trusting it on client apps.
Rockxy vs Proxyman vs Charles
Rockxy Proxyman Charles Source Open, AGPL 3.0 Closed Closed Native macOS Swift + SwiftNIO Native commercial Cross platform MCP bridge Built in, local Not in public docs Not in public docs Build from source Free with Xcode No No Maturity Young, fast moving Very mature Very mature
Rockxy wins on transparency and automation. Proxyman and Charles still win on years of edge case polish and team workflows.
Where it still breaks (for me)
Rockxy is honest about what is future work. Deeper protocol aware rules for AI models, JSON RPC methods, or chain specific filters are on the roadmap. Team sharing and redacted evidence bundles are marked coming soon.
I also notice the project moving fast. v0.30.0 redesigned workspace navigation and added Focus Sets in the same release that shipped nearby iPhone transfers. Great for power users. Expect to relearn a panel layout every few months until things settle.
If you need gRPC or HTTP/3 today, verify the current branch before you bet a production incident on it. The README calls those directions out explicitly.
What I would do differently next time
- Start with bypass rules for analytics and crash SDKs so the session stays small.
- Save Focus Sets for recurring investigations (auth failures, GraphQL errors, slow endpoints).
- Turn on redaction before exporting HAR or sharing a
.rockxysessionwith a teammate. - Wire MCP early if you live in Cursor. It changes how you debug regressions.
Takeaways for iOS engineers
Rockxy is worth a look if you debug mobile APIs on macOS and you care about open source, local first capture, and editor integration. It is especially strong when you split time between simulator traffic, physical devices, and CLI scripts hitting the same backend.
It is not a full replacement for every Charles power user yet. It is the first proxy in years that made me want to read the source before I routed production credentials through it.
Clone it, build it, break something on purpose with Map Local, and see if the workflow sticks:
git clone https://github.com/RockxyApp/Rockxy.git
cd Rockxy
open Rockxy.xcodeproj
If you try it, start with one real bug repro instead of a toy demo. That is where native tools either earn a dock slot or go back to the Applications folder.
메타데이터
- post_id
- d1d89bcac22d
- slug
- i-switched-my-ios-api-debugging-to-rockxy-here-is-what-changed-d1d89bcac22d
- url
- https://blog.stackademic.com/i-switched-my-ios-api-debugging-to-rockxy-here-is-what-changed-d1d89bcac22d
- canonical_url
- https://blog.stackademic.com/i-switched-my-ios-api-debugging-to-rockxy-here-is-what-changed-d1d89bcac22d
- author_url
- https://medium.com/@maatheusgois
- status
- ok
- fetched_at
- 2026-09-12 03:12:22