There is another case where the app accesses a remote internet server before joining the multicast group as described in my previous post. In this other case, a DNS request is sent via the gateway router. I have tried both cases (no DNS request and gateway router DNS request) and the problem occurs in both these cases.

Thanks very much for all your help with this. My app is a UPnP server. It creates a multicast socket that joins multicast group 239.255.255.250, which sends an IGMPv2 Membership Report message to the multicast group address 239.255.255.250. This is the first message sent to the local network. After this, the app sends an SSDP NOTIFY message to the multicast group 239.255.255.250 and waits for UDP unicast responses from other UPnP devices. There are no DNS messages sent. When local network access is disabled, the IGMPv2 Membership Report message is sent (confirmed by using Wireshark) but the NOTIFY message is blocked. There is another variation on this (UPnP client mode) where an SSDP M-SEARCH message is sent after joining the multicast group instead of sending a NOTIFY message. Again, the IGMPv2 Membership Report message is sent but the M-SEARCH message is blocked.

Thanks for your prompt reply. My application is packaged as a .app package. It is distributed independently, not on the App Store. I have tried two other apps (.app packages) that do similar things to my app. One is distributed via the App Store and works immediately after a macOS restart. The other is distributed independently and has the same issue as my app after a macOS restart. I am testing by deleting my test volume, then creating a new empty test volume and installing Sequoia from scratch in that volume. This is simpler for me than creating a VM. Following a hint in TN3179, I have also tried creating a new user account to get a "clean sheet" of local network privacy settings and I see exactly the same issue when starting my app from this new user account. I have tried running the Console app to see what is going on when the working app starts and when the failing app starts. The output from Console shows that the working app is populating a local network privacy cache when it starts, with messages like the following: default 11:14:35.343586+0000 nesessionmanager NESMPathControllerSession[com.apple.preferences.networkprivacy-773BACFE-4BF4-4F12-A349-A127ACAE3DE7:A0036093-7F67-4D6A-AB13-F90153F11724]: No UUIDs in the cache for PathRuleDefaultNonSystemIdentifier, populating the cache from the path rules default 11:14:35.343694+0000 nesessionmanager Sending a message to populate the cache with UUIDs from configuration A0036093-7F67-4D6A-AB13-F90153F11724 default 11:14:35.345021+0000 nehelper com.apple.preferences.networkprivacy-773BACFE-4BF4-4F12-A349-A127ACAE3DE7: Populating the cache with UUIDs for 8 app rules default 11:14:35.361911+0000 nehelper com.apple.preferences.networkprivacy-773BACFE-4BF4-4F12-A349-A127ACAE3DE7: Populating the cache with 1 UUID(s) for uk.co.linn.linn default 11:14:35.361993+0000 nehelper com.apple.preferences.networkprivacy-773BACFE-4BF4-4F12-A349-A127ACAE3DE7: Saving the cache default 11:14:35.473344+0000 nesessionmanager UUID cache miss for com.minimserver.server default 11:14:35.485558+0000 nehelper Caching 2 UUID(s) for com.minimserver.server default 11:14:35.487837+0000 nesessionmanager UUID: Found for com.minimserver.server: ( "D4B6F942-5D28-3D52-B279-C5766B3B0F70", "6CA3C8E4-0DBD-3B47-BD57-70CE30DB0547" ) The app uk.co.linn.linn is the app that works immediately after a macOS restart and the app com.minimserver.server is my app that does not work immediately after a macOS restart. After this cache population has happened, all apps in the Local Network section are working normally.

Thanks very much for your prompt and very helpful reply. Both apps have a native main executable, so that wasn't the issue. Your pointer to the need for a unique bundle ID led me to the cause of the problem: an error in my build script had caused the main executables in both apps to have the same bundle ID. When I fixed the build script, everythng started to work as expected.

I discovered that the Java library contains code that uses the deprecated NSUserNotification API and calls NSUserNotificationCenter setDelegate. The delegate has a shouldPresentNotification method that always returns YES. I suspect this is what is triggering the pop-up even though the app doesn't send any notifications.