Apps do not trigger pop-up asking for permission to access local network on macOS Sequoia/Tahoe

We are having an issue with the Local Network permission pop-up not getting triggered for our apps that need to communicate with devices via local network interfaces/addresses.

As we understand, apps using UDP should trigger this, causing macOS to prompt for access, or, if denied, fail to connect. However, we are facing issues with macOS not prompting this popup at all.

Here are important and related points:

  • Our application is packaged as a .app package and distributed independently (not on the App Store).
  • The application controls hardware that we manufacture. In order to find the hardware on the network, we send a UDP broadcast with a message for our hardware on the local network, and the hardware responds with a message back.
  • However, the popup (to ask for permission) never shows up. The application is not able to find the hardware device. It is interesting to note that data is still sent out to the network (without the popup) but we receive back the wrong data.

The behaviour is consistent macOS Sequoia (and above) with both Apple And Intel silicon.

Workarounds that have been tried:

  • Manual Authorization: One solution suggested in various blogs was to go to "Settings → Privacy and Security-> Local network", find your application and grant access. However, the application never shows up in the list here.
  • Firewall: No difference is seen in behaviour with firewall being ON OR OFF.
  • Setting NSLocalNetworkUsageDescription: We have also tried setting the Info.plist adding the NSLocalNetworkUsageDescription with a meaningful string and updating the NSBonjourServices.
  • Running Via terminal (WORKS): Running the application via terminal sees no issues. The application runs correctly and is able to send UDP and receive correct data (and find the devices on the network). But this is not an appropriate solution.

How can we get this bug/issue fixed in macOS Sequoia (and above)?

Are there any other solutions/workarounds that we can try on our end?

Have you read through TN3179 Understanding local network privacy? If not, please do so; it has a whole bunch of information about this technology.

If that doesn’t help, my first bit of advice is that you re-test on a ‘clean’ machine. That way you can be sure that your day-to-day development work isn’t messing with the local network privacy state [1].

I usually use a VM for this sort of testing, restoring from a fresh snapshot between tests.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] It’d be nice if there were a way to reset the local network privacy state but as TN3179 there’s no way to do that )-:

Our engineers have thoroughly followed the practices outlined in TN3179.

The apps have been tested on a variety of test systems (including clean installs) in our test lab. As the issue has also been reported by many end-user customers, we are confident that the behaviour is reproducible across all systems and test environments/setups. We can affirm that it is not specific to one system and its corrupted local network privacy state.

Our engineers have thoroughly followed the practices outlined in TN3179.

Cool.

I’m pretty sure there are mysterious extant problems with local network privacy, especially on the Mac. However, the ones I’m aware of are much harder to reproduce [1]. In your case it sounds like you can reproduce this 100% of the time. For example:

  1. You set up a VM that’s never seen your app before.
  2. You install the app on that VM.
  3. You start it up.
  4. It’s blocked from performing local network operations.
  5. And it never displays the local network alert.

Is that right?

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] For example, the one in this thread

Hello Quinn,

We wanted to followup on this topic of broken Local Network security access on macOS. This issue has been open on our side for a while and we're just starting to escalate it now.

We haven't setup a VM yet. This issue reproduces 100%, immediately on new machines. We are aware of at least 10 systems that this reproduces on, including new systems and old systems. (100% of systems are broken) A fresh install is not necessary, and actually if someone were to have to install a fresh OS in order to use our software, that's unworkable too. Our existing working software simply broke in that macOS upgrade.

We only have a single algorithm style for network communication, we haven't deployed experiments that might break the detection.

We get this complaint regularly from Apple employees who use our products. We were hoping one of them would be able to get this fixed but they move on after launching via Terminal.

On to the technical side:

There may be two issues here.

Our application sends a UDP broadcast successfully. Our device sends back a UDP response, which makes it back into our app. The response is corrupted though, so we don't get the full picture of the device state in order to proceed to the next step.

This seems very broken. We shouldn't be able to send a message without authorization, and the popup never comes.

How do we get this addressed? We can give you a link to our app and you can try it, it will send the message on your Ethernet connection.

Thanks

Apps do not trigger pop-up asking for permission to access local network on macOS Sequoia/Tahoe
 
 
Q