BUILD(client): Raise macOS deployment target to 14

[nicholas-lonsinger]

Summary

• Raise CMAKE_OSX_DEPLOYMENT_TARGET from 10.15 to 14 (Sonoma), removing compatibility shims and dead code for macOS 10.5–10.14
• Disable the macOS overlay for all macOS builds — it relies on mach_override (no ARM support) and deprecated APIs like AuthorizationExecuteWithPrivileges
• Replace deprecated NSSpeechSynthesizer (AppKit) with AVSpeechSynthesizer (AVFoundation), eliminating the manual utterance queue and delegate chain
• Remove all dead macOS overlay code, files, scripts, and the mach-override submodule left behind after disabling the overlay
• Clean up CoreAudio.mm deprecation pragma that is no longer needed after kAudioObjectPropertyElementMaster migration

Changes by commit

1. 5adac2d — BUILD(client): Raise macOS deployment target to 14 and disable overlay

   • kAudioObjectPropertyElementMaster → kAudioObjectPropertyElementMain
   • Deprecated AudioDeviceGetProperty → AudioObjectGetPropertyData
   • Remove @available() guards for macOS 10.12/10.14
   • NSAutoreleasePool → @autoreleasepool blocks
   • Remove Carbon API fallback code, respondsToSelector: checks for long-available APIs
   • Remove macOS overlay build targets and dependencies (ScriptingBridge, Security, xar)
   • Remove USE_MAC_UNIVERSAL preprocessor guard in VersionCheck

2. 2231a65 — REFAC(client): Replace deprecated NSSpeechSynthesizer with AVSpeechSynthesizer

   • AVSpeechSynthesizer has built-in utterance queuing, so the manual NSMutableArray queue and delegate chain are no longer needed

3. 5e7f82e — MAINT(client): Remove dead macOS overlay code, files, and submodule

   • Remove 3rdparty/mach-override-src submodule and mach-override-build wrapper
   • Remove overlay scripts from macx/scripts/ and macx/osax/ directory
   • Delete overlay_gl macOS files and dead Overlay_macx.mm
   • Remove USE_OVERLAY blocks and dead forwardEvent slot from GlobalShortcut_macx.mm/.h
   • Remove Q_OS_MAC blocks from OverlayClient.cpp/.h and OverlayUserGroup.cpp
   • Remove macOS overlay UI string from GlobalShortcut.cpp/.ui and translations
   • Clean up overlay style default and font #ifdef in Settings.cpp
   • Remove dead deprecation pragma from CoreAudio.mm
   • Delete unused g15helper_macx.c

Test plan

• Verify the client builds on macOS 14+ with cmake -B build -Dserver=OFF -Dtests=ON && cmake --build build
• Verify text-to-speech works with the new AVSpeechSynthesizer backend
• Verify global shortcuts still function correctly
• Confirm overlay remains functional on Windows/Linux/FreeBSD (no changes to those platforms)

🤖 Generated with Claude Code

[coderabbitai]

Walkthrough

This PR modernizes macOS support by raising the deployment target to macOS 14 and removing legacy compatibility code. It replaces deprecated Core Audio APIs with updated equivalents, eliminates platform-specific overlay injection mechanisms, and refactors text-to-speech implementation from NSSpeechSynthesizer to AVSpeechSynthesizer. The PR removes macOS-specific compilation guards throughout the codebase, making several code paths unconditional. The overlay implementation for macOS is completely removed, with overlay support now using the Unix implementation instead. The changes simplify the codebase by dropping support for older macOS versions and deprecated frameworks.

Possibly related PRs

• mumble#7060: Modifies CMake overlay inclusion and guard logic around ARM/Apple platforms, sharing similar build-configuration changes for overlay handling.

Suggested reviewers

• Krzmbrzl

🚥 Pre-merge checks | ✅ 2

