Thanks Quinn. Our app's architecture is client/server. One iOS device (server) is connected to Bluetooth sensors and broadcasts sensor data to one or more other iOS devices (clients). We need realtime message delivery (say, <2 seconds) and a range of 150 feet.
Regarding watchOS, yes, I did look at TN3135. If high-level networking (URLSession) is inadequate for our use case (as you suggest by saying "Any Multipeer Connectivity replacement would necessarily use low-level networking APIs", then watchOS support is out and we revert to message sending between Apple Watch and the paired iPhone.
Thanks for your thoughts on Multipeer Connectivity. I'm hearing that we are wise to develop a replacement solution using low-level networking APIs. We will have more control over stability and, possibly, performance too.
In summary:
Using infrastructure wifi will address the range issue we experience when using peer-to-peer wifi of Multipeer Connectivity, assuming infrastructure wifi at the use venue has adequate coverage.
If infrastructure wifi with adequate coverage is not available at the use venue, our users can bring a mobile wifi router with adequate coverage and use that as infrastructure wifi.
Multipeer Connectivity is not getting much love at Apple, so we are best to implement a replacement using low-level networking APIs.
Message sending between Apple Watch and paired iPhone is the only practical solution for watchOS support. The paired iPhone participates in the client/server network and, in turn, refreshes the Apple Watch display as sensor data is shared on the network.
Reasonable? Any helpful resources for implementing a Multipeer Connectivity replacement using low-level networking APIs?
Many thanks!
Tim