Why per-app volume needs extra software on Mac: the technical reason

Per-app volume needs extra software on a Mac because Core Audio, the macOS audio layer, is built around devices, not apps. Every app opens a stream to an output device, the system mixes them all down to that one device, and the only levels macOS exposes are the device's master volume and whatever slider an app ships inside itself. There is no public system control for setting one app's output level from the outside — so any tool that gives you per-app volume has to insert itself into the audio path to create the control macOS never did.

"Just add a slider per app" sounds like a small feature Apple keeps forgetting. It isn't a small feature, and they haven't forgotten. The reason it takes a separate app comes straight out of how audio is wired on macOS, and once you see the plumbing, the whole third-party category makes sense: those apps aren't hacks bolted onto a hidden setting, they're building a layer the operating system doesn't provide. Here's the actual mechanism.

Core Audio thinks in devices, not apps

At the bottom of macOS audio sits Core Audio and its Hardware Abstraction Layer — the HAL. The HAL deals in devices: your built-in speakers, your headphones, an audio interface, a Bluetooth headset. When an app plays sound, it opens an output stream aimed at a device. Ten apps playing at once means ten streams pointed at the same device, and the system mixes them together into one signal before it reaches your speakers.

The volume you control with the F-keys or the menu bar is the device's level, applied to that already-combined mix. By the time your keypress lands, the ten apps are one stream — there's no per-app knob left to turn, because per-app doesn't exist at that point in the chain. That's why turning the Mac down quiets everything at once: you're moving the master fader on a mix that was already blended. If you want the background on that specific symptom, see what per-app volume control is and why macOS doesn't have it.

The one thing macOS never exposed

An app can absolutely set its own volume — Spotify, VLC, and browsers all do. What macOS historically gave no public way to do is reach in and set another app's output level from outside it. There was no supported API a utility could call to say "put the process named Spotify at 30% and leave everything else alone." Windows has exposed exactly that for over fifteen years, which is why its Volume Mixer just works. macOS never shipped the equivalent.

So the problem developers faced wasn't "find the hidden setting." It was "the setting doesn't exist — build the layer that should hold it." There are two ways to do that, and the difference between them is the whole story of why some per-app apps need a driver and some don't.

Approach one: install a virtual audio device

The long-standing trick is to insert your own software audio device — a virtual device, implemented as a HAL plugin — into the chain and make it the system's default output. Now every app's audio flows into your device instead of the real speakers. Because the audio arrives tagged by the process that produced it, the software can apply a separate gain to each app, remix the result, and forward it to the real hardware output. Per-app volume, reconstructed by hand.

This is how the free, open-source Background Music works: a virtual driver (BGMDriver) becomes the default device, captures each app's audio, applies per-app gain, and plays the mix back through your chosen output. Pure routing tools like BlackHole — a free, open-source virtual audio driver — provide the same kind of software device as a building block for people who wire their own signal chains. It's a real, legitimate approach that predates any Apple support for the idea.

The trade-offs come with the territory. A virtual driver has to be installed and has to become your default output, so it now sits in the path of all your audio. macOS treats capturing that audio like microphone access, so it asks for permission. The software has to keep the mix glitch-free and follow along every time you switch headphones or plug in an interface. None of that is fatal — millions of people run these tools happily — but it's genuinely more moving parts than "a slider."

Approach two: tap a process directly (macOS 14.4+)

In macOS 14.4, Apple added the piece that had been missing: a public Core Audio process-tap API. Using CATapDescription and AudioHardwareCreateProcessTap, an app can create a tap on a specific process's output audio at the HAL level, read that stream, and — with the tap set to mute the original — apply its own gain before the audio plays back through your real device. No virtual driver installed, no hijacking the system default output. macOS still gates it behind a permission prompt, so nothing happens silently.

This is the framework Fader is built on, and it's exactly why Fader requires macOS 14.4 or later: the capability it depends on simply didn't exist in the public API before then. It doesn't mean Apple shipped a mixer — there's still no built-in per-app volume interface anywhere in System Settings. It means the operating system finally offers a supported hook that third-party apps can hang per-app control on, without acting as a system-wide audio driver first.

SoundSource by Rogue Amoeba (SoundSource 6, $49 one-time) is the mature commercial option and does far more than volume — routing, effects, and a per-app EQ — using the company's own long-established audio capture technology. It's excellent software. The point of the table isn't which app is best; it's that every row exists because macOS has no built-in per-app level to expose. They differ only in how they build the missing layer.

Why this isn't just Apple being stubborn

It's tempting to read the gap as neglect, but there's a design logic to it. Keeping audio device-centric makes the common path simple and reliable: apps don't have to know about each other, the system owns one clean mix, and there's a single, predictable place volume is applied. Letting any app reach into any other app's output is also a privacy and security question — reading another process's audio is sensitive, which is precisely why the 14.4 tap API is permission-gated. Apple moved slowly and shipped a controlled hook rather than a free-for-all. You can disagree with the priority; it isn't an oversight.

The practical upshot for you is unchanged either way: if you want Spotify at 30% while a call holds at 100%, the operating system will not do it, and no hidden preference will either. Something has to build the control. If you're weighing whether that "something" needs a virtual device in your setup, this plain-English guide to virtual audio devices walks through when you actually need one and when you can skip it.

Bottom line

Per-app volume needs extra software on a Mac for a concrete technical reason, not a marketing one: Core Audio mixes every app down to a single device and exposes only that device's master level, with no public control for an individual app's output. Third-party tools fill the gap either by installing a virtual audio device that captures and remixes everything, or — since macOS 14.4 — by tapping a single process directly with no driver at all. Fader takes the second route, which is why it needs macOS 14.4 and why it can turn your keyboard into a per-app mixer without ever becoming your system's audio driver.