Why Mac volume apps ask for system audio recording
The wording sounds like a red flag. For a per-app volume tool, it can be the correct permission. The real question is whether the app is recording audio to disk or processing output audio in real time.
The short answer: approve system audio recording permission for a Mac volume app only when the app needs to read outgoing app audio to adjust, route, mute, record, stream, or transcribe it. For TeenySound, that permission is used for per-app volume and routing through Apple's Core Audio tap path. It is not used to save recordings.
That distinction matters because macOS uses the word "recording" for more than one user intent. Sometimes an app is actually saving audio. Sometimes it is receiving an output stream so it can change the volume before the sound reaches your speakers.
What the permission means
Apple's support docs group screen and system audio recording under Privacy and Security. You can allow apps to use screen and audio recording, and you can review or revoke that access later in System Settings. Apple also has a developer key, NSAudioCaptureUsageDescription, for apps that request access to capture system audio on macOS.
That permission is broad enough to deserve attention. It can be used by screen recorders, streaming tools, transcription tools, audio routers, and per-app volume tools. You should not approve it for a timer, calculator, clipboard manager, color picker, or generic menu bar utility.
Why per-app volume needs it
macOS gives you one master output volume. It does not expose a native slider for Chrome, Music, Zoom, Slack, and a game separately. To change one app without changing the others, a utility has to work with that app's output stream.
Apple's Core Audio taps are the modern route. A tap can target outgoing audio from a process or a group of processes. The utility can then scale volume, mute, or route that stream. That is why a driver-free per-app volume app asks for system audio access even when the app is not a recorder in the normal sense.
The permission is the gate to the stream. The product's behavior after that gate is what you should evaluate.
What TeenySound does with audio access
teenysound uses Core Audio taps on macOS 14.2 or later. The source code creates a per-process audio path with a tap, aggregate device, and IOProc playthrough engine. Volume scaling happens in the real-time audio callback, which is why each app can have its own volume slider without installing a virtual audio device.
The app's Info.plist says: "TeenySound needs access to control volume levels for individual applications." The permission helper targets the audio-only TCC service where available, checks whether access is authorized, and opens the relevant Privacy and Security pane when manual approval is needed.
The user-facing features that depend on that access are per-app volume sliders, per-app mute, per-app output routing, mute-all, and restoring saved volumes when apps or output devices change. The app also has license validation and update checks, but those are separate from audio processing.
What TeenySound does not do
| Concern | TeenySound behavior |
|---|---|
| Does it save audio files? | No. The product is a mixer, not a recorder. |
| Does it install a virtual audio driver? | No. It uses Core Audio taps instead of a virtual output device. |
| Does it need microphone input? | No. It controls output audio from apps, not microphone capture. |
| Does audio mixing require the internet? | No. Mixing happens locally. Internet is used for license validation and update-related behavior. |
| Can you revoke the permission? | Yes. Use System Settings, Privacy and Security. Per-app audio control will stop working without access. |
When to approve or deny
Approve system audio recording for a tool whose whole job is audio: per-app volume, output routing, screen recording, streaming, transcription, podcasting, voice notes, or system-audio capture you asked for. Still check whether audio is saved locally, uploaded, or only processed in memory.
Deny it when the permission does not match the product. A notes app, launcher, clipboard manager, calendar, wallpaper app, or generic "productivity" tool should have an unusually clear reason before it gets system audio access. If the explanation is vague, deny it and see what feature breaks.
For teenysound, denying the permission means the mixer cannot see app audio streams, so the core per-app volume feature cannot work. The app should make that dependency obvious instead of pretending the permission is optional.
How to review the setting later
- Open System Settings.
- Go to Privacy and Security.
- Open Screen and System Audio Recording, or System Audio Recording on macOS versions that show it separately.
- Turn access off for apps you no longer use or no longer trust.
- Reopen the audio app and confirm whether the missing permission message is clear.
If an app cannot explain why the permission is missing, that is useful information. Permission recovery is part of product quality, not an afterthought.
Sources checked
- TeenySound claims were checked against the TeenySound homepage and local source files for audio permission handling, Core Audio taps, per-app volume, output routing, and Info.plist usage text.
- Apple Developer Documentation: Capturing system audio with Core Audio taps.
- Apple Developer Documentation: NSAudioCaptureUsageDescription.
- Apple Support: Allow apps to use screen and audio recording.
- TeenyApps: Mac menu bar app permissions.
Per-app volume without a virtual audio driver.
teenysound gives each audio app its own volume slider, mute control, and output route. Native Mac app, $9.99 once, 3-day trial.