Rapid Creation Of Menu Bar Observability Utilities

Issue 86 Edition 2026-03-27 7 min read

General

Sources: 1 • Confidence: High • Updated: 2026-04-12 10:21

Key takeaways

The author built two SwiftUI apps named Bandwidther (network bandwidth by app) and Gpuer (GPU activity), and converted both into menu bar icons that open an information panel.
Gpuer produced an available-memory reading that appeared incorrect versus Activity Monitor, and the author had Claude adjust calculations based on a screenshot but still lacked confidence in correctness.
The author reports that Claude Opus 4.6 and GPT-5.4 are competent at SwiftUI for building a complete app that can fit in a single text file.
The author used a prompt-driven workflow to generate a native SwiftUI app in a temporary directory, then iteratively extended it with additional prompts while committing changes.
The author obtained a 128GB M5 MacBook Pro and reports it appears capable of running good local LLMs.

The author built two SwiftUI apps named Bandwidther (network bandwidth by app) and Gpuer (GPU activity), and converted both into menu bar icons that open an information panel.
Bandwidther was initially built to determine whether Dropbox transfers were happening over LAN or over the internet.
Bandwidther added per-process bandwidth reporting, reverse DNS while still showing IP addresses, a two-column layout, and a redesigned minimal menu bar icon experience.
Gpuer was created to monitor RAM and GPU usage using system_profiler and memory_pressure, and later matched Bandwidther’s menu bar design by copying recent design changes.

Gpuer produced an available-memory reading that appeared incorrect versus Activity Monitor, and the author had Claude adjust calculations based on a screenshot but still lacked confidence in correctness.
The author reports that having Claude suggest features surfaced capabilities the author did not know were possible for detailed network usage reporting.
The author shared the apps on GitHub primarily as examples of what Claude can do with SwiftUI rather than as trusted monitoring tools.
The author warns the apps should not be trusted because the author does not know Swift, barely reviewed the generated code, and lacks expertise in macOS internal metrics.

The author reports that Claude Opus 4.6 and GPT-5.4 are competent at SwiftUI for building a complete app that can fit in a single text file.
The author concludes that single-file SwiftUI apps can accomplish a lot, terminal commands can be wrapped into a UI easily, converting to a menu bar app takes only a few lines, and Xcode is not required to build such apps.
Based on the speed of building these utilities, the author expects SwiftUI macOS app development to be a capability to consider for future projects.

The author used a prompt-driven workflow to generate a native SwiftUI app in a temporary directory, then iteratively extended it with additional prompts while committing changes.
The author states a useful coding-agent technique is to point the agent at an existing codebase and ask it to imitate/recombine elements for a new project.

The author obtained a 128GB M5 MacBook Pro and reports it appears capable of running good local LLMs.

How accurate and stable are Bandwidther and Gpuer metrics across macOS versions, workloads, and against authoritative references (e.g., Activity Monitor)?
What was the actual time-to-build for each app and feature milestone, and what fraction of work was prompting vs. manual edits/debugging?
To what extent did the author run models locally versus using cloud inference during development, and what were latency/cost tradeoffs?
Under what exact conditions is Xcode not required in this workflow (build, sign, sandbox, distribution), and what are the limitations?
How well does the “imitate an existing codebase” technique work when the target codebase is larger, more idiomatic, or has stricter quality/security requirements?

Growing appetite for LLM accelerated native macOS utility prototyping may lift demand for coding agents tuned to SwiftUI and for workflows that generate, iterate, and reuse patterns quickly.
Correctness risk in agent built observability tools suggests a market need for validation, testing, and reference alignment layers that make AI generated system metrics trustworthy across macOS versions.
High memory Mac laptops enabling local LLM use could shift some developer inference from cloud to device, affecting demand for local model tooling and for hardware configurations optimized for on device AI.

More independent examples of SwiftUI menu bar utilities shipped via prompt driven iteration, with reported time to build and limited manual debugging, showing repeatability beyond one author.
Benchmarks showing Bandwidther and Gpuer style metrics match Activity Monitor and other references across macOS versions and workloads, plus documented test suites or calibration methods.
Evidence developers run useful local models on high memory Macs for coding tasks, with measured latency and cost advantages versus cloud, and workflows that do not require Xcode for common steps.

Repeated findings that agent generated observability metrics are unstable or incorrect across macOS versions, and fixing requires deep manual work that removes most speed gains.
Prompt driven single file SwiftUI prototypes fail to scale, with pattern imitation breaking under larger codebases or stricter security and quality needs, leading teams back to conventional development.
Local LLM development on laptops proves impractical due to performance, setup complexity, or limited model quality, keeping cloud inference dominant for this workflow.