Skip to main content

Sonos App not working in MacOS Golden Gate Beta

  • June 12, 2026
  • 70 replies
  • 1708 views

Show first post

70 replies

  • Lyricist II
  • September 17, 2026

Airgetlam
  • September 17, 2026

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. 


  • Lyricist II
  • September 17, 2026

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.


AjTrek1
  • September 17, 2026

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.


  • September 17, 2026

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.

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


Smilja
  • September 17, 2026

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. 


controlav
Forum|alt.badge.img+24
  • Lead Maestro
  • September 18, 2026

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

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


  • September 18, 2026

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

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.


Frank Veldman
Forum|alt.badge.img

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

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


  • Lyricist II
  • September 19, 2026

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.


  • September 19, 2026

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.

I don’t think the new version is available with app update yet. Check the version. Did the update downgrade you back to 90.0-79210?


  • Lyricist II
  • September 19, 2026

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.

I don’t think the new version is available with app update yet. Check the version. Did the update downgrade you back to 90.0-79210?

Version 17.2.3 and build 90079210 so seems like it got downgraded.

 

Would think it would see current version is newer when you check for updates.


  • September 19, 2026

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.

I don’t think the new version is available with app update yet. Check the version. Did the update downgrade you back to 90.0-79210?

Version 17.2.3 and build 90079210 so seems like it got downgraded.

 

Would think it would see current version is newer when you check for updates.

You would think. I sure hope they get the new version in app updates soon. For those that install the new version, it’s going to start telling them there’s an update. Which will downgrade them to a non-working version. Can’t make this up.


AjTrek1
  • September 19, 2026

I just installed the MacOS Desktop App shown on the following Apple Silicon versions:

  • M1
  • M2
  • M3
  • M4 

Date stamp is 9/18/26 @ 3:38PM which I assume is PST.  The app launches with no issue! *

 * I recommend deleting the previous version before installing the new version.


  • September 19, 2026

I just installed the MacOS Desktop App shown on the following Apple Silicon versions:

  • M1
  • M2
  • M3
  • M4 

Date stamp is 9/18/26 @ 3:38PM which I assume is PST.  The app launches with no issue! *

 * I recommend deleting the previous version before installing the new version.

What happens if you select check for updates?


AjTrek1
  • September 19, 2026

@kdowling 

Rather than keep duplicating the image I posted 😂...in answer to your question….I don’t know.

I just downloaded the app and checked the .dmg while still in the downloads folder and checked it against the version that was working on my M1 Mac and that mentioned by ​@Gryph . I installed it on all my Mac’s (also replacing the working version on my M1).


  • September 19, 2026

@kdowling 

Rather than keep duplicating the image I posted 😂...in answer to your question….I don’t know.

I just downloaded the app and checked the .dmg while still in the downloads folder and checked it against the version that was working on my M1 Mac and that mentioned by ​@Gryph . I installed it on all my Mac’s (also replacing the working version on my M1).

@AjTrek1 

In the new controller, select to check for updates and let us know if it tells you there is one available. If there is, don’t update to it.


AjTrek1
  • September 19, 2026

@kdowling 

Rather than keep duplicating the image I posted 😂...in answer to your question….I don’t know.

I just downloaded the app and checked the .dmg while still in the downloads folder and checked it against the version that was working on my M1 Mac and that mentioned by ​@Gryph . I installed it on all my Mac’s (also replacing the working version on my M1).

@AjTrek1 

In the new controller, select to check for updates and let us know if it tells you there is one available. If there is, don’t update to it.

Yeah...it does. I've seen that before with Sonos and was advised by Sonos Tech in the pass to ignore “up date available” if the .dmg date stamp was very recent and all is working as it should. Sonos definitely needs to fix that.


Its Thorny
  • Author
  • Contributor I
  • September 19, 2026

An update to the Sonos Mac app version 90.0-081181 is now available. Finds system no issues now on macos Golden Gate!!


AjTrek1
  • September 20, 2026

An update to the Sonos Mac app version 90.0-081181 is now available. Finds system no issues now on macos Golden Gate!!

The download .dmg (Build) from the Sonos Website is the same as what’s installed on my Mac’s. I wouldn’t trust another version at this point as everything is loading as it should.