It is a bound accessory. However, after it's configured and joined the local WiFi network, there will be no need for the phone to interact with it directly. It's a one and done.

Yes, that's right. And it's all working EXCEPT I am unable to receive the response back from the device. So I send it a configuration packet (#4), and I know the device get's it because it does the "configuration" thing. Before #5, the device sends back an Acknowledgement packet saying it got the configuration packet, but my receiveMessage: callback is NOT called. The device is happy though and we go to #6. BUT, if I have a 3rd party random iOS Sniffer App running at the time that I do this, MY App's receiveMessage: callback IS called. So I know that the device received my configuration packet in #4. . So the sniffer app is somehow affecting the functionality of my App. So I'm wondering if there is something that I can do differently that will cause the same effect as the sniffer App. Since the configuration of the device IS working, I can just "assume" that the device received it, but I'd like to at least try to close the handshake loop.

Perhaps I should reach out to DTS then. I have the modified sample App I can provide, but of course can't provide the actual device. Was just hoping something would "twig" with someone based on the fact that a sniffer running causes different behavior. (There's an uncertainty principle joke lurking here)

Follow up for those interested :: I switched to using URLSession.dataTask() instead of NWConnection and now I receive the response and it's all working fine. So def a problem routing back at the NWConnection level.