Local Network permission on macOS 15 macOS 26: multicast behaves inconsistently and regularly drops

First up, please understand that I’m not claiming that local network privacy (LNP) is bug free. I’ve seen enough reports like this to understand that there are real issues in play, especially on the Mac where the platform’s greater flexibility makes LNP’s job much harder. However, my experience is that it’s difficult for LNP bugs to get traction unless they come with strong evidence, and ideally a reliable set of steps to reproduce. And that’s going to be the focus of my response here.

It also means I’m gonna start with the first pathology, primarily so that I can be sure that we’re aligned when it comes to testing.

You wrote:

• On a clean install of macOS Tahoe (our test setup used macOS 26.0.1 on a Mac mini M2 8GB), we upload the app (version 5.1).
• We run the app, make sure the selected NIC is the proper one, and open the multicast socket. The app asks us to allow Local Network, we allow it.

The first divergence I see is at this step. I don’t have your accessory on my network so no local traffic is generated, so there’s no local network alert. I’ll explain how I got around this below.

The alert shows a different Local Network Usage Description than the one we set in our project's plist.

I don’t understand how that’s possible if this is a “clean install” of macOS. Where could it possible get a different usage string?

Lemme walk you through what I did today:

1. I reverted a macOS 26.1 VM to a clean snapshot, one that’s never seen your app previously.

2. I downloaded FM Mac App Test 5.1.zip to the VM in a way that sets quarantine.

   Note For those following along at home, I got VictorPetitjean’s test setup via a separate channel.

3. I unpacked it using the Finder.

4. And moved it to the Applications folder.

5. And launched it.

6. The system presented the Gatekeeper alert. I clicked Open to run the app.

7. In the app, I checked that en0 was selected in the popup (in a VM there’s not much choice :-).

8. And enabled “Also send packets with ID”. This is my way to force the local network alert.

9. And clicked “Start socket”.

10. The system presented this local network alert:

    Allow “FM Mac App Test 5.1” to 
    find devices on local networks?
    
    The purpose of this test app is to 
    use the Local Network, please allow it!
    
    [Don’t Allow] [Allow]
    

    I clicked Allow.

11. I clicked “Start socket” again.

12. Now I see the “RECEIVED CONSOLE” field fill in and also packets on the ‘wire’.

13. I clicked “Stop socket”.

14. I quit the app.

15. I restarted the Mac.

16. I launched the app again.

17. I repeated steps 7 through 9. I didn’t get a second local network alert — so no repeat of step 10 — and I saw the “RECEIVED CONSOLE” field fill in and packets on the ‘wire’.

So, all of this looks correct to me. Are you able to retry those steps yourself? If so, do you see the same results?

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

Thank you for your detailed answer. I reproduced your steps and see different outcomes. Let me answer your first two questions and then describe how I reproduced your steps and where I see differences.

Answers

The first divergence I see is at this step. I don’t have your accessory on my network so no local traffic is generated, so there’s no local network alert

Indeed that checkbox makes the app itself send similar data than our hardware, using multicast.

I don’t understand how that’s possible if this is a “clean install” of macOS. Where could it possible get a different usage string?

I should have been clearer. It shows the string "This will allow the app to discover, connect to and collect data from devices on your network." which we did not set ourselves. I could not figure out if it comes from an other app, or if it's the default usage description.

Reproduction steps

Here's a Dropbox link to our app (zipped): https://www.dropbox.com/scl/fi/btnpz64u8rz7y7t0dicbu/FM-Mac-App-Test-5.1.zip?rlkey=8g43pvph7qrld12hp3r6u6yt6&dl=1

1. Instead of your 26.1 VM, I have a clean install of 26.0.1 on a Mac mini (M2, 2023).
2. I airdrop FM Mac App Test 5.1.zip.
3. I unzip it using Finder, move the app to Applications and launch it.
4. I get this Gatekeeper/Airdop warning. I click Open.

"FM Mac App Test 5.1" is an app
sent over AirDrop. Are you sure
you want to open it?

You received this file today at 11:16.
Apple checked it for malicious software
and none was detected.

Cancel / Open

1. The app starts. I check "Also send packets" and start the socket.
2. The Local Network alert presented is here different than yours. It uses this Local Network Usage Description, not the string we set ourselves:

