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

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"

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?

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"

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

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

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.

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"

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?

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"

I have been struggling with the same Local Network permission issue and developed the same toggling work around. This has been an issue for machines with frequent reboots.

I now have a small (>250 line) Obj-C Xcode project that will show the issue. This is a bare bones app that tries to make a TCP connection to a given IP address and port.

The first time the app runs, it asks for Local Network permission. It can connect once this permission is granted.

After a reboot, I can demonstrate this connection failing repeatedly until the Local Network permission for the app is toggled off and then back on.

I've also noticed this behavior with a third party app, Packet Sender.

I now have a small (>250 line) Obj-C Xcode project that will show the issue.

OK. And you’re signing it with a stable code-signing identity, right? So not unsigned or Sign to Run Locally, but rather Apple Developer or Developer ID Application.

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

Hello Quinn,

Thank you for the prompt response.

Here is a link to the github repo: https://github.com/James-L-Taylor/NetworkIssueTest/

The documentation folder has a zipped and unzipped version of the .app, along with a screen capture showing the problem and the current signing of the app.

Thanks, James

I ran your program and didn’t see anything weird, at least on the local network privacy front. Specifically:

1. I open the project with Xcode 26.1.
2. In Signing & Capabilities I chose my individual test team.
3. I tweaked the default IP address and port to match a server on my local network.
4. I built the project.
5. And copied the resulting app to a VM running macOS 26.1. Its network interface is in bridged mode, so it’s effectively on my local network.
6. In the VM, I moved the app to Applications.
7. And launched it from the Finder.
8. I clicked Test Connection. It prompted for local network access, which I allowed. It was able to connect.
9. I clicked Test Connection again, just to make sure it’s still working.
10. I restarted the VM.
11. I launched the app and clicked Test Connection. It continued to work.

I see various possibilities here:

• It’s possible that something is borked on your specific test machine. I recommend that you re-test on a VM, as described above. (As mentioned in TN3179, VMs are a good way to test this stuff because you can restore to a fresh snapshot between each test.)
• It’s possible that this problem only shows up on a specific OS release. AFAICT you haven’t shared your OS version here, or in your GitHub project. If you reply here with that info, I’d be happy to repeat my tests on a VM running that version.
• Your app has a non-standard structure, resulting in it showing no menu bar. It’s possible that this is a factor somehow. I recommend that you put the same code in a more standard structure, ideally one based on Xcode’s macOS > App template, and then retest. It’ll be interesting to see if that has an effect.

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