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