Developer Setup Hub

The Developer Setup Hub is a dedicated window that collects everything you need to point a specific runtime, client, device, or framework at Rockxy's local proxy. Open it from Tools → Debug My App… in the menu bar. The hub itself lives in its own window (developerSetupHub); the automatic and manual setup flows open in two separate companion windows (automaticSetup, manualSetup) so you can run setup in parallel with active debugging.

Layout:

• Source list (left): searchable, grouped by category.
• Detail tabs (center): Overview, Setup, Snippets, Validate, Troubleshooting.
• Status inspector (right): proxy, certificate, and validation state for the active target.

What manual support means

Every target in the hub has a manual path. Manual support means:

• the app surfaces Rockxy's current listen address, port, and root certificate state;
• the hub ships the concrete command, config block, or code snippet you paste into the runtime, client, container, or framework;
• Rockxy never launches a shell, configures a third-party app, modifies macOS trust, or changes a device's network settings for you.

Many targets additionally ship an in-app validation watcher. The Snippets tab keeps the general-purpose sample request, while the Validate tab swaps in a target-specific local probe URL such as GET http://127.0.0.1:<probe-port>/.well-known/rockxy/dev-setup/python/<token> before you press Run Local Probe. This is still a generic capture check, not process, device, simulator, emulator, or runtime attribution for the selected target.

Some targets are hybrid: they have generated snippets and still keep platform guide notes. Flutter is the reference example: Rockxy can generate Flutter client snippets, but the underlying iOS or Android target still owns reachability and certificate trust. Its validation probe confirms capture through Rockxy, not which device, emulator, simulator, or Dart runtime emitted the traffic. React Native follows the same model with a fetch probe, Android debug XML, and Metro troubleshooting notes.

Support matrix

Core runtimes proven end-to-end on a developer machine with local toolchains

These targets now have runtime integration tests that start a local upstream probe server, run the real language/tool through Rockxy's proxy, and confirm Rockxy captures the request:

Target	Proof lane
Python	python3 stdlib HTTP request through Rockxy
Node.js	node built-in http request through Rockxy
Ruby	ruby Net::HTTP::Proxy request through Rockxy
Golang	go run net/http request through Rockxy
Rust	rustc probe binary talking HTTP through Rockxy
cURL	curl --proxy ... through Rockxy
Java	local JDK HttpClient request through Rockxy

Additional manual-support targets proven end-to-end when the local app/tool is present

These targets still rely on manual setup inside the real third-party app, but the repo now also carries end-to-end proof lanes that drive the real local prerequisite through Rockxy:

Target	Proof lane
Firefox	headless Firefox profile with proxy prefs forcing the probe through Rockxy
Docker	Docker Desktop container using curl --proxy ... through Rockxy to a host IPv4 probe
Next.js	temporary App Router route handler under next dev with NODE_USE_ENV_PROXY=1 + proxy envs

Available now — manual snippets + local capture check

Target	Snippet variants
Python	requests, httpx, aiohttp, urllib3
Node.js	axios, Node core HTTP/HTTPS, got
Ruby	net/http, http, Faraday
Golang	net/http, Resty
Rust	reqwest
cURL	command form, environment-variable form
Java VMs	keytool import, HttpClient sample, requires a local JDK
Firefox	Network Settings + authority-store import + localhost probe fallback
Postman	Proxy settings + CA certificate + cURL preflight
Insomnia	Proxy preferences + CA certificate + cURL preflight
Paw	macOS system-proxy block + keychain trust + cURL preflight
Docker	docker run probe with host IPv4 + mounted CA
ElectronJS	--proxy-server CLI flag, session.setProxy main-process call
Next.js	App Router route handler + NODE_USE_ENV_PROXY + HTTP_PROXY / HTTPS_PROXY + NODE_EXTRA_CA_CERTS
Flutter	Dio 5, Dart HttpClient, package:http, Android debug network_security_config.xml
React Native	fetch probe, Android debug network_security_config.xml, Metro/ADB checklist

