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

App & System Services Networking
VictorPetitjean OP
Created 1w
Replies 1
Boosts 0
Views 66
Participants 2

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

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.
Replies  1
Boosts  0
Views  66
Participants  2
DTS Engineer OP
Apple
3d

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"

0
Local Network permission on macOS 15 macOS 26: multicast behaves inconsistently and regularly drops
First post date Last post date
 
 
Q