Allow "FM Mac App Test" to find
devices on local networks?

This will allow the app to discover,
connect to and collect data from
devices on your network.

Don't Allow / Allow

1. Packets are received. I close the app, verify that the app shows in the Settings > Privacy > Local Network list, and restart the Mac.
2. After restart, the app does not show in the Settings > Privacy list anymore.
3. I do step 5 again, and get the alert once again, same as step 6, also with the unknown Local Network Usage Description.
4. From that moment on, the app has permanent Local Network access, even after reboots.

The 3 main differences in my setup are the macOS version (26.0.1 vs 26.1), the physical machine, and the Gatekeeper alert. I then removed those differences one by one:

• I tried a 26.0.1 VM, transferring the file directly from my local files (it did not trigger Gatekeeper): same outcomes
• I tried a 26.2 VM, same transfer method: same outcomes
• I tried a 26.2 VM, this time downloading the app from the Dropbox link, to trigger the Gatekeep alert: same outcomes

I think I now reproduce the exact same steps as you: VM, macOS 26.0 or 26.2, Gatekeeper alert. Yet the Local Network alert shows the wrong usage description and the app disappears from the Privacy list after reboot.

Are you seeing something I do different than you?

And do you know if the usage description "This will allow the app to discover, connect to and collect data from devices on your network." is the default string, or from a specific app?

Herewith an update from us on the Local Network Privacy issues that we and our users are experiencing.

Over the past period we have done many tests with various combinations of machines and OS'es.

Long story short

Local Network Security settings seem to behave different between applications that have been either Downloaded, AirDropped or tranferred over a USB Drive. Airdropping the application to the machine gives the expected behavior. Installing the application by downloading it or by installing it over a USB drive gives broken behavior for Local Network Access. Deleting the application and then Airdropping the Application can fix the behavior. Having multiple versions of the same application on the machine breaks Local Network Access.

Airdropping gives an additional warning on first launch, so could this be Gatekeeper related?

Reproduction

These are the steps where you would be able to recreate the issue, we've done this multiple times on multiple different machines on multiple OS versions. The latest OS tested was 26.2. We did not see differences between OS versions.

Issues with Local Network after reboot

Preconditions for this test:

• Have two fresh installed dedicated mac machines attached to a network switch
• Have a USB key that contains multiple versions of our test application

To generate proper multicast traffic on the physical network from machine 1:

• Make sure that WiFi is disabled
• Give the machine a static IP on its physical network interface
• Launch our Test App
• Select the proper interface to output the multicast packets onto
• Make sure it will be sending packets by clicking the bottom checkbox (Also send packets with ID...)
• Click on Start Socket to activate traffic on the network

This machine is now generating the multicast network traffic that you will be receiving on machine 2.

To replicate the issues that we are experiencing on machine 2:

• Start from a clean reset machine. We used Tahoe 26.2 in our latest tests
• Turn off wifi
• Open network settings and set a static IP for the network interface
• Transfer zipped Test app v5.1 from USB drive to Desktop, unzip it and run it
• Start socket. App asks for Local Network permission
• Validate that multicast is received
• Quit the application
• Reboot the mac
• Run the app again. Multicast is NOT received, no matter how many times we stop and start the socket
• Go to the settings and toggle off and on the Local Network permission of the app
• The app can now receive our multicast traffic again. Until the next reboot…

Both downloading as well as USB tranfer lead to the same result, initially it works, until you reboot.

To make this machine work proper again:

• Delete the installed application
• Empty the trash to make sure it is fully removed from the machine
• Enable WiFi
• Airdrop the exact same application version as previously used
• Disable WiFi
• Unzip and launch the Application, Gatekeeper will ask: Are you sure?
• Start socket. App asks for Local Network permission
• Validate that Consoles are received
• Quit the application
• Reboot the mac
• Run the app again. Multicast should now be received again and again after reboots, without asking again for permission

The above test results make it seem like Gatekeeper is having a special influence on the Application when Airdrop is being used. Does Gatekeeper set special attributes after the Airdropping of the App or after the initial launch question message?

Multiple versions of the same app

Then the next subject: Local Network Access while having multiple versions of the same application installed or present on the machine.

