peer-to-peer networking for iOS, iPadOS, watchOS, tvOS

Our product (rockhawk.ca) uses the Multipeer Connectivity framework for peer-to-peer communication between multiple iOS/iPadOS devices. My understanding is that MC framework communicates via three methods: 1) infrastructure wifi (i.e. multiple iOS/iPadOS devices are connected to the same wifi network), 2) peer-to-peer wifi, or 3) Bluetooth. In my experience, I don't believe I've seen MC use Bluetooth. With wifi turned off on the devices, and Bluetooth turned on, no connection is established. With wifi on and Bluetooth off, MC works and I presume either infrastructure wifi (if available) or peer-to-peer wifi are used.

I'm trying to overcome two issues:

  1. Over time (since iOS 9.x), the radio transmit strength for MC over peer-to-peer wifi has decreased to the point that range is unacceptable for our use case. We need at least 150 feet range.

  2. We would like to extend this support to watchOS and the MC framework is not available.

Regarding #1, I'd like to confirm that if infrastructure wifi is available, MC uses it. If infrastructure wifi is not available, MC uses peer-to-peer wifi. If this is true, then we can assure our customers that if infrastructure wifi is available at the venue, then with all devices connected to it, range will be adequate.

If infrastructure wifi is not available at the venue, perhaps a mobile wifi router (battery operated) could be set up, devices connected to it, then range would be adequate. We are about to test this. Reasonable?

Can we be assured that if infrastructure wifi is available, MC uses it?

Regarding #2, given we are targeting minimum watchOS 7.0, would the available networking APIs and frameworks be adequate to implement our own equivalent of the MC framework so our app on iOS/iPadOS and watchOS devices could communicate? How much work? Where would I start? I'm new to implementing networking but experienced in using the MC framework. I'm assuming that I would write the networking code to use infrastructure wifi to achieve acceptable range.

Many thanks!

Tim

Answered by DTS Engineer in 814832022
Written by Tim764 in 769043021
My understanding is that MC framework communicates via three methods

Nope. Multipeer Connectivity hasn’t used Bluetooth since… gosh… I think it was iOS 11.

Written by Tim764 in 769043021
Regarding #1, I'd like to confirm that if infrastructure wifi is available, MC uses it.

That’s correct.

Written by Tim764 in 769043021
Regarding #2, given we are targeting minimum watchOS 7.0

Multipeer Connectivity is not available on watchOS.

As to what you can do about that, I see two key questions:

  • How do you implement the equivalent of Multipeer Connectivity?

  • Will that actually help on watchOS?


Lemme tackle the second one first. Have you read TN3135 Low-level networking on watchOS? Any Multipeer Connectivity replacement would necessarily use low-level networking APIs, and thus would be affected by this.

Beyond that, I’m not actually sure if peer-to-peer Wi-Fi is available on watchOS. I’ve never had anyone ask about this because the previous point rules out most use cases for it.


As to how you’d replace Multipeer Connectivity, I wanna be clear that it’s worth doing that regardless of watchOS. Multipeer Connectivity has significant performance and reliability problems and, while I can’t predict the future with 100% accuracy, the fact that we haven’t fixed them in the last N years should tell you something.

TN3151 Choosing the right networking API touches on this topic. The best approach to replace Multipeer Connectivity depends on which of its features you’re using. For example, I find that a lot of developers naturally gravitate towards the client/server networking model. That’s not well supported by Multipeer Connectivity, but it is well supported by Network framework. So, if you’re current product uses a client/server architecture, you might find that Network framework is easier.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

Written by Tim764 in 769043021
My understanding is that MC framework communicates via three methods

Nope. Multipeer Connectivity hasn’t used Bluetooth since… gosh… I think it was iOS 11.

Written by Tim764 in 769043021
Regarding #1, I'd like to confirm that if infrastructure wifi is available, MC uses it.

That’s correct.

Written by Tim764 in 769043021
Regarding #2, given we are targeting minimum watchOS 7.0

Multipeer Connectivity is not available on watchOS.

As to what you can do about that, I see two key questions:

  • How do you implement the equivalent of Multipeer Connectivity?

  • Will that actually help on watchOS?


Lemme tackle the second one first. Have you read TN3135 Low-level networking on watchOS? Any Multipeer Connectivity replacement would necessarily use low-level networking APIs, and thus would be affected by this.

Beyond that, I’m not actually sure if peer-to-peer Wi-Fi is available on watchOS. I’ve never had anyone ask about this because the previous point rules out most use cases for it.


As to how you’d replace Multipeer Connectivity, I wanna be clear that it’s worth doing that regardless of watchOS. Multipeer Connectivity has significant performance and reliability problems and, while I can’t predict the future with 100% accuracy, the fact that we haven’t fixed them in the last N years should tell you something.

TN3151 Choosing the right networking API touches on this topic. The best approach to replace Multipeer Connectivity depends on which of its features you’re using. For example, I find that a lot of developers naturally gravitate towards the client/server networking model. That’s not well supported by Multipeer Connectivity, but it is well supported by Network framework. So, if you’re current product uses a client/server architecture, you might find that Network framework is easier.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

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

Accepted Answer
Written by Tim764 in 815334022
Reasonable?

Yes.

I’d add one more thing to the list: If the user plans to deploy infrastructure Wi-Fi, give them the option to disable peer-to-peer Wi-Fi in your app. That’ll help in a couple of ways:

  • Peer-to-peer Wi-Fi can degrade the performance of infrastructure Wi-Fi.

  • If you leave peer-to-peer enabled, it makes it hard to debug things.

Let’s say the user’s infrastructure Wi-Fi is borked [1]. If you let them disable peer-to-peer then they’ll discover that and fix it. If you leave peer-to-peer enabled, things more work, but work badly. That’s much harder to debug.

In Network framework you have to opt in to peer-to-peer Wi-Fi via the includePeerToPeer property, and that makes it easy to also opt out.

Written by Tim764 in 815334022
Any helpful resources for implementing a Multipeer Connectivity replacement using low-level networking APIs?

If you already use a client/server model then this’ll all be very familiar. On your server, use NWListener to advertise your service. On your client, use NWBrowser to find it and NWConnection to connect to it.

If you’re coming from Multipeer Connectivity then the biggest gotcha relates to framing. In Network framework you typically use TCP and that’s a stream protocol. To send messages over that, you need some sort of framing. I generally use WebSocket for that, because it’s available and easy.

You can also do your own framing, but IMO that only makes sense if you have to interoperate with an existing implementation that prescribes that framing.

Share and Enjoy

Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] A common issue here is APs that disable multicast or even STA-to-STA messaging. See Wi-Fi Fundamentals for more on this stuff.

More thanks to you Quinn. Very helpful.

Tim

peer-to-peer networking for iOS, iPadOS, watchOS, tvOS
 
 
Q