Well, I guess we have our answer now. It's officially deprecated! Obviously we'd still prefer if the whole framework wouldn't have regressed the way it did. But I'm sure Quinn and Kevin are gonna have their own little party around this :-). Thank you very much for your help guys. At least I came out of this with much more knowledge on how to create better sysdiagnoses for the future.

Hi @DTS Engineer and @DTS Engineer (Kevin and Quinn), Just checking in whether this is still on your radar 👀. Have you been able to reproduce it (friendly reminder: it's super easy and reliably reproducible) or learn anything more about the issue in the meantime? Or perhaps you got it in front of the right team already? Regards Pascal

This is much, much funnier than you'd realized. Up until COVID took... I can imagine! And don’t get me wrong, I really understand why you guys are suggesting the Network framework. IMO, it makes total sense for new applications to build directly on top of that. But I think there’s still a lot of value in fixing the MPC framework, because there are many apps and libraries out there relying on MPC. In our case, for example, we’re also quite restricted in terms of update policies due to our very regulated domain. We can’t simply push updated apps to customers, or at least not to customers running years-old versions who either don’t want to or can’t update to more recent releases. In those situations, we rely on Apple fixing these issues on the OS side. We also wouldn’t be raising awareness here if this had always been an issue. Our apps have relied on MPC for almost a decade now (the code goes back to 2018), and for our use cases it worked flawlessly (it really did :D). Customers used it extensively without problems. This appears to be a regression introduced specifically in iOS 26, as the exact same MPC setup and connection flow worked reliably across previous iOS releases for years. As you kind of mentioned yourself: if this wasn’t a newly introduced bug, we wouldn’t be filing feedback reports and sending mails with this much detail and urgency. Now enough chit chat about background information and restrictions. Lets get back to the issue: Two requests/suggestions: Earlier I mentioned the sample "Building a custom peer-to-peer protocol".... Done, and as assumed, I didn't reproduce it. (Surprise surprise! Network framework is great :D) 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).... Now here the result might actually surprise you: I STILL managed to reproduce it. Same steps as earlier. I even made sure the Tic-Tac-Toe game from Apple’s sample app was already paired up and running. And in an attempt to really help you guys out as much as possible, I added the following to the feedback FB22691771: A new pair of sysdiagnoses for the second test, running Tic-Tac-Toe and Rock Paper Scissors in Split View. As you suggested, I had both iPads powered off for at least 10 minutes. After booting, I waited another 5 minutes before executing the test steps. You should see clear log gaps from both devices, significantly less log noise, and only a single test execution with a few connection attempts before it successfully connected. This time I included a video showing both devices in "split screen" running the two apps in "split screen" ("split screen"-ception. Sorry, couldn’t help myself), recorded during the sysdiagnoses above. I really hope the effort I put in helps you out and maybe earns me a little reciprocal debugging effort from Apple’s side as well :D. But honestly, with the information I already provided and the test steps I mentioned earlier, I think you should be able to reproduce the issue yourselves pretty easily. I assume you also have the right debugging and instrumentation tools internally to investigate this much more deeply than what sysdiagnoses alone would provide :) Please give it a try. I’m convinced this affects all apps using MPC the same way the example app has it set up. There are also third-party Swift packages that abstract MPC even further for developers while using the same setup internally, so users of those packages are very likely affected as well.

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!

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): Our apps mainly work on iPads. And it affects ALL iPad devices on/since iOS 26 as far as we can tell. 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. 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. 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 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