Investigate XPC for CLI-to-daemon IPC

[pszypowicz]

Context

MicGuard currently uses two IPC mechanisms between the CLI (mic-guard) and the running daemon:

1. Config file writes + DispatchSource file watcher — for enable, disable, set commands. The CLI writes to ~/.config/mic-guard/, the daemon watches the directory with a DispatchSource and reacts.
2. DistributedNotificationCenter — for ping (and soon mute/setVolume). The CLI posts a notification, the daemon observes it and acts.

Both work reliably today because the app is not sandboxed (distributed via Homebrew, not the Mac App Store).

Why consider XPC

Apple's developer documentation recommends XPC (NSXPCConnection) as the standard macOS pattern for inter-process communication between a CLI tool and a daemon/agent. Key advantages:

• Bidirectional communication — strongly typed interfaces via NSXPCInterface and Swift protocols. Currently we can't get a response back from the daemon (e.g., confirming a mute toggle succeeded).
• Reliable delivery — DistributedNotificationCenter docs explicitly warn that notifications may be dropped if the server's queue fills up and have "unbounded latency". XPC guarantees delivery.
• Structured messages — typed protocol methods vs. parsing string dictionaries from userInfo.
• Security — built-in process isolation. DistributedNotificationCenter docs note it is "NOT a secure communications protocol".
• Sandboxing ready — if MicGuard ever moves to the Mac App Store, sandboxed apps cannot send distributed notifications with userInfo (must be nil). XPC works seamlessly with sandboxing.

Current assessment (March 2025)

DistributedNotificationCenter is adequate for now:

• The app is not sandboxed and has no plans to be
• All commands are fire-and-forget (the daemon broadcasts statusChanged back, closing the feedback loop naturally via CoreAudio listeners)
• The existing pattern is simple and proven
• Adding XPC would require: a Mach service, a launchd plist, a separate XPC service target in the Xcode project, and an NSXPCInterface protocol — significant complexity

What an XPC migration would look like

1. Define a Swift protocol for the daemon's interface:

   @objc protocol MicGuardDaemonProtocol {
       func toggleMute(reply: @escaping (Bool) -> Void)
       func setVolume(_ volume: Int, reply: @escaping (Bool) -> Void)
       func setPreferredDevice(_ name: String, reply: @escaping (Bool) -> Void)
       func setEnabled(_ enabled: Bool)
       func requestStatus(reply: @escaping ([String: String]) -> Void)
   }

2. Register a Mach service in the daemon (via NSXPCListener)
3. Have the CLI connect via NSXPCConnection(machServiceName:)
4. Replace all file-write and notification-based IPC with XPC calls
5. Keep DistributedNotificationCenter only for outbound broadcasts to external consumers (sketchybar, etc.) — those are genuinely one-to-many and appropriate for notifications

When to pursue this

• If the app needs request/response IPC (e.g., CLI needs to confirm an action succeeded)
• If sandboxing becomes a requirement (Mac App Store distribution)
• If notification drops become a problem in practice
• As a general architecture improvement when the IPC surface grows

References

• Apple: DistributedNotificationCenter
• Apple: NSXPCConnection
• Apple: Creating XPC Services

[pszypowicz]

XPC Implementation Attempt — Findings & Blockers (March 2026)

We implemented the full XPC rewrite (commit d758bbf). Here's what we learned:

What works

• Modern Swift XPC API (XPCListener/XPCSession from the XPC framework) with native Codable message support — no @objc protocol needed
• XPCSession inactive+activate pattern — creating the session as .inactive then calling activate() throws XPCRichError gracefully when the Mach service is unavailable (instead of the _xpc_api_misuse trap that occurs with default auto-activation on dealloc)
• Daemon listener (XPCListener(service:)) works when the Mach service is registered in launchd's bootstrap namespace
• CLI client (XPCSession(machService:, options: .inactive) → activate() → sendSync) works cleanly with typed request/response
• @preconcurrency import XPC is required and correct per Apple's Swift 6 migration guidance — XPCSession.InitializationOptions.inactive is exposed as static var instead of static let in Apple's headers

The blocker: Launch Constraint Violation with ad-hoc signing

For XPC Mach services to work, the daemon must be launched by launchd with the Mach service declared in a LaunchAgent plist. The proper way to register a LaunchAgent is SMAppService.agent(plistName:).

However, when launchd tries to spawn the agent, macOS enforces Launch Constraints on the executable:

xpcproxy exited due to OS_REASON_CODESIGNING | Launch Constraint Violation,
(Constraint not matched) launch type 0, failure proc:
/Applications/MicGuard.app/Contents/MacOS/MicGuard

MicGuard is ad-hoc signed (codesign --sign -) for Homebrew distribution. Ad-hoc signing does not satisfy the launch constraints required by SMAppService.agent() for LaunchAgent executables. This is a macOS security requirement — the binary needs a proper Developer ID signature (or at least a development certificate) for launchd to trust it as a managed agent.

What this means

Distribution method	XPC possible?	Why
Homebrew cask (ad-hoc signed)	No	Launch Constraint Violation blocks SMAppService.agent()
Developer ID signed	Yes	Proper signing satisfies launch constraints
Mac App Store	Yes	App Store signing satisfies constraints
make dev (manual launchctl bootstrap)	Yes	Bypasses SMAppService, registers Mach service directly

Options going forward

1. Get a Developer ID certificate — sign the app properly, SMAppService.agent() works, XPC works end-to-end. This is the "correct" path per Apple.
2. Keep the current dual approach — XPC code exists and works for development (make dev). Production Homebrew builds fall back to DistributedNotificationCenter for CLI→daemon (the pre-XPC pattern). CLI commands that require daemon response (mute, toggle, etc.) work fire-and-forget via notifications.
3. Separate the daemon as a helper executable — Apple's sample code pattern: main app is UI-only, a separate LaunchAgent binary handles XPC. But this still requires proper signing.
4. Notarization — Apple requires notarization for Developer ID-signed apps. This adds a xcrun notarytool step to the release pipeline.

Implementation details preserved

The XPC implementation is complete and tested in the codebase:

• Sources/MicGuardCore/XPCProtocol.swift — MicGuardRequest/MicGuardResponse Codable types
• Sources/MicGuardCore/XPCClient.swift — sendDaemonRequest() with inactive+activate pattern
• Sources/MicGuardCore/AudioMonitor.swift — XPCListener with typed handler, handleRequest() dispatcher, centralized toggleMute()
• Resources/com.pszypowicz.MicGuard.agent.plist — LaunchAgent plist with BundleProgram and MachServices
• Makefile dev/dev-stop targets — local XPC testing via launchctl bootstrap

References

• Apple: Updating your app package installer to use the new Service Management API
• Apple: XPCSession.activate() — "Deinitializing an inactive session causes the process to crash"
• Apple: Adopting strict concurrency in Swift 6 apps