macOS has never had a built-in, system-wide per-app volume mixer the way Windows has since 2007. Core Audio, the framework macOS's audio runs on, was designed around a single shared output device rather than individual app sessions, which is a genuine design choice, not a feature Apple simply hasn't gotten around to.
Windows users take Volume Mixer for granted: right-click the speaker icon, and every app making sound gets its own slider, remembered between launches. Reach for the same thing on a Mac and it either isn't there, or only shows up for a handful of apps. That gap sits deeper than a missing settings pane. It comes from how Apple's audio stack is actually built, and it's worth being precise about it, because most explanations either wave it away as an Apple oversight or overstate what the workarounds actually do.
Windows has had a per-app mixer since 2007
Windows introduced session-based audio with the rebuilt engine that shipped in Vista in 2007, and it has stayed part of Windows ever since. Every app that plays sound gets its own audio session inside the shared engine, and Volume Mixer exposes each session as an independent slider automatically. Close the app and reopen it, and Windows remembers where you left it. It's a native, opt-out feature: an app gets a session whether or not its developer did anything special to ask for one.
Core Audio was built around devices, not app sessions
Apple's audio framework models the world differently. At its centre sits the Hardware Abstraction Layer, which represents physical and virtual audio hardware as devices with streams, not as the apps sending sound to them. There is one default output device and one system volume, adjusted by one set of volume keys and one HUD. An app's audio passes through that shared path unless something intercepts it before it gets there. There has never been a first-class "per-process channel with its own volume" sitting inside that model the way Windows' session engine has had for nearly two decades.
A design decision, not an oversight
This isn't Apple quietly failing to catch up. It reflects a genuinely different assumption about what a volume control is for: one Mac, one output at a time, one number, set by one control. The same assumption shows up across the rest of Apple's hardware, from the iPhone's single ringer volume to the one number a HomePod exposes, and it long predates Core Audio itself.
There's a second reason a real per-app mixer is a harder problem on the Mac than it sounds. Reading or altering another app's live audio stream is exactly the kind of capability macOS treats as privacy-sensitive, on the same footing as reading someone's screen. Apple didn't give third-party developers a supported way to do that until Core Audio Process Taps arrived in macOS 14.4 in 2024, and even then it's gated behind a one-time permission prompt, not silently available to any app that asks.
Every feature free for 30 days. No account, no card details.
Download for MacHow third-party apps close the gap
Without an OS-level mixer to plug into, apps that offer per-app volume on a Mac have had to build it themselves, and there are really two different ways to do that.
Route each app to its own device, then control the device. The older, more common approach: install a virtual audio driver, assign an app to a virtual or real output, and adjust that device's own volume instead of the app's. It produces the same practical effect as a per-app slider, but what's actually being controlled is a device, not the app itself, and it typically needs a driver installed alongside the app.
Capture the app's own audio stream directly. Newer, and closer to what Windows does natively: Core Audio Process Taps, added in macOS 14.4, let a permitted app tap into another app's live audio, mute that app's normal output, and re-render the captured audio with new volume applied before it reaches an output. This works on the app's actual stream rather than a stand-in device.
Where Chorus fits
Chorus's per-app volume uses Process Taps, the newer of the two approaches. It captures the audio each app produces, suppresses that app's normal output, and re-renders it to whichever device you've chosen with the volume, mute, and boost you've set applied. There's no virtual driver to install and no separate device to manage. In the interest of accuracy: this one feature specifically needs macOS 14.4 or later, because that's when Process Taps arrived, even though the rest of Chorus, including output grouping and per-app output routing, runs from macOS 13. It also needs a one-time permission grant, since reading another app's audio is exactly the sensitive capability described above.
That gets you the same practical result as a native per-app mixer, for every app currently making sound, whether or not that app ever built in support for macOS's own limited per-app volume feature. It stays scoped to volume, mute, boost and output, though. Chorus doesn't add EQ, audio effects, recording, or the kind of app-to-app virtual routing a DAW uses; it solves the one problem of giving each app a working volume of its own.
| macOS | Windows | |
|---|---|---|
| Native per-app mixer | No system-level equivalent | Yes, since Vista in 2007 |
| Where it lives | Control Center's Sound module | Volume Mixer |
| Coverage | Only apps that opt in | Every app automatically |
| Levels remembered between launches | No | Yes |
None of this makes macOS wrong to have built things this way. It just means anyone who wants a Mac to behave like Windows' Volume Mixer has to go looking for it, rather than finding it already sitting in System Settings.
For the full technical detail on the framework, see Apple's own Core Audio developer documentation.
Frequently asked questions
Does macOS have a native per-app volume mixer like Windows?
No. macOS has no built-in, system-wide per-app volume mixer in System Settings the way Windows has had since Windows Vista in 2007. Control Center's Sound module shows individual sliders for some apps, but only for the ones that specifically build in support for that feature, and the level resets once the app quits.
Why doesn't Apple build a per-app volume mixer into Core Audio the way Windows does?
Core Audio was designed around a single shared output device with one system volume, not around individual app audio sessions each carrying their own persistent volume. That's a different starting assumption to Windows' audio engine, which has modelled every app as its own session since 2007, rather than something Apple has simply failed to add.
How do apps like Chorus add per-app volume if macOS doesn't support it?
They use Core Audio Process Taps, an API Apple added in macOS 14.4, which lets an app you've granted permission to capture another running app's audio stream directly, mute that app's normal output, and re-render the captured audio with new volume applied before it reaches an output. It requires a one-time permission grant, similar to granting screen recording access.
Is routing an app to a different virtual audio device the same as per-app volume?
Not quite. Older workarounds route each app to its own virtual or real output device and let you control that device's volume, which produces a similar practical result but is really per-device volume rather than volume attached to the app itself. Process Taps work more directly on the app's own audio stream instead.
Does Chorus's per-app volume work on every version of macOS?
No, this one feature specifically needs macOS 14.4 or later, because it depends on Core Audio Process Taps, which Apple introduced in that release. The rest of Chorus, including output grouping and per-app output routing, works from macOS 13 onward.
