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 Instead of your 26.1 VM, I have a clean install of 26.0.1 on a Mac mini (M2, 2023). I airdrop FM Mac App Test 5.1.zip. I unzip it using Finder, move the app to Applications and launch it. 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 The app starts. I check "Also send packets" and start the socket. 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 Packets are received. I close the app, verify that the app shows in the Settings > Privacy > Local Network list, and restart the Mac. After restart, the app does not show in the Settings > Privacy list anymore. I do step 5 again, and get the alert once again, same as step 6, also with the unknown Local Network Usage Description. 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

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

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

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

Thanks for the explanation, we're glad to know you guys are onto something! We understand a fix might not be coming soon, but would you have an advice on how to make this issue happen less often? If something goes wrong with the IPC, the kernel ‘fails secure’ by denying the local network operation. Is there a way to have the IPC fail less often? By not opening the app too soon after startup, or by making sure the kernel is not too busy somehow? And caches that result, so it’s only cleared if you restart (or, as you discovered, toggle the state in System Settings). Can we "programatically" reset the cache, when our app starts and before opening the multicast sockets? I guess from TN3179 that's probably not possible though... Any workarounds would be appreciated until an actual fix is found and published

I tried the "victim app" strategy. I have 2 different apps that both require Local Network (our test app and another very different piece of software, from a different company). Both have local network permitted. At restart, whether I open app 1 or app 2, none receive multicast. Neither when I open both app one after the other, in any order. Then I go to the settings, toggle Local Network for any of the app: both start receiving multicast traffic! Doesn't matter if I toggle off/on app 1 or app 2, both start receiving. I guess this disqualifies the "victim app" strategy. Even if we would use app 2 to warm everything up as you put it, it doesn't really until the user manually toggles the privacy setting. Might as well directly toggle our main app... Thanks for the suggestion though

Hi Quinn and those following along: The just released 26.5 beta (build 25F5042g) seems to - mostly - solve FB21858319 (After macOS reboots, multicast traffic might not be received by app even with Local Network permitted), what a relief! Now after a reboot, apps directly receive Local Network traffic, no need to toggle permission off and on or restart the app. I've tested a couple of apps across many reboots, seems to behave as expected. One issue (at least) remains: when multiple versions of the app coexist on a machine, the latest installed version won't receive Local Network traffic after macOS reboot until its socket is closed and reopened. The previously installed versions receive Local Network immediately, only the latest version needs a socket restart. It's already much more stable than previously (users had to toggle off and on the Local Network permission and restart the app for traffic to appear), we can now programmatically restart the socket and we're good. This looks more related to unresolved 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.). But one step at a time!

Yes. More specifically: the latest installed copy is unable to access local network after reboot (until restarting its networking code), all other previously installed copies are ok from the start. I shared a screen recording in the feedback assistant showing this behavior

FB21858319 is now closed, new issue created in FB22434780 (When several versions of an app coexist on a machine, the latest installed version won't receive Local Network traffic after macOS reboot, until a 2nd socket is created)