mac-capture: Add toggle to hide privacy indicators

[tagavari]

Description

Adds a toggle that allows macOS Screen Capture sources to hide macOS' privacy indicators.

For context, here is a screen recording with the privacy indicators visible, as they have always been:

2026-01-10.02-08-46.mov

Here is a screen recording with the new toggle activated to hide privacy indicators:

2026-01-10.02-09-05.mov

New toggle:

Motivation and Context

While the screen is being recorded, macOS will display a purple dot in the top right corner of the screen.
This dot can also be orange if the microphone is in use.

This dot will show up over fullscreen content, and can disrupt recordings:

Also suggested on OBS Studio Ideas and Suggestions: MacOS: Add option to exclude fullscreen recording-indicator

How Has This Been Tested?

Tested on Apple Silicon on:

macOS Monterey 12.6

Display Capture is unsupported, does nothing. Rest of the app works as expected.

macOS Ventura 13.7.8

Works as expected, privacy indicator can be hidden.

While the Hide privacy indicators from capture toggle is unchecked, recordings are identical to before.

While the Hide privacy indicators from capture toggle is checked, recordings do not include the privacy dot.

macOS Tahoe 26.2

Works as expected, same as macOS Ventura 13.7.8.

Types of changes

• New feature (non-breaking change which adds functionality)

Checklist:

• My code has been run through clang-format.
• I have read the contributing document.
• My code is not on the master branch.
• The code has been tested.
• All commit messages are properly formatted and commits squashed where appropriate.
• I have included updates to all appropriate documentation.
  ^ I haven't found any documentation this affects, but would appreciate if someone could let me know!

[Fenrirthviti]

I'm really confused what problem this is trying to solve. The orange indicator is unobtrusive and only in the task bar.

What workflow is actually impacted by this? I'm current against adding this, admittedly hacky, workaround to hide a simple dot that isn't in the way of anything?

[jcm93]

I'm really confused what problem this is trying to solve. The orange indicator is unobtrusive and only in the task bar.

The issue is that the orange indicator will also show on top of fullscreen content, which can easily happen when playing games or watching videos:

If you can use Application Capture or Window Capture to capture the content in question, this is not an issue, because the capture indicator won't appear in those capture types, but if you are using Display Capture, you're stuck with it. And Application/Window capture are not always an option for some programs that have stubborn fullscreen behavior, so there are real reasons one might be stuck using Display Capture.

[tagavari]

Thanks jcm93, that’s exactly it. When using display capture for fullscreen games or software that doesn't work with window or application capture, the indicator is rendered into the recorded video, which can be quite distracting in high-quality recordings.

@Fenrirthviti I appreciate the review. Since Apple hasn't provided a formal API to hide the privacy indicator, I’ve looked to established precedents. As suggested in the Ideas page, Chromium / WebRTC has successfully been using a similar filtering approach for over three years.

I’ve updated the PR to align with Chromium’s logic and verified the change on macOS Ventura 13.7.8 and macOS Tahoe 26.2.

If you have concerns about maintenance burden, edge cases, or alternative approaches, I'd be happy to discuss.

[Fenrirthviti]

Thanks for the clarifications, and context around this. We have engaged Apple from our side to see what the recommendation or potential future plans for this feature might be, and if they might offer a better solution. Knowing that Chrome is doing something similar certainly helps here, appreciate the footwork on that.

[jcm93]

This solution seems quite fragile to me, unfortunately.

I don't think there is any guarantee that the dictionary of window information returned by this older API is going to remain stable with the same window owner information. It actually seems a bit doubtful to me that it would, primarily because the newer ScreenCaptureKit API doesn't return any useful information whatsoever about WindowServer; the SCRunningApplication instance for it has neither an applicationName nor a bundleIdentifier (though the latter because WindowServer itself has no canonical bundle identifier), which is why you need this workaround in the first place.

So given that the newer API has no reliable way to identify a WindowServer window, or the WindowServer application, I would be fairly suspicious that an older, not-quite-deprecated API that redundantly enumerates the same information as ScreenCaptureKit would remain able to do so moving forward.

[tagavari]

Thanks for taking a look. While I agree this isn't the ideal way to identify the privacy indicator window, I proposed this implementation because it has proven stable in Chromium for several years.

As Fenrirthviti has reached out to Apple, I think this PR should wait for their feedback before moving forward in any way.

If a better solution doesn't emerge from Apple, I'm happy to either close this, or iterate on this logic (like checking the user of the pid of the window), depending on your preference for maintaining this feature.

[CyBeRoni]

Note that, as a workaround for those suffering from this problem and using more than one screen, Apple provides a way to disable the indicator on external screens: https://support.apple.com/en-us/118449. Obviously, if it's not there, it won't be captured.

[PatTheMav]

As this is a rather niche use-case, I'd suggest a different approach from a design POV:

• Instead of adding yet another checkbox, implement a multi-select dropdown that allows users to explicitly add windows to exclude from their capture.
• For convenience this dropdown may have OBS Studio's own window(s) and the privacy indicator(s) sorted to the very top, so they are easy to add to the exclusion list

This has two benefits: The "exclude stuff from being visible" use-case is handled via a single control and can be adapted to other use-cases easily, either because users "learn" to add a specific window to that list by themselves, or the project adds code in later updates to "promote" more windows to "typical exclusions".

So users can engage in self-help until the project can be updated. And corresponding knowledge base articles can be published to explain why specific windows were sorted to the top of the drop-down.