Best iOS TCP API for accessories with a soft API?

I have a sensor, set up as a soft Access Point, DHCP / WPA / TCP, which sends sensing data to my iOS app. I currently use GCDAsyncSocket to manage connections. I can associate with NEHotspotConfiguration. There is no internet access involved: accessory and iOS device exchange data via Wi-Fi.


Is the Network Extension framework, specifically NEAppProxyProvider and an appEx with subclassed NEAppProxyFlow and NEAppProxyTPFlow, the preferred approach? Is there an upate to the SimpleTunnel project or a guide to the whole process (things like the App Proxy configuration, entitlements, and PLIST settings)?


Thanks in advance...

Replies

I’m not sure what you’re expected

NEAppProxyProvider
to do for you here. It’s a flavour of per-app VPN. How does that fit into your accessory integration story?

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"

Thanks for the reply Quinn. I have been doing some research and programming to state better the problem I am trying to solve.


I have an IoT sensor, an accessory, that sets up a SoftAP (WPA2, DHCP, TCP/IP) which is joined by a single iOS device. The iOS device opens a socket using GCDAsyncSocket (based on CFStream) to exchange data with the sensor. My goal is to make the TCP connection robust by using the modern networking technologies in iOS.


I have successfully used NEHotspotConfiguration to associate the iOS device with the SoftAP Wi-Fi network with a fixed IP address and channel. We are an MFi developer and manufacturer. My research suggests that the preferred MFi approach is to use Wi-Fi Accessory Configuration, Bonjour, and NSNetService to establish connections. I am also investigating what benefits Homekit offers.

My research suggests that the preferred MFi approach is to use Wi-Fi Accessory Configuration …

That depends on the expected deployment scenario for your accessory. In my experience this breaks downs into two cases:

  • You have an accessory, like a set of speakers, that you expect to be deployed in some static location that has infrastructure Wi-Fi (A)

  • You have an accessory, like a fancy video camera, where the user often wants to talk to the accessory where there’s no infrastructure Wi-Fi (B)

WAC is a massive win for case A and you should definitely do it in that case. For case B, however, the situation is more nuanced. Depending in the details a solution based on

NEHotspotConfigurationManager
might be just fine.

One option for B is to use both Core Bluetooth (Bluetooth LE) and

NEHotspotConfigurationManager
. Your app can then use Core Bluetooth to get minimal information about the accessory (like its SSID) and then use
NEHotspotConfigurationManager
to join the accessory’s network when it needs to do a high-speed transfer.

Once you get both the device and the accessory on the same Wi-Fi you need to think about how to run the communication. Here I strongly recommend Bonjour technologies:

Keep in mind that RFC 3927 is only necessary if you’re stuck on legacy IP. IPv6 supports link-local addressing out of the box, and it’s a big win for accessory integration because there’s no way to ‘break’ that link-local support.

Share and Enjoy

Quinn “The Eskimo!”
Apple Developer Relations, Developer Technical Support, Core OS/Hardware

let myEmail = "eskimo" + "1" + "@apple.com"