Macos Menubar Tuist App

---
name: macos-menubar-tuist-app
description: >-
  Creates and maintains a macOS menu bar app whose Xcode project is generated by Tuist: a SwiftUI MenuBarExtra scene, no Dock icon, manifests in Swift, and a terminal loop that rebuilds and relaunches the app. Covers choosing between a menu and a panel, where fetching and state belong, Quit and Settings items, launch at login, dependencies and tests. Use when the user says "make a menu bar app", "status bar utility for macOS", "set this up with Tuist", "hide the Dock icon", "LSUIElement", "MenuBarExtra", "rebuild and relaunch from the terminal" or "add launch at login".
license: Apache-2.0
compatibility: "macOS with Xcode 16 or later and Tuist 4.62 or later (checked against 4.210). MenuBarExtra needs macOS 13; @Observable and SettingsLink need macOS 14."
metadata:
  author: terminal-skills
  version: "2.0.0"
  category: development
  repository: https://github.com/tuist/tuist
  tags: ["macos", "menubar", "tuist", "swiftui", "menubarextra"]
---

# macOS Menu Bar App with Tuist

## Overview

A menu bar app lives as an icon next to the clock and has no Dock icon and no main window. On macOS 13 and later it takes two ingredients: a SwiftUI `MenuBarExtra` scene, and the Info.plist key `LSUIElement` set to true, which marks the bundle as an agent app. Tuist supplies the project: the targets are declared in `Project.swift`, `tuist generate` writes the `.xcodeproj` and `.xcworkspace`, and the generated files are never edited or committed. This skill covers the decisions, the manifest, the app skeleton, and a build-and-relaunch loop an agent can run without opening Xcode.

## Instructions

### 1. Gather what you need

Ask the user:

- The app name and the bundle identifier prefix (for example `io.harborlane`).
- What the icon and its contents show, and where the data comes from (a local command, a file, an HTTP API).
- The oldest macOS version to support.
- Whether it should start at login, and whether it will be distributed outside the developer's own Mac.

Look up in the folder: an existing `Tuist.swift`, `Project.swift` or `Workspace.swift`; a pinned version in `mise.toml`; `tuist version`; `xcodebuild -version`; any scripts that already build or launch the app. If manifests exist, extend them; do not scaffold a second project beside them.

### 2. Install and pin Tuist

```bash
mise use tuist@4.210.0        # writes the version to mise.toml for everyone on the project
# or, on a single Mac:
brew tap tuist/tuist
brew install --formula tuist

tuist version
```

Producing a project requires a Mac that has Xcode. On Linux the only installer is mise, and anything that calls Xcode (`tuist generate` included) will not run.

### 3. Make the design decisions

| Decision | Options | How to choose |
|----------|---------|---------------|
| Presentation | `.menuBarExtraStyle(.menu)` (the default pull-down menu) or `.window` (a popover-like panel) | A menu when the content is a short list of commands and toggles. A panel when it needs custom layout, scrolling lists, text fields or charts |
| State model | `@Observable` class (macOS 14) or `ObservableObject` (macOS 13) | Follow the deployment target |
| Sources in the manifest | `buildableFolders` or `sources` globs | Buildable folders (Tuist 4.62, Xcode 16) track the file system, so adding a file needs no regeneration. With globs, run `tuist generate` after adding or removing files |
| Below macOS 13 | AppKit `NSStatusItem` | `MenuBarExtra` does not exist there |
| Dependencies | `Tuist/Package.swift` plus `.external(name:)` | Run `tuist install` before generating whenever that file changes |

Keep three layers apart, whatever the app does: a client that talks to the outside world and decodes, a store that owns state, refresh timing and errors, and views that only render the store and send it user intent. A view body that fires a request is refetched on every redraw and cannot be tested.

### 4. Lay out the project

```text
Beacon/
├── Tuist.swift               # tells Tuist where the root is
├── Project.swift             # targets, Info.plist keys, deployment target
├── mise.toml                 # pinned Tuist version
├── Beacon/Sources/           # BeaconApp.swift, BuildClient.swift, BuildStore.swift, BuildListView.swift
├── BeaconTests/              # store and decoding tests
├── Scripts/dev.sh            # rebuild and relaunch
└── .gitignore                # *.xcodeproj  *.xcworkspace  Derived/  .build/
```

