macos-menubar-tuist-app
A toolkit for maintaining Tuist-based macOS menubar utilities.
Install
mkdir -p .claude/skills/macos-menubar-tuist-app && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/13111" && unzip -o skill.zip -d .claude/skills/macos-menubar-tuist-app && rm skill.zipInstalls to .claude/skills/macos-menubar-tuist-app
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Build, refactor, or review macOS menubar apps that use Tuist and SwiftUI. Use when creating or maintaining LSUIElement menubar utilities, defining Tuist targets/manifests, implementing model-client-store-view architecture, adding script-based launch flows, or validating reliable local build/run behavior without Xcode-first workflows.Key capabilities
- →Keep the app menubar-only using `LSUIElement = true`
- →Keep transport and decoding logic outside views
- →Keep state transitions in a store layer
- →Treat Tuist manifests as the source of truth
- →Prefer script-based launch for local iteration
- →Ensure run script restarts an existing instance before relaunching
How it works
The skill enforces architectural boundaries and uses Tuist manifests as the source of truth, guiding the implementation of models, clients, stores, and views, and standardizing launch scripts.
Inputs & outputs
When to use macos-menubar-tuist-app
- →Creating a new Tuist project
- →Refactoring menubar app architecture
- →Validating local build behaviors
About this skill
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 = trueby default. - Keep transport and decoding logic outside views. Do not call networking from SwiftUI view bodies.
- Keep state transitions in a store layer (
@Observableor 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 runis unreliable for macOS target/device resolution. - Prefer
tuist xcodebuild buildover rawxcodebuildin local run scripts when building generated projects.
Expected File Shape
Use this placement by default:
Project.swift: app target, settings, resources,Info.plistkeysSources/*Model*.swift: API/domain models and decodingSources/*Client*.swift: requests, response mapping, transport concernsSources/*Store*.swift: observable state, refresh policy, filtering, cachingSources/*Menu*View*.swift: menu composition and top-level UI stateSources/*Row*View*.swift: row rendering and lightweight interactionsrun-menubar.sh: canonical local restart/build/launch pathstop-menubar.sh: explicit stop helper when needed
Workflow
- Confirm Tuist ownership
- Verify
Tuist.swiftandProject.swift(or workspace manifests) exist. - Read existing run scripts before changing launch behavior.
- Probe backend behavior before coding assumptions
- Use
curlto 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
Appor 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-openwhen generation is required. - When the run script builds the generated project, prefer
TUIST_SKIP_UPDATE_CHECK=1 tuist xcodebuild build ...instead of invoking rawxcodebuilddirectly.
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 runcannot 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.
When not to use it
- →When building an Xcode-first workflow
- →When the app is not a macOS menubar utility
- →When the project does not use Tuist
Limitations
- →Keep the app menubar-only unless explicitly told otherwise
- →Do not rely on hand-edited generated Xcode artifacts
How it compares
This skill provides a Tuist-first, script-driven workflow for macOS menubar apps, ensuring a structured and testable architecture, unlike a typical Xcode-centric development approach.
Compared to similar skills
macos-menubar-tuist-app side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| macos-menubar-tuist-app (this skill) | 0 | 4mo | Review | Advanced |
| swiftui-expert-skill | 13 | 4mo | No flags | Intermediate |
| swiftui-ui-patterns | 1 | 4mo | No flags | Intermediate |
| ios-navigation | 2 | 3mo | No flags | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
You might also like
swiftui-expert-skill
sickn33
Write, review, or improve SwiftUI code following best practices for state management, view composition, performance, modern APIs, Swift concurrency, and iOS 26+ Liquid Glass adoption. Use when building new SwiftUI features, refactoring existing views, reviewing code quality, or adopting modern SwiftUI patterns.
swiftui-ui-patterns
Dimillian
Best practices and example-driven guidance for building SwiftUI views and components. Use when creating or refactoring SwiftUI UI, designing tab architecture with TabView, composing screens, or needing component-specific patterns and examples.
ios-navigation
HoangNguyen0403
SwiftUI navigation and deep linking using NavigationStack and Universal Links.
view
andrelucassvt
Cria uma nova View SwiftUI seguindo o padrao MVVM do projeto (iOS 15+). Use quando o usuario pedir para criar uma nova tela, view ou screen.
swiftui-whats-new-27
CamilleScholtz
New SwiftUI APIs, behaviors, and deprecations introduced in the 2027 OS releases (iOS 27, macOS 27, watchOS 27, tvOS 27, visionOS 27). Use when a SwiftUI view using @State fails to compile with \"used before being initialized\", \"invalid redeclaration of synthesized property\", or \"extraneous argu
swift
bouclem
Expert in Swift and SwiftUI development for iOS, macOS, and Apple platforms