Build macOS Menubar Apps with Tuist

This skill builds and maintains macOS menubar apps using a Tuist-first workflow and stable launch scripts, preserving strict architecture boundaries so networking, state, and UI stay testable and predictable. Core rules: keep the app menubar-only by default (LSUIElement = true unless told otherwise), keep transport and decoding logic out of SwiftUI view bodies, keep state transitions in an observable store layer rather than row/view presentation code, keep model decoding resilient to API drift with optional fields and safe fallbacks, treat Tuist manifests as the source of truth over hand-edited generated Xcode artifacts, and prefer script-based launch over tuist run when macOS target/device resolution is unreliable, using tuist xcodebuild build rather than raw xcodebuild in local run scripts.

Use it when working on LSUIElement menubar utilities built with Tuist and SwiftUI, or when Tuist manifests, launch scripts, or architecture guidance for a menubar app are needed.

The expected file shape places app target/settings/Info.plist keys in Project.swift, API/domain models and decoding in Sources/*Model*.swift, requests and response mapping in Sources/*Client*.swift, observable state/refresh/filtering/caching in Sources/*Store*.swift, menu composition in Sources/*Menu*View*.swift, row rendering in Sources/*Row*View*.swift, plus canonical run-menubar.sh and stop-menubar.sh scripts. The workflow goes bottom to top: confirm Tuist ownership by checking Tuist.swift/Project.swift and reading existing run scripts, probe backend behavior with curl to verify endpoint shape/auth/pagination before coding assumptions (implementing full-list handling with local trimming if an endpoint ignores limit/page), implement models then client then store before wiring views last, keep app entry focused on scene/menu wiring and dependency injection without embedded business logic, and standardize launch so the run script restarts an existing instance, never opens Xcode as a side effect, and uses tuist generate --no-open plus TUIST_SKIP_UPDATE_CHECK=1 tuist xcodebuild build when generation or building is required. The validation matrix after edits:

TUIST_SKIP_UPDATE_CHECK=1 tuist xcodebuild build -scheme <TargetName> -configuration Debug

Documented failure patterns include tuist run failing to resolve the macOS destination (use the run/stop scripts instead), laggy or inconsistent menu UI after refresh (move derived state and filtering into the store, keep views render-only), API payload changes breaking decode (relax model decoding with optional fields and defaults), and a "quick UI patch" request that actually needs root-cause tracing in model/client/store before touching row/menu presentation.

Built around the Tuist project-generation toolchain for Xcode, SwiftUI for the menubar UI layer, and shell-based run-menubar.sh/stop-menubar.sh scripts as the canonical local launch path.

macOS developers building or maintaining menubar utility apps with SwiftUI and Tuist who want enforced architecture boundaries (networking and state kept out of views) and a repeatable local build/launch/validation workflow.