✅ Passed checks (2 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: raising the macOS deployment target to version 14. It is concise and clearly reflects the primary objective of the PR.
Description check	✅ Passed	PR description is comprehensive and well-structured with clear summary, organized changes by commit, and test plan, though one test item remains unchecked.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment

Tip

Issue Planner is now in beta. Read the docs and try it out! Share your feedback on Discord.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

src/mumble/CMakeLists.txt (1)

1035-1041: ⚠️ Potential issue | 🟠 Major

AVFoundation is only linked when coreaudio is enabled, but TextToSpeech_macx.mm depends on it unconditionally.

TextToSpeech_macx.mm is added unconditionally for Apple builds (line 794) and imports <AVFoundation/AVFoundation.h>. However, AVFoundation is currently linked only at line 1039 within the if(coreaudio) block. If a user disables CoreAudio (-Dcoreaudio=OFF), the build will fail with a linker error.

Move the AVFoundation framework linkage to the unconditional Apple block at lines 711–716, where other Apple frameworks are already linked.

Proposed fix

Add to the unconditional Apple linking block (lines 711–716):

 	target_link_libraries(mumble_client_object_lib
 		PUBLIC
 			${LIB_APPKIT}
 			${LIB_APPLICATIONSERVICES}
 			${LIB_CARBON}
+			"-framework AVFoundation"
 	)

Remove from the coreaudio block (line 1039):

 	target_link_libraries(mumble_client_object_lib
 		PUBLIC
 			${LIB_AUDIOUNIT}
 			${LIB_COREAUDIO}
-			"-framework AVFoundation"
 	)

🤖 Fix all issues with AI agents

In `@src/mumble/CoreAudio.mm`:
- Around line 513-519: Update the denied-access message in the
AVAuthorizationStatusDenied case in CoreAudio.mm: replace the outdated "System
Preferences -> Security & Privacy -> Privacy -> Microphone" text with the
correct macOS 14 string "System Settings -> Privacy & Security -> Microphone" in
the QObject::tr(...) passed to Global::get().mw->msgBox, keeping the surrounding
wording and translation call intact (the code location is the
AVAuthorizationStatusDenied branch handling microphone access in CoreAudioInput
/ CoreAudio.mm).

[nicholas-lonsinger]

@davidebeatrici @Krzmbrzl

Continuing our conversation from #7066

The only thing that I could find supporting overlay was steam for steam games, everyone else had it dropped due to the security model of macOS.

I'm submitting a new PR with changes taking the target to macOS 14 (this is oldest "actively" supported build by Apple, older version don't get security updates, just a recent certificate update).

This update is in 3 commits as it's quite a lot of cleanup code. The actual "bump" did not require much, and the middle commit was not required due to the previous API only being deprecated but felt like it would be needed eventually anyway so I added it in.

Estimates are ~90% of user base is on 14, 15 or 26 (yes the numbering jumped from incremental to year based).

Machines from the year ~2018 (+/- 1 for a single line) are still supported by this version of the OS.

[davidebeatrici]

Thank you for the detailed explanation.

[davidebeatrici]

Can we wrap this in a if NOT(APPLE) block? With the overlay option disabled there shouldn't be a hard dependency on the definition.

[Krzmbrzl]

See Davide's comment - other than that I guess this is fine.

[Krzmbrzl]

@davidebeatrici @Hartmnt should we wait with merging this until we have split the 1.6 branch? I feel like this is a reasonably large change and I would probably feel better if it lived in master for a bit before becoming part of a stable release 👀

[Hartmnt]

@davidebeatrici @Hartmnt should we wait with merging this until we have split the 1.6 branch? I feel like this is a reasonably large change and I would probably feel better if it lived in master for a bit before becoming part of a stable release 👀

Yep, 100%. 1.7.x as target

[nicholas-lonsinger]

I appreciate the thoughtful approach to release management, but I'd respectfully push back on targeting 1.7.x and would advocate for including this in 1.6.

Looking at Mumble's recent release cadence, there were roughly 3 years between 1.3 (September 2019) and 1.4 (September 2022), and about 1.5–2 years between 1.4 and 1.5 (May 2024). If 1.6 follows a similar pattern, it would land sometime in 2026. Pushing these changes to 1.7 likely means they won't reach users until 2028 or later — which, as I'll explain below, is too late for macOS users.

My two goals across the PRs I've been submitting are:

1. Universal build support — Mumble is the only piece of software I've been running that still requires Rosetta 2 translation, and that's been the case for a few years now. I'd like to get Mumble to a universal binary.

