Multipeer Connectivity remains in .connecting state and drops connections when Mobile Data is enabled

Question

Created 5d

Replies 1

Boosts 0

Participants 2

We are using Multipeer Connectivity (MCSession, MCNearbyServiceBrowser, MCNearbyServiceAdvertiser) for nearby peer discovery and communication.

**Observed behaviour: **

When Wi-Fi is ON (Not connected to any network) and Mobile Data is also ON:

Peer discovery (foundPeer) consistently succeeds
Invitation is sent using invitePeer
MCSession transitions to .connecting
The session remains indefinitely in .connecting
connected is never reached
notConnected is also not reported

When Mobile Data is turned OFF, the same flow reliably reaches .connected.

Key details:

Both devices have Wi-Fi and Bluetooth enabled
Browsing and advertising are active on both devices
Application-level timeouts and session resets are implemented
The Issue is reproducible across multiple devices with iOS 26 versions.

Expectation / Question:

We understand that Multipeer Connectivity does not use cellular data for peer discovery or transport. However, when Wi-Fi is available and peers are discovered successfully, we would like clarification on the following:

Is it expected behavior that enabling Mobile Data can cause the invitation/connection phase to remain indefinitely in .connecting without transitioning to .notConnected?
Are there recommended best practices to avoid stalled invitation or transport negotiation in this scenario?
Is there a supported way to detect or recover from a stalled .connecting state beyond application-level timeouts and session resets?

Any guidance on expected behavior or recommended handling would be appreciated.

Boost

Answer 1

DTS Engineer OP

Apple

4d

Is it expected behavior that enabling Mobile Data can cause the invitation/connection phase to remain indefinitely in .connecting without transitioning to .notConnected?

No, that's actually pretty weird. If you haven't already, please file a bug on this and then post the bug back here.

Is there a supported way to detect or recover from a stalled .connecting state beyond application-level timeouts and session resets?

No, not really. Multipeer doesn't really give you enough visibility into what's going on to resolve this.

Are there recommended best practices to avoid stalled invitation or transport negotiation in this scenario?

Sort of. My actual recommendation here would be to stop using Multipeer. Quinn has a whole post on this titled "Moving from Multipeer Connectivity to Network Framework".

The one other suggestion I'd have here is to try out the same scenario with the Network.framework sample, "Building a custom peer-to-peer protocol". That sample implements a simple TicTacToe using peer-to-peer WiFi, so if it's failing in the same way, then that would mean there is a much more serious bug underneath Multipeer. However, I suspect you'll find it works fine, making this another reason not to use Multipeer.

Note: In the unlikely event that the Network.framework sample also fails, please file that as a separate bug and post that number here as well.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

0