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

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.

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

That’s correct.

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

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.

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