Problem description
Since macOS Sequoia, our users have experienced issues with multicast traffic in our macOS app. Regularly, the app starts but cannot receive multicast, or multicast eventually stops mid-execution. The app sometimes asks again for Local Network permission, while it was already allowed so. Several versions of our app on a single machine are sometimes (but not always) shown as different instances in the System Settings > Privacy & Security > Local Network list. And when several instances are shown in that list, disabling one disables all of them, but it does not actually forbids the app from receiving multicast traffic. All of those issues are experienced by an increasing number of users after they update their system from macOS 14 to macOS 15 or 26, and many of them have reported networking issues during production-critical moments.
We haven't been able to find the root cause of those issues, so we built a simple test app, called "FM Mac App Test", that can reproduce multicast issues. This app creates a GCDAsyncUdpSocket socket to receive multicast packets from a piece of hardware we also develop, and displays a simple UI showing if such packets are received. The app is entitled with "Custom Network Protocol", is built against x86_64 and arm64, and is archived (signed and notarized). We can share the source code if requested.
Out of the many issues our main app exhibits, the test app showcases some:
- The app asks several times for Local Network permission, even after being allowed so previously. After allowing the app's Local Network and rebooting the machine, the System Settings > Privacy & Security > Local Network does not show the app, and the app asks again for Local Network access.
- The app shows a different Local Network Usage Description than in the project's plist.
- Several versions of the app appear as different instances in the Privacy list, and behave strangely. Toggling on or off one instance toggles the others. Only one version of the app seems affected by the setting, the other versions always seem to have access to Local Network even when the toggle is set to off.
- We even did see messages from different app versions in different user accounts. This seems to contradicts Apple's documentation that states user accounts have independent Privacy settings.
Can you help us understand what we are missing (in terms of build settings, entitlements, proper archiving...) so our app conforms to what macOS expects for proper Local Network behavior?
Related material
- Local Network Privacy breaks Application: this issue seemed related to ours, but the fix was to ensure different versions of the app have different UUIDs. We ensured that ourselves, to no improvement.
- Local Network FAQ
- Technote TN3179
Steps to Reproduce
Test App is developed on Xcode 15.4 (15F31d) on macOS 14.5 (23F79), and runs on macOS 26.0.1 (25A362). We can share the source code if requested.
- 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 alert shows a different Local Network Usage Description than the one we set in our project's plist.
- The app properly shows packets are received from the console on our LAN.
- We check the list in System Settings > Privacy & Security > Local Network, it includes our app properly allowed.
- We then reboot the machine. After reboot, the same list does not show the app anymore.
- We run the app, it asks again about Local Network access (still with incorrect Usage Description). We allow it again, but no console packet is received yet. Only after closing and reopening the socket are the console packets received.
- After a 2nd reboot, the System Settings > Privacy & Security > Local Network list shows correctly the app. The app seems to now run fine.
- We then upload an updated version of the same app (5.2), also built and notarized. The 2nd version is simulating when we send different versions of our main app to our users. The updated version has a different UUID than the 1st version.
- The updated version also asks for Local Network access, this time with proper Usage Description.
- A 3rd updated version of the app (5.3, also with unique UUID) behaves the same. The System Settings > Privacy & Security > Local Network list shows three instances of the app.
- We toggle off one of the app, all of them toggle off. The 1st version of the app (5.1) does not have local network access anymore, but both 2nd and 3rd versions do, while their toggle button seems off.
- We toggle on one of the app, all of them toggle on. All 3 versions have local network access.
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:
- Restart the Mac.
- Start the multicast receive. This results in either an OK or NG result.
- Stop the receive.
- Quit the app.
- 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:
- 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.
- I started the sender in the test app.
- I started a ‘clean’ macOS 26.2 VM, with bridged networking.
- I used SSH to copy my test app to the guest.
- On the guest, I starting the receiver so as to trigger the local network alert.
- 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.