To add some more information. I'm using AsyncUdpSocket. This is just for binding to a port and receiving UDP. I'm not broadcasting nor is this multicasting. The last time this stopped working was in iOS 11.4 I believe. With that particular incident it appeared to be a bug within the update since the next patch resolved the issue. From reading I can see Apple has added in a Local Network Privacy. I don't believe this is the same however I did add the Privacy Local Network to the plist along with description to see. This however seemed to have no affect. Walking through the code it looks as if the UDPSocket is being bound without error however the on udpsocket is never being fired when receiving data. I have verified that data is being sent to the correct port in which it is bound.

I resolved this issue. This app has been around for sometime. Some pieces that have been working have not been moved forward as I would like unfortunately. Upon moving the target version to iOS 12, I started receiving the binding error. My initial thought was not understanding the lengths of the Privacy Local Network and that it may be affecting this. This was not the case. If others come across this issue wondering this, the additions of Privacy Local Network in iOS 14 did not affect me in just receiving UDP messages.

The issue was the Local Privacy Network dialog not showing. I was a bit unclear on this. I didn't believe this was needed to receive UDP but in our case it seems it is required. This is using the CocoaAsyncSocket library GCDAsyncUdpSocket. We discovered this when a gentleman was testing on a local host. The app uses both tcp/ip for some communication and udp for external gps. The tcp/ip communication on the local network triggered the dialog I believe since it does have outgoing messaging. When accepting the UDP receive started working. I did see there was a bug that is noted that only outgoing messaging on the local network will trigger the local privacy network dialog. To resolve we just access the local hostname which triggers the dialog. I have not delved into the GCDAsyncUdpSocket library nor a network expert by any means. We are binding to a specific known port to listen. It is possible that this is maybe something underlining within the library we are using. This may not be a thing with NSConnection. I do agree with tts320 that maybe just binding to the port should trigger this dialog as well. It seems everything but the receive on unicast requires it. Also I didn't see a good way, similar to internal GPS, when the dialog appears handling a callback to know exactly if it was authorized or not. This may be different with NWConnection. I have not looked at that completely and is something we may move to in the future but currently just need it to work. Thank you for your help and comments with this.