Local Network permission appears to be ignored after reboot, even though it was granted

Question

Created Jul ’25

Replies 9

Boosts 0

Participants 3

We have a Java application built for macOS. On the first launch, the application prompts the user to allow local network access. We've correctly added the NSLocalNetworkUsageDescription key to the Info.plist, and the provided description appears in the system prompt.

After the user grants permission, the application can successfully connect to a local server using its hostname. However, the issue arises after the system is rebooted. When the application is launched again, macOS does not prompt for local network access a second time—which is expected, as the permission was already granted.

Despite this, the application is unable to connect to the local server. It appears the previously granted permission is being ignored after a reboot. A temporary workaround is to manually toggle the Local Network permission off and back on via System Settings > Privacy & Security, which restores connectivity—until the next reboot.

This behavior is highly disruptive, both for us and for a significant number of our users. We can reproduce this on multiple systems...

The issues started from macOS Sequoia 15.0

By opening the application bundle using "Show Package Contents," we can launch the application via "JavaAppLauncher" without any issues. Once started, the application is able to connect to our server over the local network. This seems to bypass the granted permissions? "JavaAppLauncher" is also been used in our Info.plist file

Answered by DTS Engineer in 850070022

Cool.

We regularly find and fix local network privacy problems [1]. It’s possible that this is what you’re seeing here. It’s also possible that you perturbed the system enough that the bug was masked. As the old saying goes: Bugs that mysteriously disappear can mysteriously reappear (-:

Still, it does put the kibosh on debugging this right now. But if you see it come back, please reply back on this thread.

Oh, and you should definitely test on the macOS 15.6 release candidate that we’re currently seeding. It contains at least one important local network privacy fix.

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

[1] Sometimes we introduce new ones too, which makes me sad )-:

Boost

Answer 1

DTS Engineer OP

Apple

Jul ’25

If you try something similar with a test project you build in Xcode, does it have the same problem?

IMPORTANT Make sure to sign your app with a stable code signing identity, such as an Apple Development identity. If you choose Sign to Run Locally, the system won’t be able to track the identity of your properly. For more about this, see TN3127 Inside Code Signing: Requirements.

This is relevant because:

If the test project works correctly, this is probably related to the way your Java app is packaged or signed.
If the test project exhibits the same failure, that suggests an environmental issue.

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

0

Answer 2

Dieter_C OP

Jul ’25

With a test project do you mean to strip the complete java application and keep only the part that is not working and build it in Xcode?

0

Answer 3

DTS Engineer OP

Apple

Jul ’25

Nope. I’m suggesting you create a new test project, with no Java code, that does some local networking. That’ll tell you whether you have an environmental issue (that is, local network privacy is just broken on your Mac for some reason) or a code issue (that is, the issue is specific to your Java app).

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

0

Answer 4

Dieter_C OP

Jul ’25

Out of curiosity, I installed macOS Tahoe 26 Beta 3 and tested the application, it appears to be working without any issues.

0

Answer 5

DTS Engineer OP

Apple

Jul ’25

Recommended

Cool.

We regularly find and fix local network privacy problems [1]. It’s possible that this is what you’re seeing here. It’s also possible that you perturbed the system enough that the bug was masked. As the old saying goes: Bugs that mysteriously disappear can mysteriously reappear (-:

Still, it does put the kibosh on debugging this right now. But if you see it come back, please reply back on this thread.

Oh, and you should definitely test on the macOS 15.6 release candidate that we’re currently seeding. It contains at least one important local network privacy fix.

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

[1] Sometimes we introduce new ones too, which makes me sad )-:

0

Answer 6

jaikiran OP

Jul ’25

Hello Quinn,

Oh, and you should definitely test on the macOS 15.6 release candidate that we’re currently seeding. It contains at least one important local network privacy fix.

Would it be possible to tell a bit more of that fix in 15.6 release candidate? We had numerous issues in 15.x releases related to local network privacy (some of which I've raised in these forums previously). There weren't any solutions we could come up with for these problems because the local network privacy configuration couldn't be automated (on test machines). So we had to temporarily disable several tests that were running into issues local network privacy issues. If there's some specific fix in this area, then I would like to try it out on a separate system and see if it helps us in some manner.

0

Answer 7

DTS Engineer OP

Apple

Jul ’25

Would it be possible to tell a bit more of that fix in 15.6 release candidate?

I don’t have a complete list. The two that I’m specifically tracking are:

The FB14321888 bug mentioned in the latest update to TN3179 Understanding local network privacy. That’s an iOS bug but, as iOS and macOS share a lot of code, and the bug is super gnarly, I think it’s better to be safe than sorry.
The simulator issue discussed in NWBrowser with bonjour returning PolicyDenied(-65570).

The good news here is thet 15.6 is now released, so it makes sense to switch your testing over to it.

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

0

Answer 8

Dieter_C OP

Aug ’25

We were also able to break it on macOS Tahoe Beta 3. We noticed that we were reusing the JavaAppLauncher over and over again for all our versions so the same uuid for all versions, which should be unique according to TN3179: Understanding local network privacy | Apple Developer Documentation#Build-time-considerations.

Local network privacy uses your main executable UUID as part of its implementation. If your main executable has no UUID, or shares a UUID with other programs, local network privacy may behave weirdly.

But what else should be unique so the app will be seen as a unique application? CFBundleIdentifier? What if you install applications in de same folder will the local network privacy settings be reused?

0

Answer 9

DTS Engineer OP

Apple

Aug ’25

We were also able to break it on macOS Tahoe Beta 3.

macOS 26.0b3 does not hvae all the fixes that went into macOS 15.6. In fact, I’m not even sure that 20.6b4 has all those fixes. I recommend that you focus on macOS 15.6 for now, and then re-test on any future macOS 26 betas as and when they start seeding.

But what else should be unique so the app will be seen as a unique application?

In general, macOS identifies code via its designated requirement. TN3127 Inside Code Signing: Requirements explains this in general. Hence this advice in TN3179:

To ensure that local network privacy reliably tracks the identity of your macOS program, sign it with an Apple-issued code-signing identity.

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

0