Sonos App not working in MacOS Golden Gate Beta

This worked for me

https://www.reddit.com/r/sonos/comments/1vy34vw/comment/p7u3re5/

Not sure I understand, that thread appears, on scanning it, to be about running the app on Apple Silicon, which Sonos already released, as indicated in ​a previous post. 

After I installed macos 27 sonos app stopped working. Didn’t find it and got message to check firewall settings. Followed the commands in the reddit post I got a new version of the app called sonos-fixed and that works

The problem is this according to that post:

Since macOS Sequoia, apps need "Local Network" permission to talk to devices on your LAN. The kernel enforces that permission using the app's code-signing identifier. System Settings records your Allow using the app's bundle identifier from Info.plist. Normally those two are the same string, so nobody notices the difference.

In this Sonos build they are not the same:

• Bundle identifier: com.sonos.macController2

• Code-signing identifier: com.sonos.macController

So your Allow gets filed under one name, the kernel looks up the other, finds nothing, and treats Sonos as an app you never approved. Every discovery packet and every connection to a speaker fails inside the Mac before it reaches the network. The app only sees silence and blames the firewall.

The link is saying that while Sonos released a proper version of the desktop app for Silicon; Apple made changes in how MacOS reads the bundles/signatures. The work around in terminal allegedly fixes the issue.

The link also suggests that Sonos needs to make the proper adjustments and urges users to contact both Apple and Sonos. While I can understand the rationale I’m still suspect as to the why the desktop app launches natively on my MacStudio (M1) and MacMini (M4) both running MacOS Golden Gate 27.

Can anyone explain why the controller works when run from the terminal, but not from the app icon?

I consulted the Google Gemini Oracle:

Yes, this conclusion by the Reddit user is technically absolutely correct and pinpoints exactly why the new native macOS version of the Sonos app fails to connect to the system for many users. 

 

The user's discovery describes a classic security and permission issue under macOS, caused precisely by the incorrect handling of the two identifiers you asked about earlier. 

 

🔍 What Went Wrong at Sonos

According to the analysis by the Reddit user, the signature structure of the app in the update looks like this: 

 

• Bundle Identifier (CFBundleIdentifier): com.sonos.macController2 

• Code-Signing Identifier: com.sonos.macController 

Because the macOS operating system strictly regulates network privileges (such as local network access), this asymmetry leads to the following error: 

 

1. The Blockade: When the app launches, it requests access to the local network to search for speakers using multicast (M-Search probes). 

2. The Identity Issue: macOS links the user-granted permission ("Allow Local Network") to the app's cryptographic Code-Signing Identity. However, if the app internally operates with the mismatched Bundle Identifier, the keys do not fit together from the operating system's perspective. 

3. The Consequence: macOS blocks the app's outgoing network packets in the background, even though the user has enabled the toggle under System Settings > Privacy & Security > Local Network. The app simply fails to send data into the network and, as a result, finds no speakers. 

💡 Why the User's Workaround Works

The Reddit user suggests re-signing the app via Terminal with an ad-hoc signature, manually overwriting the Code-Signing Identifier so that it exactly matches the Bundle Identifier (com.sonos.macController2). 

 

As soon as both identifiers are identical, macOS's TCC protection (Transparency, Consent, and Control) functions correctly again: The app requests local network permission, macOS can uniquely map the request, releases the network sockets, and the speakers are found immediately. 

 

⚠️ The Catch

While this workaround resolves the issue on your local Mac: 

 

• The app loses its official Developer ID signature from Sonos. 

• macOS will classify it as "unverified" if copied to other Macs (triggering Gatekeeper warnings). 

• Automatic in-app updates will generally no longer work for this modified copy. 

The user's analysis impressively demonstrates what happens when developers disregard the consistency between the logical identity (Info.plist) and the cryptographic identity (Code Signature) during the build process. 

Because code run from Terminal does not need the Local Network permission.

Thank you. That sure seems strange to me. Like Apple missed something here. So the app needs local network permissions, but the app doesn’t really need local network permissions. It can use the local network without them if launched from a terminal instead of the GUI. Wow.

There is a new version on the Sonos website! Problem solved.

https://support.sonos.com/downloads#sonos_app_for_macos_and_windows

Worked fine. Then I looked for an update and it found one. Then it’s back to the same problem again.