### 5. Write the manifests

`Tuist.swift` needs one line of content: `let tuist = Tuist(project: .tuist())`. In `Project.swift`, the menu bar behaviour comes from a single Info.plist entry; everything else is an ordinary macOS app target. Manifests are edited as text, or with `tuist edit`, which opens a temporary Xcode project with autocompletion for them.

### 6. Write the app

- The `App` body holds the `MenuBarExtra` scene and creates the store once. No networking or parsing here.
- The label can change with state: pass a different `systemImage` when something needs attention.
- Always include a Quit control (`NSApplication.shared.terminate(nil)`). Without a Dock icon it is the only way out besides Activity Monitor.
- For preferences, add a `Settings` scene and open it with `SettingsLink` (macOS 14).
- To let users hide the icon, use the `MenuBarExtra` initializer that takes an `isInserted` binding.
- Launch at login is `SMAppService.mainApp.register()` and `unregister()` from the ServiceManagement framework (macOS 13); the user can revoke it in System Settings, so read `SMAppService.mainApp.status` instead of caching a flag.

### 7. Build and relaunch from the terminal

```bash
#!/usr/bin/env bash
# Scripts/dev.sh — regenerate, build, restart Beacon
set -euo pipefail
cd "$(dirname "$0")/.."

APP=Beacon
PRODUCTS="$PWD/.build/DerivedData/Build/Products/Debug"

tuist generate --no-open
tuist xcodebuild build \
  -workspace "$APP.xcworkspace" -scheme "$APP" -configuration Debug \
  -destination 'platform=macOS' -derivedDataPath "$PWD/.build/DerivedData" -quiet

for pid in $(pgrep -x "$APP" || true); do kill "$pid"; done    # stop any copy that is running
"$PRODUCTS/$APP.app/Contents/MacOS/$APP" > .build/$APP.log 2>&1 &
echo "started $APP, pid $!, output in .build/$APP.log"
```

The script starts the executable inside the bundle directly, so the app inherits the shell's environment and its output goes to a log file; `open Beacon.app` would do neither. `tuist generate` opens Xcode unless `--no-open` is passed. `tuist xcodebuild build` is a pass-through to `xcodebuild` (same flags) that also reports timings to a Tuist server if one is configured; `tuist build` is deprecated in its favour. `tuist run Beacon` builds and runs a scheme in one step, but it does not stop a copy that is already running, which is why the script exists.

### 8. Verify before reporting

| Check | Command | Expected |
|-------|---------|----------|
| Manifests compile | `tuist generate --no-open` | Exit status 0, workspace written |
| App builds | `Scripts/dev.sh` | No errors; the script prints the new PID |
| Agent app | `plutil -p .build/DerivedData/Build/Products/Debug/Beacon.app/Contents/Info.plist \| grep LSUIElement` | `"LSUIElement" => 1` (or `true`) |
| Running | `pgrep -x Beacon` | One PID |
| Tests | `tuist test` | All pass |
| Scripts | `bash -n Scripts/dev.sh` | No output |

Then tell the user which commands ran and what they printed, and ask them to confirm the icon is visible: an agent cannot see the menu bar, and on a crowded menu bar macOS may not show every icon.

## Examples

### Example 1: a new menu bar app that shows failing nightly builds

**Request:** "Create a menu bar app called Beacon for macOS 14 that lists our failing nightly builds. Tuist project, no Dock icon."

```swift
// Project.swift
import ProjectDescription

let project = Project(
    name: "Beacon",
    targets: [
        .target(
            name: "Beacon",
            destinations: .macOS,
            product: .app,
            bundleId: "io.harborlane.Beacon",
            deploymentTargets: .macOS("14.0"),
            infoPlist: .extendingDefault(with: [
                "LSUIElement": true,
            ]),
            buildableFolders: ["Beacon/Sources"],
            dependencies: []
        ),
        .target(
            name: "BeaconTests",
            destinations: .macOS,
            product: .unitTests,
            bundleId: "io.harborlane.BeaconTests",
            deploymentTargets: .macOS("14.0"),
            buildableFolders: ["BeaconTests"],
            dependencies: [.target(name: "Beacon")]
        ),
    ]
)
```

