Proposal: consider a criterion (or documented pattern) for desktop-app presence choice — Dock icon / menu bar / background-only

[trsdn]

Observation

Across the menu-bar macOS apps in this account, whether the app shows a Dock
icon, a menu bar status item, both, or neither is hardcoded per app, with no
user choice:

• Dock + menu bar always, no way to turn either off: trsdn/OpenPromptr,
  trsdn/OpenFreshr
• Menu bar only always (LSUIElement), no way to get a Dock icon:
  trsdn/PtionsPlus, trsdn/OpenSwitchr, trsdn/OpenWritr, trsdn/OpenZombr,
  trsdn/OpenZonr
• No menu bar item at all, despite actions that would benefit from quick
  access without switching to the app window: trsdn/OpenConnct,
  trsdn/OpenCamraHub

Per-app issues proposing a "presence" setting (Dock / menu bar / both /
background-only, with NSApplication.setActivationPolicy switched at runtime)
are filed against each: OpenPromptr#32, OpenFreshr#38, PtionsPlus#40,
OpenSwitchr#82, OpenWritr#80, OpenZombr#9, OpenZonr#65, OpenConnct#25,
OpenCamraHub#64.

What this issue asks

Not a specific criterion text — the observation is one AI agent noticing the
same gap repeated nine times, which usually means it belongs in the shared
standard rather than nine separate reinventions, but whether and how that's
true is the maintainer's call, not something to assume. I checked the existing
catalog (standard.yml) and nothing covers this today — closest are X01–X05
(accessibility) and the I/product-identity section, neither of which reaches
"can the user choose how the app presents itself in Dock/menu bar."

Three shapes this could take, roughly in order of how much the standard would
own:

1. A criterion, for whatever profile fits a desktop/menu-bar application
   (a new one, or an addition to an existing platform-specific profile),
   requiring that presence be a user choice rather than fixed at build time —
   with the usual Not applicable for apps that aren't menu-bar apps at all.
2. A documented pattern, the way templates/repo-stats/ or
   templates/release-notes/ give a reusable starting point without being an
   assessed criterion — a short guide plus maybe a reference SwiftUI/AppKit
   snippet for switching .regular/.accessory at runtime and handling
   reopen, that repositories can adopt or not.
3. Out of scope — this is a product/UX decision about what an app does,
   not about repository governance, security, or documentation, and the
   standard should stay out of it. If so, closing this with that reasoning is
   a useful answer too.

Why raise it here rather than just fixing each app

The per-app issues can be implemented independently regardless of what happens
here. This issue exists so the pattern is visible in one place before nine
apps grow nine slightly different flavors of the same setting.

🤖 Generated with Claude Code