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

Question

Created 1w

Replies 5

Boosts 0

Participants 2

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?

Boost

Answer 1

DTS Engineer OP

Apple

1w

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 )-:

0

Answer 2

TotalPhase OP

1w

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.

0

Answer 3

DTS Engineer OP

Apple

1w

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:

You set up a VM that’s never seen your app before.
You install the app on that VM.
You start it up.
It’s blocked from performing local network operations.
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

0

Answer 4

TotalPhase OP

1w

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

0

Answer 5

DTS Engineer OP

Apple

1w

We haven't setup a VM yet.

I strongly recommend that you do. It has some key benefits:

It strictly constrains the problem space. For example, if you have a bug with identifying the correct broadcast interface [1], such a problem will go away in a VM because there’s only one interface. So, if the local network alert always shows up in a VM but fails on real hardware, it’s likely that this isn’t an issue with local network privacy per se, but something in your code.
It makes it much easier to run tests in isolation. You can quickly iterate on your tests, creating a new clone of your ‘clean’ VM each time.
It allows you to test across OS releases. If you think something broke in, say, macOS 26.2, you can easily test 26.1, 26.2, and 26.3 beta, all in parallel.

Debugging these problems on real hardware just makes things harder.

The response is corrupted though

What do you mean by that? That the UDP datagrams you get back from the networking stack are corrupted internally? Or that your network operations are logically corrupted because you only received some of those datagrams?

My experience is that UDP code, and especially UDP broadcast code, is a common cause of bugs. These often get misidentified as local network privacy bugs, when they’re actually caused by other issues. For general advice on this front, see Extra-ordinary Networking > Broadcasts and Multicasts, Hints and Tips.

Oh, and I should check some assumptions:

When you say “app”, you’re referring to a GUI app that the user launches from the Finder, right?
Is your networking being done by your main app’s process? Or does it spawn child processes for its networking?

How do we get this addressed?

There are basically two paths forward here:

You can file a bug without doing any investigation.
You can try to isolate the issue at your end.

My experience is that the latter gets more traction than the former. A generic “my app fails with local network privacy” bug tends to get grouped with all the other “my app fails with local network privacy” bugs. OTOH, a bug like “local network privacy fails with this specific sequence of events, oh and here’s the source code for a test app to reproduce it” is more effective.

For an example of the latter, consider the conversation I’m having with another developer in this thread.

But, honestly, it’s up to you. Isolating a problem like this can take time, and you get to decide whether the potential benefits of that are worth your time.

Oh, and speaking of benefits, I should note that such investigations don’t always lead to bug reports. Many of the local network privacy problems that I help developers with get resolved by them changing their code.

If you do decide to go down the bug report path, see Bug Reporting: How and Why? for lots of hints and tips on that front. And please do post your bug number here, just for the record.

We get this complaint regularly from Apple employees who use our products.

Did any of them file bugs about this? If so, what were the bug numbers?

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

[1] This is a common cause of problems like this. We talk about this in TN3179 and I go into more details in my Extra-ordinary Networking > Broadcasts and Multicasts, Hints and Tips post.

0