u/East_Call1027

I’ve been building Hostflip, a free and open-source native macOS app for switching /etc/hosts profiles from the menu bar. I thought its SwiftUI/AppKit seams might be useful to share here.

Most of the UI is SwiftUI. MenuBarExtra, the main window, and Settings share a single workspace store built with Swift’s Observation framework. The main window combines a sidebar and editor with a drift review: if another tool edits /etc/hosts, Hostflip stops writing and shows the difference for review instead of silently overwriting it.

Two small AppKit escape hatches were needed:

• NSViewRepresentable with NSTitlebarAccessoryViewController keeps the master switch pinned to the trailing edge. Putting it inside the SwiftUI-managed toolbar made it move whenever SwiftUI rebuilt the toolbar items.

• NSApplicationDelegateAdaptor handles the window lifecycle, so a normal launch opens the main window while a login-item launch remains menu-bar-only.

The privileged boundary stays outside the UI. A minimal root helper exposes a two-method XPC interface: a handshake and a single write operation that atomically replaces the merged hosts content. The app and helper verify each other’s code-signing identity before accepting the connection.

Hostflip is MIT-licensed and notarized. It currently requires macOS 14 or later on Apple silicon.

Source: https://github.com/heronapp/hostflip

I’d especially appreciate feedback on the SwiftUI/AppKit seam and the shared state flow between MenuBarExtra and the main window.

I'm the solo developer of Heron. I built it because phone-side bugs kept splitting one investigation across two places: a network proxy on the Mac and Safari's page console on the device.

Heron now puts both timelines on the Mac and exposes them through a local MCP server. A typical session looks like this:

1. Scan Heron's profile QR, then enable the certificate trust switch that iOS requires.
2. Reproduce the bug in Safari or an inspectable WKWebView.
3. Ask your coding agent to find the failed request and read the console messages around it.

The MCP tools can query capture status and flows, list inspectable pages, and read console messages. JavaScript evaluation is available too, but it has its own permission switch.

I was careful about the boundary because captured traffic and console output can contain credentials. The MCP server is off by default. Page inspection, console reads, and JavaScript evaluation have separate controls, and credential headers and URL tokens are masked by default. Heron itself has no account or analytics SDK and does not upload your config, traffic logs, or page console. Anything an agent reads can still be sent to that agent's LLM provider, so the app says that explicitly before access is enabled.

It is a native SwiftUI app with a Rust proxy engine for Apple Silicon Macs running macOS 15 or later. The full trial lasts 14 days without an account or card, and the license is $49 once for all 1.x updates.

https://getheron.app

Heron is currently at 1.3.0. The MCP and live page-console work landed across 1.1 and 1.2; 1.3 was mostly light-mode and Settings polish. I'm sharing it now because the complete debugging loop is finally the part I want feedback on.

If you use MCP for debugging, I would especially like to know whether the read-only versus JavaScript-evaluation boundary feels right, and what real debugging question the current tool set would fail to answer.