2. Moving from Accessibility to Input Monitoring permissions (#7065) — This is a significant security improvement. The Accessibility permission is one of the most powerful permissions on macOS — Apple's own documentation describes it as allowing apps to "access and control your Mac." Specifically, an app granted Accessibility can:

• Inject synthetic keyboard and mouse events into any application (via CGEventPost / kCGEventTapOptionDefault), enabling it to type keystrokes, click buttons, and interact with UI elements in other apps as if it were the user
• Log all keystrokes system-wide, functioning as a keylogger
• Read and manipulate the UI of any running application via the Accessibility API (AXUIElement), including reading text fields, pressing buttons, and navigating menus in other apps
• Enable remote control of the computer — this is the same permission that remote desktop tools (TeamViewer, etc.) require to control a Mac
• Be leveraged for privilege escalation — security researchers have documented that Accessibility combined with Automation permissions can be chained to escalate to Full Disk Access by sending keystrokes to processes like Finder to modify system settings

Mumble needs none of these capabilities for push-to-talk. All it needs is to passively listen for keyboard/mouse events. Input Monitoring provides exactly that — listen-only access via kCGEventTapOptionListenOnly — following the principle of least privilege. It cannot inject events, control other apps, or modify the system. This is a meaningful reduction in attack surface, and aligns with how Apple expects apps to request permissions since macOS 10.15.

Regarding the deployment target increase specifically — the reason I raised it was to make universal builds feasible. My original PR (#7066) only asked to move the target to macOS 11, since Universal 2 binaries require a minimum deployment target of 11.0 (Apple Silicon didn't exist before Big Sur). The previous target of 10.15 meant ARM64 builds were automatically getting bumped to 11.0 anyway, resulting in two separate effective targets. The move to macOS 14 was in response to @Krzmbrzl's suggestion in #7066 to go all the way to whatever Apple currently still supports.

Here's some timing context worth considering — Apple has laid out a clear deprecation timeline, and the window is closing faster than it might seem:

macOS Version	Expected Release	Intel Mac Support	Rosetta 2 (x86 app translation)	Impact on Mumble
macOS 26 (Tahoe)	Sept 2025 (released)	✅ Last version	✅ Full support	Current x86-only build works
macOS 27	Fall 2026	❌ Apple Silicon only	✅ Full support (last version)	x86-only build runs via Rosetta 2
macOS 28	Fall 2027	❌	⚠️ Limited (legacy games only)	x86-only Mumble build will likely no longer run

Apple announced at WWDC 2025 that Rosetta 2 will remain available as a general-purpose translation tool through macOS 27, but starting with macOS 28, only a limited subset will remain — specifically aimed at "older unmaintained gaming titles that rely on Intel-based frameworks." A general-purpose VoIP application like Mumble would not qualify for that subset.

macOS 26.4 (currently in beta) has already started showing users warnings when they launch apps that require Rosetta 2, alerting them that it will soon be discontinued.

I think it would be wise to get these changes merged and into users' hands before macOS 28 arrives in fall 2027, so that there's already a working universal or ARM-native build that people can fall back to — rather than discovering after the fact that Mumble no longer launches on their system. If these changes land in 1.7, that timeline becomes very tight or possibly too late.

[Krzmbrzl]

Thanks for the detailed explanation and reasoning. I agree that the changes are super valuable for Mumble macOS users. However, experience has shown that bigger changes almost always cause some unintended side-effects that only surface once the change has been live for some time. Typically, these come from use-cases the developers didn't anticipate while writing and/or reviewing the changes. That's the reason why I would like to have them in master for some time before they will be shipped in a stable release. This way, people making use of those changes are (on average) a lot more tech-savy than the typical end user using the release (supposedly) stable versions. That means that they are more likely to give better reports about what's going wrong (or reports at all), which allows fixing issues more effectively. Plus, it avoids having to use "the general public" as a guinea pig for testing our software.

That being said, I would like to add the following: It is true that we used to have quite large gaps between stable Mumble releases. We wanted to move to a significantly shorter release cycle for a while but there have always been some issues that got in between that. However, we also seldomly had anything that provided a real need for timely releases. What I am saying is that I am absolutely open to drafting a 1.7 release in let's say half a year after 1.6 has been officially shipped.

/CC @Hartmnt @davidebeatrici

[Hartmnt]

That being said, I would like to add the following: It is true that we used to have quite large gaps between stable Mumble releases. We wanted to move to a significantly shorter release cycle for a while but there have always been some issues that got in between that. However, we also seldomly had anything that provided a real need for timely releases. What I am saying is that I am absolutely open to drafting a 1.7 release in let's say half a year after 1.6 has been officially shipped.

I agree. In the past there was always something blocking new releases. If that is not the case, there is no trouble in drafting 1.7 earlier. I want to add though, that I think we should have at least some meaningful features implemented in 1.7 before drafting a new minor release.

[Krzmbrzl]

I want to add though, that I think we should have at least some meaningful features implemented in 1.7 before drafting a new minor release.

Fair - though I'd argue "macOS users can continue using Mumble" in and of itself seems like a meaningful feature :D