---

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

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

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

#!/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."

// 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")]
        ),
    ]
)

// 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
        }
    }
}

// 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.

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:

// 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.