macOS menu bar app blueprint
Architectural decisions for apps built on ~/blueprints/macos. For commands, use the macos skill.
The shape every app shares
- SwiftPM, three targets:
__App__Core (portable logic, tested via a CLI), __app__cli
(headless), __App__ (thin AppKit+SwiftUI UI). Put logic in Core; keep the app target thin.
- AppKit
NSStatusItem + native NSMenu with SwiftUI rows hosted in NSMenuItem.view. Not
MenuBarExtra — that can't draw live icons or show multiple items, and boxes you in.
- Modern Observation (
@Observable/@State/@Bindable), injected UserDefaults, no
ObservableObject.
- Developer-ID-direct distribution: notarized zip → Sparkle auto-update → Homebrew cask.
Decide the data source
| App idea |
Data |
Modules to enable |
| Static/computed (clock, system stat, timer) |
none / local compute |
core only |
| Reads a public API (weather, prices, status) |
URLSession + cache |
networking |
| Reads an authed API (GitHub, a SaaS) |
API + stored token |
networking + credentials (+ oauth if OAuth) |
| Local prefs/state only |
UserDefaults (built in) |
core only |
| Live indicator in the menu bar (progress, count) |
any of the above |
add icon-render |
macos new <slug> --api enables networking + oauth + credentials up front. Otherwise add a
module later with macos modules update <slug> <module>.
Credentials
If the app stores a token/key, use the credentials module's TokenStore (Keychain in release,
file in debug — so dev and agents never hit a Keychain prompt). Never roll your own SecItem calls;
never log tokens. For OAuth, pair oauth (PKCE + loopback callback) with credentials.
Menu & settings
- Menu content is a
MenuDescriptor value tree — add sections/entries there, not ad-hoc in the
controller. Keep it pure so it stays unit-testable.
- Settings is a tabbed
Settings scene; add a pane per concern, reuse SettingsSection /
PreferenceToggleRow. Persist via SettingsStore (injected UserDefaults).
Distribution
- Default: Developer ID direct. Best for open source — no sandbox restrictions, Sparkle
auto-update,
brew install --cask. This is fully built.
- Mac App Store: designed in
references/app-store-connect.md, lands in v1.1. Set
distribution: "mas" in app.config.json when ready; it requires app-sandbox entitlements and a
different upload path. Choose MAS only if you need its discovery/billing; it costs you the
non-sandbox freedoms.
When the menu bar isn't enough
A full window with a sidebar (the eventual "proper app" track) is additive: the same Core + the same
Settings scene, plus a real WindowGroup with NavigationSplitView. Anything needing private
entitlements (FamilyControls, screen recording, accessibility automation) is a meaningfully larger
native effort — flag it early; it's not a menu-bar-afternoon.
Don't
- Don't reach for
MenuBarExtra, ObservableObject, or @AppStorage — they're off-pattern here.
- Don't add dependencies casually; the baseline is Foundation + Sparkle.
- Don't put identity/distribution facts anywhere but
app.config.json.
1---2name: macos-blueprint3description: Use the macOS app blueprint to shape new native menu bar apps under ~/apps/macos. Use when deciding a menu bar app's data source, whether it needs the credentials/networking/oauth/icon-render modules, its distribution path (Developer ID direct vs Mac App Store), how the menu and settings are structured, or whether an idea needs native work beyond the menu bar (sidebar/full window). Pairs with the `macos` CLI skill for commands.4---56# macOS menu bar app blueprint78Architectural decisions for apps built on `~/blueprints/macos`. For commands, use the `macos` skill.910## The shape every app shares1112- **SwiftPM, three targets:** `__App__Core` (portable logic, tested via a CLI), `__app__cli`13 (headless), `__App__` (thin AppKit+SwiftUI UI). Put logic in Core; keep the app target thin.14- **AppKit `NSStatusItem` + native `NSMenu` with SwiftUI rows** hosted in `NSMenuItem.view`. Not15 `MenuBarExtra` — that can't draw live icons or show multiple items, and boxes you in.16- **Modern Observation** (`@Observable`/`@State`/`@Bindable`), injected `UserDefaults`, no17 `ObservableObject`.18- **Developer-ID-direct** distribution: notarized zip → Sparkle auto-update → Homebrew cask.1920## Decide the data source2122| App idea | Data | Modules to enable |23|---|---|---|24| Static/computed (clock, system stat, timer) | none / local compute | core only |25| Reads a public API (weather, prices, status) | URLSession + cache | `networking` |26| Reads an authed API (GitHub, a SaaS) | API + stored token | `networking` + `credentials` (+ `oauth` if OAuth) |27| Local prefs/state only | `UserDefaults` (built in) | core only |28| Live indicator in the menu bar (progress, count) | any of the above | add `icon-render` |2930`macos new <slug> --api` enables `networking` + `oauth` + `credentials` up front. Otherwise add a31module later with `macos modules update <slug> <module>`.3233## Credentials3435If the app stores a token/key, use the `credentials` module's `TokenStore` (Keychain in release,36file in debug — so dev and agents never hit a Keychain prompt). Never roll your own `SecItem` calls;37never log tokens. For OAuth, pair `oauth` (PKCE + loopback callback) with `credentials`.3839## Menu & settings4041- Menu content is a `MenuDescriptor` value tree — add sections/entries there, not ad-hoc in the42 controller. Keep it pure so it stays unit-testable.43- Settings is a tabbed `Settings` scene; add a pane per concern, reuse `SettingsSection` /44 `PreferenceToggleRow`. Persist via `SettingsStore` (injected `UserDefaults`).4546## Distribution4748- **Default: Developer ID direct.** Best for open source — no sandbox restrictions, Sparkle49 auto-update, `brew install --cask`. This is fully built.50- **Mac App Store:** designed in `references/app-store-connect.md`, lands in v1.1. Set51 `distribution: "mas"` in `app.config.json` when ready; it requires app-sandbox entitlements and a52 different upload path. Choose MAS only if you need its discovery/billing; it costs you the53 non-sandbox freedoms.5455## When the menu bar isn't enough5657A full window with a sidebar (the eventual "proper app" track) is additive: the same Core + the same58`Settings` scene, plus a real `WindowGroup` with `NavigationSplitView`. Anything needing private59entitlements (FamilyControls, screen recording, accessibility automation) is a meaningfully larger60native effort — flag it early; it's not a menu-bar-afternoon.6162## Don't6364- Don't reach for `MenuBarExtra`, `ObservableObject`, or `@AppStorage` — they're off-pattern here.65- Don't add dependencies casually; the baseline is Foundation + Sparkle.66- Don't put identity/distribution facts anywhere but `app.config.json`.
iannuttall