Multipeer Connectivity connection is flaky on iOS 26

While updating our test devices to iOS 26, we noticed that the connection between devices is flaky. Often when connecting to a peer from a device running iOS 26, we can observe the invite coming through and when accepting said invite, both ends go to .connecting state and a while later go back to .notConnected within the peer(_ peerID: MCPeerID, didChange state: MCSessionState) function. This happens regularly, and retrying the invitation process several times usually resolves it.

Have you filed a bug on this, and if so, what is the bug number?

Does anyone have any information or guidance on how to resolve this issue?

Well, unfortunately, my (and Quinn's) longstanding advice has been to move to a new API and stop using MultipeerConnectivity. Quinn actually has an extended forum post describing how to move to the Network framework. I'd also suggest taking a look at the "Building a custom peer-to-peer protocol" sample, which uses the Network framework to implement something very similar to what MultipeerConnectivity provides.

One last comment I'd make on this. Many developers have been reluctant to take this advice because they're concerned about the work involved and that they'll end up with exactly the same issues they were originally having with MultipeerConnectivity. However, in practice, every developer I've helped through this transition has had exactly the same experience. That is:

• They found the "lower level" APIs simpler to understand and work with. In many cases, their new implementation was half the length or less of their original implementation.

• The issues they were previously having with MultipeerConnectivity simply did not happen.

• They were able to add new functionality* with minimal additional effort.

*One particular feature I'd highlight here is the ability to easily DISABLE p2p Wi-Fi, relying entirely on bonjour over infrastructure Wi-Fi. Quinn has a post here describing why that's so useful.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

Hi everyone,

We'd like to raise this issue as well. Our team and another team within our company already raised Radars for this issue.

While I understand that migrating to the Network framework is suggested in this forum. But as long as the MultipeerConnectivity framework is officially supported and not officially deprecated. I don't see a reason why this should not be addressed.

The feedback IDs are: 102797175610 And after more extensive testing with a more detailed description and findings that might help you: FB22691771

In summary for this forum: We assume that (since iOS26) as soon as Bluetooth is involved in establishing a connection, the pairing process becomes flaky and requires up to 20 attempts. When Wifi is turned off or at least not connected to any Access Point, we reproduce this issue, always. When Wifi is turned on and both devices are connected to the same network, the MultipeerConnectivity framework works flawlessly still.

Kind regards Pascal

So, I want to start by directly addressing this:

While I understand that migrating to the Network framework is suggested in this forum. But as long as the MultipeerConnectivity framework is officially supported and not officially deprecated.

While it might seem like this is simply a case of us recommending a newer/fancier framework over an older one, that isn't actually the case here. In my previous post, I referenced Quinn's post on this transition, which opens by saying:

"I see a lot of folks spend a lot of time trying to get Multipeer Connectivity to work for them. My experience is that the final result is often unsatisfactory."

Unfortunately, that sentence has largely been true since we introduced MultipeerConnectivity. Quinn's post then outlines a number of issues we've seen with the framework, and then recommends the Network framework. Prior to the introduction of the Network framework (which is a very nice API), my recommendation would instead have been to use NSNetService or, possibly, dnssd (the lowest level Bonjour API).

Critically, this isn't simply about any specific bug or minor failure. The reality is that our experience across a very long period of time is that, in practice, MultipeerConnectivity simply does not work very well for most developers.

Moving over to the bug side of things, reordering things a bit:

When Wi-Fi is turned on and both devices are connected to the same network, the MultipeerConnectivity framework works flawlessly still.

When both devices are on the same network, MultipeerConnectivity discovery works as a relatively "thin" layer on top of standard Bonjour discovery. This has always been highly reliable, to the point that the vast majority of problems on infrastructure Wi-Fi are app bugs, not framework issues.

When Wi-Fi is turned off or at least not connected to any Access Point, we reproduce this issue, always.

What do you mean by "turned off"? Wi-Fi is the system’s p2p communication channel, so if Wi-Fi is turned off, wireless p2p communication cannot occur.

How are you testing this? In particular, are you testing with one device being the phone, the other device being the Mac, and the phone connected to the Mac over USB?

It's not well known, but this configuration works by creating a network interface over the USB connection and that interface is visible to both systems and can be used for more "general" networking. I'm not sure of the current state of things, but it's certainly possible that changes to that system have also made it less reliable as a "general" interface, which might explain the timing change.

The feedback IDs are: 102797175610 And after more extensive testing with a more detailed description and findings that might help you: FB22691771

In terms of an active investigation, we'd need the following to be added to that bug:

1. A description of the specific devices involved in the test.

2. A detailed description of both the general testing process and the details of each test cycle that was performed, including a timeline of the testing process that includes both what should have happened and what happened instead.

3. Ideally, a copy of the small test project used to replicate the problem.

4. A sysdiagnose from every device involved in the testing.

Note that while the exact time the sysdiagnose is triggered (anytime within a few minutes of the test ending is fine), it is critical that the device NOT have been rebooted after testing finishes. So much log data is purged during the reboot process that the system console is no longer reliable for this kind of investigation.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

What Kevin said but also…

But as long as the MultipeerConnectivity framework is … not officially deprecated.

The fact that Multipeer Connectivity is not officially deprecated is an ongoing source of confusion, one that I’ve been trying to rectify for years (r. 83185901). There are two ways to resolve that confusion:

• Fix the various bugs affecting Multipeer Connectivity.
• Formally deprecate the framework.

I’d bet dollars to doughnuts [1] that the ultimate resolution is gonna be that second one. So, if you’re investing time with this framework, you should carefully consider whether that’s time well spent.

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

[1] Actually, doughnuts to dollars, because doughnuts have got a lot more expensive since that idiom was coined back in the 1800s (-:

Hi Kevin, Hi Quinn

Thank you very much for the very quick replies. Almost an honor to hear from two literal dev forum legends so quickly. Much appreciated. Thanks in advance.

I will add all the requested detailed info into the feedback app, asap. Hopefully as early as Monday when i'm in the office. In the meantime I can give you some reply already, should you guys chose to already be working/looking at it over the weekend (who knows).

To correct a statement of mine: With Wi-Fi "off" I meant via the control center. Naive me forgot completely that it doesn't really turn off the wifi interface. Obviously, turning it off completely via the Settings app will result in noop for the framework and that makes obviously sense. So please ignore that statement, i made a mess there.

Some answers I can give you already though (Based on Kevins list):

1. Our apps mainly work on iPads. And it affects ALL iPad devices on/since iOS 26 as far as we can tell.
2. Theoretically theres not much more detail needed other than attempting to pair two iPads using the framework, all while Wifi is on and not connected to any access point. It's really that simple. No direct USB connection or anything.
3. I'd bet any example app would do. As it affects multiple apps in our portfolio equally (with separate implementations). But if it really helps, i think I can quickly hook up an example app on Monday and share a repository with you. But I really think you could try any already existing out there.
4. I don't have it handy right now. But I can try on Monday once i'm in the office to give you that.

To summarize: We never had issues with the framework, our applications relied on the framework for multiple years. For our use cases it worked flawlessly until and with iOS18. iOS26 broke it fundamentally for the initial pairing process, affecting all devices in our own repository (from iPad Airs, up to Pros, Wifi only and Wifi + Cellular, you name it). Customers are also starting to report issues since iOS26.

But on Monday i will try to supplement the thread here and the radar with a young sysdiagnose (without reboot, promised :-) ) after reproducing the issue. Maybe/Ideally/Hopefully with a barebones example app.

Thank you and a nice weekend Pascal

Hi Quinn and Kevin,

To the feedback FB22691771 I now added:

• A small example app found online, with the same setup as our app.
• Two sysdiagnoses, one from the sender end (the app initiaiting pairing) and one from the receiver end (the one accepting the invitation).
• As requested, the pairing attempts should be visible within the last 2-3 minutes in the sysdiagnose,
• pairing attempts were performed until pairing succeeded.
• Additionally I attached a side by side screen (time matched) recording showing both views (test setup). On the bottom right it would be the receivers view. Additionally, the video was recorded during the same period as the sysdiagnose. So timestamps (at least minutes) should match.

And again for this to be reproducible:

• Turn Wifi on + don't be connected to any access point (on both devices).
• Be on iOS 26 on both devices (on iOS18 this is NOT reproducible)

I would add the attachments here as well, but file size and formats are limited.

Thank you for your help!

Thank you very much for the very quick replies. Almost an honor to hear from two literal dev forum legends so quickly.

This is much, much funnier than you'd realized. Up until COVID took WWDC virtual, Quinn and I would regularly end up hanging out together in the WWDC labs... talking someone out of using MultipeerConnectivity. Apparently, we've continued that habit into the forums.

To the feedback FB22691771 I now added:

Fabulous, all of that was perfect. In terms of what the logs show, if you narrow down to the "MultipeerConnectivity" library, you'll clearly see that it's repeatedly discovering the device and attempting to connect, only to have the connection fail over and over again. What's causing the full failure pattern isn't clear, but it's likely tied to these messages on the receiver side:

2026-05-11 08:30:50.990771+0200 wifip2pd: [com.apple.awdl:subscribe] AWDLBrowse _rps-service._tcp.local will attempt to stop
2026-05-11 08:30:50.991521+0200 wifip2pd: [com.apple.awdl:subscribe] AWDLBrowse _rps-service._tcp.local was terminated with reason User Requested

I haven't figured out the exact timing, but it looks to me like there's a timing bug of some kind which is causing the system to teardown the AWDL interface before MPC is able to fully establish the connection. FYI, ignore the "User Requested" reason above, it's not referring to "you" or any action you took.

Two requests/suggestions:

1. Earlier I mentioned the sample "Building a custom peer-to-peer protocol". Please perform the same tests with that sample, as that will help validate whether this is an issue in the AWDL link itself or in how MPC is managing that connection.

2. If the sample above works (which I expect it will), try running both apps in "split screen" (so that they're both running at the same time). My guess is that you'll find that MPC starts working, which would confirm that this is an issue in MPC, not the broader network.

If you get a failure on #1, then please connect the same pair of sysdiagnoses and upload them to the bug as well. In the comments, note that this is reproducing them with our non-MPC sample.

Finally, if you end up collecting more sysdiagnoses (now or in the future), I'd recommend that you do the following before you actually start testing:

• Turn the device off and leave it off for “a while". Basically, as long as possible (overnight would be great!), but a few 10 or 15 minutes is fine. The goal here is to create a very clear time gap in the log, so that's easy to see where the device powered on (this can be surprisingly hard to determine).

• Turn the device on, unlock it, then leave it for a few minutes. Lots of "stuff" happens when a device first turns on, so leaving it like this helps reduce log noise when you actually start testing.

...then perform your tests and collect the log as usual.

None of those steps are necessarily essential, but they help make the log clearer and easier to analyze. For example, one issue with the logs you just sent is that you've done so much testing across so much time that there's no good way to determine exactly when the problem first occurred. That can be a problem if the clue we need is tied to how the Wi-Fi stat first initialized.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware