I am seeing a reproducible issue with macOS ControlCenter's per-app menu bar tracking state in a SwiftUI MenuBarExtra app. On launch the app creates its menu bar status item. ControlCenter then reads group.com.apple.controlcenter / trackedApplications, moves the app's status item host to the blocked list, sends NSStatusItemChangeVisibilityAction with visibility=0, and the app terminates because its only status item is removed.
Two observations:
- Changing only the bundle identifier makes the menu bar item appear normally.
- In trackedApplications, the affected app has its own entry with isAllowed: true; a separate entry for another app has isAllowed: false, and that disallowed foreign entry's menuItemLocations contained an entry referencing the affected app.
Removing only the affected app's reference from the other app's disallowed entry fixed the issue: the app launched normally, and ControlCenter no longer sent visibility=0. ControlCenter appears to associate one app's menu item identity with another app's disallowed tracked record, letting the foreign blocked record override the app's own allowed record. Is this expected? And is there a supported way to reset this per-app ControlCenter menu bar state without editing the protected group.com.apple.controlcenter plist directly?
Testing Environment:
macOS 26.3 (25D125)
Xcode 26.3 (17C529)
LSUIElement: true
Sandboxed app
SwiftUI MenuBarExtra
Relevant log pattern:
Host properties initialized; (bid:[AffectedApp]-Item-0-[pid])
State(applicationItem: true, clientRequestsVisibility: true, neverClip: false)
looked up value <private> for key trackedApplications
(Domain: group.com.apple.controlcenter)
Moving host to blocked list; (bid:[AffectedApp]-Item-0-[pid])
Requesting blocked host to not be visible; (bid:[AffectedApp]-Item-0-[pid])
Sending action(s): <NSStatusItemChangeVisibilityAction: ...>
Received action(s): NSStatusItemChangeVisibilityAction
0 agent requesting visibility=0 temporary=0
0 terminating on removal