Llm-Assisted Swiftui Prototyping Without Xcode

Issue 86 Edition 2026-03-27 7 min read

General

Sources: 1 • Confidence: Medium • Updated: 2026-04-13 03:55

Key takeaways

The author reports Claude Opus 4.6 and GPT-5.4 are competent at SwiftUI.
The author built two SwiftUI apps, Bandwidther (network bandwidth by app) and Gpuer (GPU activity), and converted both into menu bar apps that open an information panel.
The author reports that having Claude suggest features helped by proposing network usage reporting capabilities the author did not know were possible.
The author observed Gpuer produced an available-memory reading that differed from Activity Monitor and then had Claude adjust the calculations based on a screenshot, while confidence in correctness remained low.
The author obtained a 128GB M5 MacBook Pro and reports it appears capable of running good local LLMs.

The author reports Claude Opus 4.6 and GPT-5.4 are competent at SwiftUI.
The author reports a complete SwiftUI app can fit in a single text file, enabling rapid iteration without opening Xcode.
The author used a prompt-driven workflow to generate a native SwiftUI app in a temporary directory and then iteratively extended it with additional prompts while committing changes.
The author concludes that single-file SwiftUI apps can accomplish substantial functionality.
The author states Xcode is not required to build these SwiftUI 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 built two SwiftUI apps, Bandwidther (network bandwidth by app) and Gpuer (GPU activity), and converted both into menu bar apps that open an information panel.
Bandwidther was initially built to determine whether Dropbox network transfers were occurring over the LAN or via the internet.
Bandwidther gained per-process bandwidth reporting, reverse DNS while still showing IP addresses, a two-column layout, and a redesigned minimal menu bar icon.
Gpuer monitored RAM and GPU usage using system_profiler and memory_pressure, and later adopted the same menu bar pattern as Bandwidther by copying recent design changes.
The author concludes that terminal commands can be wrapped into a UI easily using SwiftUI.
The author concludes that converting a SwiftUI app into a menu bar app takes only a few lines of code.

The author reports that having Claude suggest features helped by proposing network usage reporting capabilities the author did not know were possible.
Gpuer monitored RAM and GPU usage using system_profiler and memory_pressure, and later adopted the same menu bar pattern as Bandwidther by copying recent design changes.
The author states a useful technique with coding agents is to point them at an existing codebase and ask them to imitate it to recombine elements across projects.

The author observed Gpuer produced an available-memory reading that differed from Activity Monitor and then had Claude adjust the calculations based on a screenshot, while confidence in correctness remained low.
The apps were shared 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.

Do Bandwidther and Gpuer produce accurate, stable measurements across different workloads and macOS versions when validated against known-good tools and ground-truth methods?
What specific local LLM(s) were run on the 128GB M5 MacBook Pro, and what were the latency/quality tradeoffs versus cloud models for this SwiftUI workflow?
How reproducible is this "single-file SwiftUI app" workflow for developers without Swift expertise, particularly when moving from prototype to a maintainable app (testing, packaging, signing, updates)?
What security and privacy risks arise from running agent-generated macOS monitoring utilities (e.g., network/process inspection) with the required permissions, given limited human review?
Does the reported "feature discovery" effect persist beyond this case study, or was it primarily driven by this specific author’s unfamiliarity with macOS networking metrics and SwiftUI?

Lower friction macOS SwiftUI prototyping via strong code models could expand demand for developer tooling that supports rapid iterate and commit loops without full IDE workflows.
Menu bar observability utilities can be produced quickly by wrapping system tools, suggesting an increase in lightweight monitoring apps and related distribution or packaging workflows.
As agent use shifts bottlenecks from implementation to verification, there may be increased emphasis on testing, validation, and trustworthiness tooling for metric and observability code.

More examples of single file SwiftUI apps built and shipped without opening Xcode, including reproducible workflows for non Swift experts moving from prototype to maintainable apps.
Independent validation that LLM generated macOS monitoring utilities match known good tools across macOS versions and workloads, reducing discrepancies like the available memory mismatch.
Reported successful local LLM use on high memory Macs with acceptable latency and quality for SwiftUI iteration, reducing reliance on cloud models for this workflow.

Persistent measurement inaccuracies or instability in LLM generated observability tools versus authoritative references, making rapid generation unsuitable for reliable monitoring use cases.
The workflow fails when moving beyond demos due to signing, packaging, updates, testing, or maintenance challenges, limiting it to one off prototypes.
Security or privacy issues from required permissions for monitoring utilities, combined with limited human review, lead developers or platforms to restrict or avoid agent generated system tools.