Multipeer Communication via Bluetooth Only

Multipeer Connectivity hasn’t worked over Bluetooth for 10-ish years. On modern systems its peer-to-peer support is based entirely on peer-to-peer Wi-Fi.

Historically, Multipeer Connectivity wasn’t the only option for accessing peer-to-peer Bluetooth. Even after peer-to-peer Bluetooth was no longer enabled by default, you could still access it via lower-level APIs or an explicit opt in [1]. However, that’s not been the case for a long while also. At some point we disabled the opt in [2] and eventually we removed the implementation entirely.

My general advice is that you:

• Not use Multipeer Connectivity at all. See Moving from Multipeer Connectivity to Network Framework
• Forget about peer-to-peer Bluetooth, and rely on either peer-to-peer Wi-Fi or Wi-Fi Aware.

However, I wanted to address your case specifically:

We have a requirement for device-to-device communication … without requiring Wi-Fi connectivity.

What’s the rationale for the prohibition of Wi-Fi?

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

[1] Hence Bonjour over Bluetooth on iOS 5 and Later.

[2] In iOS 11 and later, the includesPeerToPeer property on NSNetService will only opt you in to peer-to-peer Wi-Fi.

Thank you for the quick response and for sharing the link—it's been very helpful.

Rationale for the prohibition of Wi-Fi : There is a need to support peer-to-peer communication between iOS devices in a closed environment without cellular service, relying on a satellite-based Wi-Fi connection that is intermittent and unreliable.

Assuming the necessary traffic (RFC 6762) properly configured, my understanding is that proposed peer-to-peer communication using the Network framework (or using Multipeer connectivity framework) would be able to maintain connections between devices when:

• Devices are connected to the same Wi-Fi network
• The Wi-Fi network itself has no internet connectivity
• Devices can only communicate locally via the Wi-Fi access point

And Bluetooth communication would not be necessary to meet this.

Could you please confirm this understanding? Also, considering above scenario, would a WebSocket-based connection be sufficient compared to a peer-to-peer Wi-Fi solution?

Also appreciate if you could share sample codes(if available) using the Network framework for better understanding of end to end configurations.

Thank you.

Could you please confirm this understanding?

That sounds right. Peer-to-peer Wi-Fi works in all of the following scenarios:

• If both devices are on the same infrastructure Wi-Fi network.
• If the two devices are on different infrastructure Wi-Fi networks.
• If neither device is on an infrastructure Wi-Fi network.
• Any combination of the above.

But, yeah, I recommend that you create a tiny prototype and test this in your specific environment, because it certainly sounds weirder than most (-:

would a WebSocket-based connection be sufficient compared to a peer-to-peer Wi-Fi solution?

That question doesn’t make sense. Peer-to-peer Wi-Fi supports TCP connections [1] and WebSocket runs over TCP. So these don’t stand in opposition. You can use WebSocket over any TCP connection. If you set up a TCP connection over peer-to-peer Wi-Fi, WebSocket will run over it just fine.

Oh, and this combination is directly supported by Network framework. It requires a bit of fiddling to make it all work, but it’s a great option in general [2].

Also appreciate if you could share sample codes

Network framework has three different APIs, and the best option depends on two factors:

• Your language choice — Are you using Swift? Or a C-based language?
• Your deployment target — Specifically, xOS 26 is the key inflection point here. If that’s your minimum deployment target, you can use the shiny new NetworkConnection API [4].

If you reply back with that info, I should be able to point you in the right direction.

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

[1] It’s not actually limited to just TCP, but the mechanics get tricky when you start talking about other TCP/IP protocols and it doesn’t matter for this case because WebSocket uses TCP.

[2] Indeed, WebSocket is one of my preferred protocols in situations like this. It supports framing out of the box, which is a pain to do otherwise [3]. Its main ‘competitor’ is QUIC, but QUIC comes with a whole bunch of additional complexity.

[3] Unless you’re able to raise your deployment target to xOS 26, where you can use the TLV support in the new NetworkConnection API [4].

[4] See WWDC 2025 Session 250 Use structured concurrency with Network framework for more on that.