macos-menubar-tuist-app
Build and maintain macOS menubar apps with a Tuist-first workflow and stable launch scripts. Preserve strict architecture boundaries so networking, state, and UI remain testable and predictable.
Core Rules
- Keep the app menubar-only unless explicitly told otherwise. Use
LSUIElement = true by default.
- Keep transport and decoding logic outside views. Do not call networking from SwiftUI view bodies.
- Keep state transitions in a store layer (
@Observable or equivalent), not in row/view presentation code.
- Keep model decoding resilient to API drift: optional fields, safe fallbacks, and defensive parsing.
- Treat Tuist manifests as the source of truth. Do not rely on hand-edited generated Xcode artifacts.
- Prefer script-based launch for local iteration when
tuist run is unreliable for macOS target/device resolution.
- Prefer
tuist xcodebuild build over raw xcodebuild in local run scripts when building generated projects.
Expected File Shape
Use this placement by default:
Project.swift: app target, settings, resources, Info.plist keys
Sources/*Model*.swift: API/domain models and decoding
Sources/*Client*.swift: requests, response mapping, transport concerns
Sources/*Store*.swift: observable state, refresh policy, filtering, caching
Sources/*Menu*View*.swift: menu composition and top-level UI state
Sources/*Row*View*.swift: row rendering and lightweight interactions
run-menubar.sh: canonical local restart/build/launch path
stop-menubar.sh: explicit stop helper when needed
Workflow
- Confirm Tuist ownership
- Verify
Tuist.swift and Project.swift (or workspace manifests) exist.
- Read existing run scripts before changing launch behavior.
- Probe backend behavior before coding assumptions
- Use
curl to verify endpoint shape, auth requirements, and pagination behavior.
- If endpoint ignores
limit/page, implement full-list handling with local trimming in the store.
- Implement layers from bottom to top
- Define/adjust models first.
- Add or update client request/decoding logic.
- Update store refresh, filtering, and cache policy.
- Wire views last.
- Keep app wiring minimal
- Keep app entry focused on scene/menu wiring and dependency injection.
- Avoid embedding business logic in
App or menu scene declarations.
- Standardize launch ergonomics
- Ensure run script restarts an existing instance before relaunching.
- Ensure run script does not open Xcode as a side effect.
- Use
tuist generate --no-open when generation is required.
- When the run script builds the generated project, prefer
TUIST_SKIP_UPDATE_CHECK=1 tuist xcodebuild build ... instead of invoking raw xcodebuild directly.
Validation Matrix
Run validations after edits:
TUIST_SKIP_UPDATE_CHECK=1 tuist xcodebuild build -scheme <TargetName> -configuration Debug
If launch workflow changed:
./run-menubar.sh
If shell scripts changed:
bash -n run-menubar.sh
bash -n stop-menubar.sh
./run-menubar.sh
Failure Patterns and Fix Direction
tuist run cannot resolve the macOS destination:
Use run/stop scripts as canonical local run path.
Menu UI is laggy or inconsistent after refresh:
Move derived state and filtering into the store; keep views render-only.
API payload changes break decode:
Relax model decoding with optional fields and defaults, then surface missing data safely in UI.
Feature asks for quick UI patch:
Trace root cause in model/client/store before changing row/menu presentation.
Completion Checklist
- Preserve menubar-only behavior unless explicitly changed.
- Keep network and state logic out of SwiftUI view bodies.
- Keep Tuist manifests and run scripts aligned with actual build/run flow.
- Run the validation matrix for touched areas.
- Report concrete commands run and outcomes.
1---
2name: macos-menubar-tuist-app
3description: >-
4 Build macOS menubar apps with Tuist and SwiftUI. Use when: creating LSUIElement menubar utilities, defining Tuist manifests, or building menubar apps without Xcode-first workflows.
5license: MIT
6compatibility: "macOS with Tuist and SwiftUI"
7metadata:
8 author: terminal-skills
9 version: "1.0.0"
10 category: development
11 tags: [macos, menubar, tuist, swift, desktop-app]
12 use-cases:
13 - "Create a macOS menubar utility with Tuist"
14 - "Build and run menubar apps with script-based launch flows"
15 agents: [claude-code, openai-codex, gemini-cli, cursor]
16---
17
18# macos-menubar-tuist-app
19
20Build and maintain macOS menubar apps with a Tuist-first workflow and stable launch scripts. Preserve strict architecture boundaries so networking, state, and UI remain testable and predictable.
21
22## Core Rules
23
24- Keep the app menubar-only unless explicitly told otherwise. Use `LSUIElement = true` by default.
25- Keep transport and decoding logic outside views. Do not call networking from SwiftUI view bodies.
26- Keep state transitions in a store layer (`@Observable` or equivalent), not in row/view presentation code.
27- Keep model decoding resilient to API drift: optional fields, safe fallbacks, and defensive parsing.
28- Treat Tuist manifests as the source of truth. Do not rely on hand-edited generated Xcode artifacts.
29- Prefer script-based launch for local iteration when `tuist run` is unreliable for macOS target/device resolution.
30- Prefer `tuist xcodebuild build` over raw `xcodebuild` in local run scripts when building generated projects.
31
32## Expected File Shape
33
34Use this placement by default:
35
36- `Project.swift`: app target, settings, resources, `Info.plist` keys
37- `Sources/*Model*.swift`: API/domain models and decoding
38- `Sources/*Client*.swift`: requests, response mapping, transport concerns
39- `Sources/*Store*.swift`: observable state, refresh policy, filtering, caching
40- `Sources/*Menu*View*.swift`: menu composition and top-level UI state
41- `Sources/*Row*View*.swift`: row rendering and lightweight interactions
42- `run-menubar.sh`: canonical local restart/build/launch path
43- `stop-menubar.sh`: explicit stop helper when needed
44
45## Workflow
46
471. Confirm Tuist ownership
48- Verify `Tuist.swift` and `Project.swift` (or workspace manifests) exist.
49- Read existing run scripts before changing launch behavior.
50
512. Probe backend behavior before coding assumptions
52- Use `curl` to verify endpoint shape, auth requirements, and pagination behavior.
53- If endpoint ignores `limit/page`, implement full-list handling with local trimming in the store.
54
553. Implement layers from bottom to top
56- Define/adjust models first.
57- Add or update client request/decoding logic.
58- Update store refresh, filtering, and cache policy.
59- Wire views last.
60
614. Keep app wiring minimal
62- Keep app entry focused on scene/menu wiring and dependency injection.
63- Avoid embedding business logic in `App` or menu scene declarations.
64
655. Standardize launch ergonomics
66- Ensure run script restarts an existing instance before relaunching.
67- Ensure run script does not open Xcode as a side effect.
68- Use `tuist generate --no-open` when generation is required.
69- When the run script builds the generated project, prefer `TUIST_SKIP_UPDATE_CHECK=1 tuist xcodebuild build ...` instead of invoking raw `xcodebuild` directly.
70
71## Validation Matrix
72
73Run validations after edits:
74
75```bash
76TUIST_SKIP_UPDATE_CHECK=1 tuist xcodebuild build -scheme <TargetName> -configuration Debug
77```
78
79If launch workflow changed:
80
81```bash
82./run-menubar.sh
83```
84
85If shell scripts changed:
86
87```bash
88bash -n run-menubar.sh
89bash -n stop-menubar.sh
90./run-menubar.sh
91```
92
93## Failure Patterns and Fix Direction
94
95- `tuist run` cannot resolve the macOS destination:
96Use run/stop scripts as canonical local run path.
97
98- Menu UI is laggy or inconsistent after refresh:
99Move derived state and filtering into the store; keep views render-only.
100
101- API payload changes break decode:
102Relax model decoding with optional fields and defaults, then surface missing data safely in UI.
103
104- Feature asks for quick UI patch:
105Trace root cause in model/client/store before changing row/menu presentation.
106
107## Completion Checklist
108
109- Preserve menubar-only behavior unless explicitly changed.
110- Keep network and state logic out of SwiftUI view bodies.
111- Keep Tuist manifests and run scripts aligned with actual build/run flow.
112- Run the validation matrix for touched areas.
113- Report concrete commands run and outcomes.