Building a local-first speech translator in Rust. It needs to capture whatever the user is hearing (system audio) so the model can translate it on-device — no cloud round-trip, no bot joining the call.

macOS 14.2+ Core Audio Taps look like the right primitive. CATapDescription::initStereoGlobalTapButExcludeProcesses(@[]) paired with an aggregate device + IOProc gives me a healthy IO callback at ~94 Hz on a stereo 48 kHz tap. But every buffer is zero-filled. Frame count is correct, samples are exactly 0.0. Classic TCC csreq-failure signature: the tap is "permitted" in System Settings but the OS silently zero-fills delivery.

Tried so far: - Granted Audio Capture in System Settings → nothing changes - codesign --force --sign - (ad-hoc) → still zero-filled - tccutil reset SystemAudioRecording → "Failed to reset" on macOS 15+ (the service name doesn't exist there) - Reinstalled to a stable PATH so TCC had something durable to bind to → no change

No Apple Developer membership — $99/yr is a steep entry fee for an open-source side project that may never ship a release.

Three questions: 1. Is a paid Developer ID actually mandatory for Core Audio Taps to deliver real samples, or does a self-signed Keychain cert + manual trust work durably across rebuilds? 2. What's the right tccutil reset service name for system-audio capture on macOS 15/16? Or is the only durable reset path through the Privacy & Security UI now? 3. The long-term plan is to ship on Linux (PipeWire/Pulse) and Windows (WASAPI loopback) as well, so the cross-platform shape matters from the start. Do those paths have equivalent unsigned-binary gating headaches, or does system-audio capture "just work" there for an open-source dev build?

Curious how others who've shipped similar local-audio tools handled the cross-platform story.