```swift
// Beacon/Sources/BuildStore.swift
import Observation

@MainActor @Observable
final class BuildStore {
    private(set) var builds: [Build] = []
    private(set) var lastError: String?
    var failing: [Build] { builds.filter { $0.status == .failed } }

    private let client: BuildClient
    init(client: BuildClient) { self.client = client }

    func refresh() async {
        do {
            builds = try await client.latestBuilds()
            lastError = nil
        } catch {
            lastError = error.localizedDescription   // keep the old list on screen
        }
    }
}
```

```swift
// Beacon/Sources/BeaconApp.swift
import SwiftUI

@main
struct BeaconApp: App {
    @State private var store = BuildStore(client: BuildClient())

    var body: some Scene {
        MenuBarExtra("Beacon", systemImage: store.failing.isEmpty ? "checkmark.circle" : "exclamationmark.triangle.fill") {
            BuildListView(store: store)
                .task { await store.refresh() }
        }
        .menuBarExtraStyle(.window)
    }
}
```

`BuildClient` reads its token with `ProcessInfo.processInfo.environment["BEACON_CI_TOKEN"]` and decodes with optional fields for anything the API may omit. `BuildListView` shows `store.failing`, the error line when `lastError` is set, a Refresh button and a Quit button.

```bash
tuist generate --no-open && Scripts/dev.sh
```

**Result:** `Beacon.xcodeproj` and `Beacon.xcworkspace` appear beside `Project.swift`, the synthesized Info.plist lands under `Derived/`, and the build ends without errors. `pgrep -x Beacon` prints one PID, nothing is added to the Dock, and the checkmark icon switches to the warning triangle when a build fails.

### Example 2: adding Quit and "Launch at login" to an existing app

**Request:** "Beacon has no way to quit, and I want it to start when I log in."

The manifest does not change. A small section goes at the bottom of the panel:

```swift
// Beacon/Sources/PanelControls.swift
import ServiceManagement
import SwiftUI

struct PanelControls: View {
    @State private var startsAtLogin = SMAppService.mainApp.status == .enabled

    var body: some View {
        Toggle("Launch at login", isOn: $startsAtLogin)
            .onChange(of: startsAtLogin) { _, enabled in
                do {
                    if enabled { try SMAppService.mainApp.register() }
                    else { try SMAppService.mainApp.unregister() }
                } catch {
                    startsAtLogin = SMAppService.mainApp.status == .enabled   // show the real state
                }
            }
        Divider()
        Button("Quit Beacon") { NSApplication.shared.terminate(nil) }
            .keyboardShortcut("q")
    }
}
```

**Result:** because the target uses a buildable folder, the new file is picked up without regenerating; `Scripts/dev.sh` rebuilds and restarts the app. Turning the toggle on makes Beacon appear under System Settings, General, Login Items. If the user removes it there, the toggle shows off the next time the panel opens, because it reads `status` instead of a stored preference.

## Guidelines

- Do not edit or commit `*.xcodeproj`, `*.xcworkspace` or `Derived/`. A change made in Xcode's target editor disappears on the next `tuist generate`; put it in `Project.swift`.
- After editing `Project.swift`, `Tuist.swift` or `Tuist/Package.swift`, regenerate before building. A build against a stale project is the usual cause of "file not found in scope" after a manifest change.
- The `.menu` style renders standard menu items only (buttons, toggles, dividers, pickers, submenus). Layout modifiers, text fields and custom drawing are ignored or look wrong there; switch to `.window`.
- Stop the running copy by PID from `pgrep -x` with the exact process name. Pattern matches on a partial name can hit unrelated processes.
- An environment variable exported in the terminal reaches the app only when the executable is started from that shell, as `Scripts/dev.sh` does. A copy opened from Finder or at login does not see it, so for daily use keep secrets in the Keychain. Never hard-code them in a manifest or in Swift sources.
- A locally built app is signed to run on this Mac only. Giving it to other people requires Developer ID signing and notarization, which is a separate job.
- `SMAppService` registers the bundle at its current path. Register from the copy in `/Applications`, not from the build folder, or the login item will point at a path that the next clean build removes.
- `tuist generate`, `tuist xcodebuild` and `tuist test` need Xcode; none of this runs on Linux or in a container without macOS.
- Wrong tool for a conventional windowed app. If the product should sit in the Dock and open documents or windows, remove the `LSUIElement` key and build it around `WindowGroup`.