Llm Assisted Swiftui Prototyping Without Xcode

Issue 86 Edition 2026-03-27 6 min read

General

Sources: 1 • Confidence: Medium • Updated: 2026-03-28 03:34

Key takeaways

The author describes Claude Opus 4.6 and GPT-5.4 as competent at SwiftUI.
The author built two SwiftUI apps (Bandwidther and Gpuer) 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.
The author observed a discrepancy between Gpuer’s available-memory reading and Activity Monitor and had Claude adjust calculations based on a screenshot, while remaining uncertain about correctness.
The author obtained a 128GB M5 MacBook Pro and reports it appears capable of running good local LLMs.

The author describes Claude Opus 4.6 and GPT-5.4 as competent at SwiftUI.
The author claims 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 via additional prompts and commits.
The author concludes that single-file SwiftUI apps can accomplish a lot and that terminal commands can be wrapped into a UI easily.
The author claims Xcode is not required to build the kind of SwiftUI apps described.

The author built two SwiftUI apps (Bandwidther and Gpuer) and converted both into menu bar apps that open an information panel.
Gpuer was later aligned with Bandwidther’s menu bar pattern by copying recent design changes from Bandwidther.
The author states a useful technique with coding agents is to point them at an existing codebase and ask them to imitate/recombine elements from it.
The author claims converting a SwiftUI app into a menu bar app takes only a few lines.

The author built two SwiftUI apps (Bandwidther and Gpuer) 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, and a two-column layout, and was redesigned into a menu bar app with a minimal icon.
Gpuer monitors RAM and GPU usage using system_profiler and memory_pressure.

The author observed a discrepancy between Gpuer’s available-memory reading and Activity Monitor and had Claude adjust calculations based on a screenshot, while remaining uncertain about correctness.
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 obtained a 128GB M5 MacBook Pro and reports it appears capable of running good local LLMs.

Which specific local LLMs (model names, quantization, context length) were run on the 128GB M5 MacBook Pro, and what were the measured latency/throughput characteristics for coding tasks?
What build/run toolchain was used to avoid Xcode, and what limitations (debugging, signing, distribution, entitlements, permissions) were encountered or would appear for broader deployment?
How accurate are Bandwidther’s per-process bandwidth metrics and reverse DNS results when compared against known-good tools across multiple networks and macOS versions?
What is the ground-truth method to validate Gpuer’s memory and GPU readings, and what test cases would detect parsing/conversion regressions?
How reproducible is the prompt-driven workflow (including the “imitation” technique) across different codebases, and what failure modes appear (hallucinated APIs, incorrect entitlements, performance regressions, security issues)?

Rising usefulness of LLMs for SwiftUI could increase demand for macOS focused developer tooling that supports prompt driven prototyping, rapid iteration, and one file apps without heavy IDE workflows.
Pattern reuse across small internal utilities suggests enterprises may expand budgets for lightweight observability and internal app frameworks if LLMs reduce development time, increasing spend on monitoring data sources and distribution workflows.
Anecdotal ability of a high memory MacBook Pro to run good local LLMs could be an early signal for greater on device AI coding workflows, supporting demand for high memory developer machines and local inference software stacks.

Reproducible benchmarks showing specific local LLMs running on a 128GB M5 MacBook Pro with measured latency and throughput for coding tasks, and evidence the workflow reduces reliance on cloud models.
Clear description of a non Xcode build and run toolchain that reliably supports signing, entitlements, debugging, and distribution for menu bar SwiftUI apps at scale.
Validation studies showing Bandwidther and Gpuer metrics match ground truth tools across macOS versions and networks, with regression tests that catch parsing and unit conversion errors.

Persistent correctness gaps where LLM generated monitoring outputs diverge from Activity Monitor or known good tools and cannot be reliably validated, limiting prototypes to demos.
Non Xcode workflows fail on key macOS requirements such as signing, entitlements, permissions, or distribution, forcing a return to conventional Xcode centric development and slowing iteration.
Local LLM claims do not reproduce on the cited hardware, or measured performance is insufficient for interactive coding, keeping workflows dependent on cloud inference.