Preconditions:

• The two proper working machines from above with Test App 5.1 installed on both

To replicate the issues that we are experiencing on machine 2:

• Validate that v5.1 is installed and works as expected, also after reboots
• Enable WiFi
• Airdrop application V5.2
• Disable WiFi
• Unzip and launch the Application
• Start socket. App might ask for Local Network permission, sometimes it does not do this
• Validate that multicast is received in the 5.2 app
• Quit the application
• validate that in the privacy Local Network list there is still only one entry
• Now launch app v5.1 (the earlier installed version)
• This v5.1 app will ask permission for local network while it mentions the name of the v5.2 app in the message?! See also attached screenshot.
• The privacy Local Network list will now contain an extra entry in the list of applications
• Now quit the v5.1 app
• Launch v5.1 again
• Again it will ask for Local Network permissions (while mentioning v5.2 in the message)
• Again an extra entry will be present in the Privacy Local Network settings list.
• This keeps going on and on

To completely break Local Network access install an additional app version: Test App 5.3. On our machine the Privacy Local Network access list got confused and started displaying unrelated application names for the entries in the list.

On a machine with a broken state, deleting all but one version fixes Local Network (as long as the remaining version was airdropped)

Additional USB-C network interfaces

Next to this there seems to be another influence, we just got informed by our team that adding additional network interfaces seems to have an influence on the Local Network Privacy issue too.

When we have a machine in working condition it will get issues after adding additional network interfaces over USB-C. The Local Network Privacy list will need to be toggled off and then On again to make the application work after a reboot.

Last remark

We hope that all of the above makes sense and we hope you and your team will be able to recreate this behaviour with a dedicated test setup. We will follow up by email with the mentioned attachments. Thank you for your help

Thanks for the update. I’m gonna focus on your first set of steps, “Issues with Local Network after reboot”, because that’s the one I really want to nail down.

Unfortunately, I fell at the first hurdle )-: To run this test I need a copy of your test app, and the download link you posted above no longer works. Can you post an updated link?

Ideally that’d include both a built app that you reproduced the problem with and the project that you used to built the app, but either should be sufficient for me to run your test here.

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

Hi Quinn,

Just want to check in with you on how things are going. Did you and your team get the examples and test apps running, from our last email? Did you see behaviour similar to what we have been experiencing?

Let us know if there is anything we can do from our side to help fixing this. We appreciate your help on this.

Kind regards, Victor and team

Sorry it’s taken a while to get back to you here. I finally got a few hours to work on this on Friday, and then that all got eaten with setting up the test environment [1]. But then today was more relaxed than the usual Monday, so I’m back looking at your stuff again.

Testing with dedicate hardware is a challenge, so I started by trying to reproduce the problem in a VM. I set up two VMs, matching your machine 1 and machine 2. Both virtual machines were set up with bridged networking, so they can see each other’s multicasts. The details of machine 1 aren’t really relevant, because all it needs to do is send multicasts. On machine 2 I installed macOS 26.2.

My rationale here was that using VMs for this was much easier, and if I could reproduce the problem with them that’d be great. And if not, I would have to invest more the time in setting up real hardware.

The results were… frankly… confusing. I left machine 1 running all the time, happily sending its multicasts. My test loop was:

1. Clone machine 2 to run a test.
2. Boot it.
3. Use scp to copy your test app to it.
4. Run the test.
5. Shut it down.
6. Go back to step 1.

This usually results in reproducible behaviour. In this case, however, things got weird. The first time I tried this I wasn’t able to reproduce the problem. I tweaked my steps a little and then I saw the problem. I then starting running more tests to see what the critical factor was, trying to find a single step that was the difference between working and not working. Everything I tried caused the problem to go away. So I went back to the steps that reproduced the problem and it didn’t reproduce any more. Wha!?!

At this point I’m confused. It’s not just that I can’t reproduce the problem. That’s just a fact of life in my job. Rather, there something missing in my understanding of the factors that affect reproducibility.

And just as I was about to post this, I reproduced the problem again! I’ve run out of time to explore this further today — meetings to go to — but at least I know that the first time I saw this wasn’t a complete fluke.

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