Each snippet is generated against Rockxy's active proxy port and the exported root certificate. The Validate tab rewrites the sample request to a target-specific local GET http://127.0.0.1:<probe-port>/.well-known/rockxy/dev-setup/<target>/<token> probe and then runs a short watcher for that exact request after you press Run Local Probe. That confirms Rockxy saw the probe through its proxy, but it does not prove which app, browser, process, device, simulator, emulator, or runtime emitted it. The watcher cancels automatically if the session is cleared, recording is paused, or the proxy stops.

If the preflight sees a problem (proxy stopped, recording paused, certificate not trusted, or certificate not exportable) it surfaces the first blocking issue with a direct action you can take before rerunning.

Validate does not depend on public DNS or a third-party endpoint. If local validation succeeds but your real API call fails, treat that as a separate upstream, network, or application issue after the Rockxy proxy/capture path is known-good.

Automatic vs manual setup

Each target's automation surface is driven by its SetupAutomationSupport value in the catalog:

• Automatic Setup — available for runtime/terminal targets (Python, Node.js, Ruby, Go, Rust, cURL, Java). The Automatic Setup window shows the workflow plan, lets you preview the exact commands in DeveloperSetupAutomationSheet, and runs the local probe once you apply.
• Manual Setup — used for every target where Rockxy ships snippets but does not drive the target tool itself (Firefox, Postman, Insomnia, Paw, Docker, ElectronJS, Next.js, Flutter, React Native), and for every guide-only target (devices, simulators, emulators).

The hub never silently bypasses the manual path. Even targets that expose Automatic Setup keep the Manual Setup window reachable from the same inspector.

Guide only — concrete manual steps, no in-app snippet generator

Guide-only targets are limited to targets where Rockxy cannot ship a first-party snippet, typically physical devices or simulators that expose only the underlying platform network stack.

These targets depend on behavior Rockxy does not drive from macOS (physical-device pairing, simulator automation, platform trust stores), so the hub ships honest guide copy rather than a generated snippet:

Devices

• iOS Device — manual Wi-Fi proxy + install the certificate as a profile + enable full trust under Certificate Trust Settings.
• iOS Simulator — loopback is reachable from the simulator; drag the PEM onto the simulator and enable full trust, then cold-launch the target app.
• Android Device — manual Wi-Fi proxy + install as a user CA + debug build with a network-security-config that trusts user CAs.
• Android Emulator — Mac is reachable at 10.0.2.2; set the emulator proxy to 10.0.2.2 plus Rockxy's port and install as user CA.
• tvOS / watchOS — reuse the iOS Device and iOS Simulator paths; there is no dedicated pairing workflow.
• Vision Pro — follows the iOS Device path on the device itself; there is no dedicated Vision Pro pairing workflow.

What guide-only does NOT do

• It does not pair with devices or simulators.
• It does not install, trust, or import certificates into third-party apps.
• It does not run AppleScript or launch Terminal for you.
• It does not rewrite network-security-config, simctl, browser profiles, or system proxy settings.
• It does not install an Android local VPN companion or offer no-code Flutter Android Emulator routing.

If a page ever implies an automatic flow, treat it as a bug. File an issue.

Source list and search

The filter at the top of the source list matches on target name, category name, summary text, and automation-support label. Searching for postman, emulator, vision, or browsers & clients narrows the list without losing category grouping.

Scope and honesty rules

• Rockxy ships the full manual path described here.
• Guide-only pages carry concrete prerequisites and limitations rather than "coming soon" copy.
• Every target's Overview tab states exactly what Rockxy does today for that target and what is still manual.

If you run into a target where the copy does not match reality, the catalog lives at Rockxy/Models/UI/DeveloperSetupCatalog.swift, the workflow + snippet generators at Rockxy/Models/UI/DeveloperSetupWorkflow.swift, and the remaining device/framework guide tips at Rockxy/Models/UI/DeveloperSetupGuideCatalog.swift. SetupSupportStatus (availableNow / guideOnly / notYetSupported) is the source of truth for what each target actually ships.