[1] Which doesn’t exactly match yours, so this should’ve been easy, but it wasn’t. *sigh*

We get that feeling of lack of reproducibility, or more precisely the heavy dependence on initial factors. For example, realizing the transfer method of an app had an impact on how well it would receive multicast traffic was fascinating! And even then, it doesn't seem the only factor: number of versions on the system, number of reboots, additional network dongles... all seem to somehow influence results.

Thanks for your work, let's hope we can find patterns

I’ve been looking at this again today. I can definitely reproduce it but, yeah, it’s weird. I’m gonna have you file a bug about this, but before we go there I want to share and compare some experiences.

Your instructions indicating that you were running the app from the desktop. That’s a bit weird, and I originally thought that it might be a factor. AFAICT it is not. I was able to reproduce the problem when running the app from my Applications folder and my home directory.

I originally thought that this might be timing related. That is, it was triggered by me running the app immediately after a restart. However, my tests today suggest that it’s not, or at least not related in that way. Specifically, I started waiting for about 10 seconds between when the Finder shows up and when I launch the test app, and I can still reproduce the problem.

I’m still suspicious that it might be related to the time between when I launch the app and when I start the multicast receiver, but I haven’t spend the time to test that.

Your tests suggest that you can reproduce the problem quite reliably. That’s not the case for me. Consider this loop:

1. Restart the Mac.
2. Start the multicast receive. This results in either an OK or NG result.
3. Stop the receive.
4. Quit the app.
5. Go back to step 1.

I’ve seen sequences like NG > OK > NG > NG > OK > NG, where it happens roughly half the time. But I’ve also seen ones like OK > OK > OK > OK > OK > NG, where I have to restart a bunch of times to trigger it.

IMPORTANT This is a very different test than the one I was running yesterday, where I was starting with a clean VM at each cycle. Here I’m just restarting the same VM over and over again, and the problem comes and goes.

When I hit the problem, stopping and starting the multicast receiver doesn’t cure it. Neither does quitting and relaunching the app. As you reported, toggling Privacy & Security > Local Network does fix the problem, although I do have to stop and start the multicase receiver as well. But that’s not a permanent fix; the problem will eventually come back after enough restarts.

To further isolate this problem I wrote my own test app that sends and receives multicasts. I did this to assure myself that there’s nothing in your code that triggering this. And, lo!, my test app also reproduces the problem.

Specifically, here’s what I did today:

1. I ran my test app in send mode on my main Mac. It’s running macOS 26.2, but as I’m using this as the sender that’s not really relevant.
2. I started the sender in the test app.
3. I started a ‘clean’ macOS 26.2 VM, with bridged networking.
4. I used SSH to copy my test app to the guest.
5. On the guest, I starting the receiver so as to trigger the local network alert.
6. I stopped the receiver, quit the app, and started running the test loop that I described above. After each restart, there’s some probability that I’ll see the problems.

So, I can reproduce the problem with some degree of reliability with only Apple stuff. Clearly this is a bug, and I think it’s time to get it into Radar.

I’m going to have you file your own bug report for this. That way you can describe your test setup in your own words, and you’ll also be notified of any updates. Once you’ve done that, post the bug number here and I’ll my own experience to it [1].

In your bug:

• Attach a sysdiagnose taken shortly after reproducing the problem. This helps ensure that the bug makes it to the right team.
• Include a link to this forums thread.

For lots of other hints and tips on filing bugs effectively, see Bug Reporting: How and Why?

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

[1] Just to set expectations, those will be internal comments that you won’t be able to see.

We just filed two related Feedback Assistant reports:

• FB21858319 (After macOS reboots, multicast traffic might not be received by app even with Local Network permitted): that's the one you should be interested in, this is the issue you could reproduce

• FB21858436 (Several versions of an app show as several instances in Settings > Privacy > Local Network. They all toggle as one, and affect only one version of the app.): we also described it in this thread

Thanks for you help. We're still curious as to why you cannot reproduce the issue consistently, while on my setup any reboot breaks Local Network. Issue might be very sensitive to initial conditions. Let's hope the right team can figure out the proper patterns, we really hope to find either a fix soon (or at least a practical, user-friendly workaround, to help our users).

Thanks! Victor & Team