Hi, I am facing a strange issue in my app with iOS14 there is a intermittent crash, i am using NetServiceBrowser for MDNS discovery not sure if that is causing the problem crash log has below information: Crashed: com.apple.main-thread 0 CoreFoundation 0x1a906c4c4 CFAssertMismatchedTypeID + 108 1 CoreFoundation 0x1a8f7db0c CFRunLoopSourceRemoveFromRunLoop + 298 2 CFNetwork 0x1a96255b0 CFNetServiceBrowserStopSearch + 460 3 CoreFoundation 0x1a8f81240 CFRUNLOOPISCALLINGOUTTOASOURCE0PERFORMFUNCTION + 24 4 CoreFoundation 0x1a8f81140 CFRunLoopDoSource0 + 204 5 CoreFoundation 0x1a8f80488 CFRunLoopDoSources0 + 256 6 CoreFoundation 0x1a8f7aa40 CFRunLoopRun + 776 7 CoreFoundation 0x1a8f7a200 CFRunLoopRunSpecific + 572 8 GraphicsServices 0x1bf075598 GSEventRunModal + 160 9 UIKitCore 0x1ab840004 -[UIApplication run] + 1052 10 UIKitCore 0x1ab8455d8 UIApplicationMain + 164

Hello, dear engineer: The UWB Accessory used by my APP has inconsistent code callbacks on iOS17 and iOS18. I have connected multiple UWB Accessory by Accessory Single Configuration Data (UUID: 95e8d9d5-d8ef-4721-9a4e-807375f53328) in the APP. In iOS17.5.1, the unconnected Accessory calls the func session in the NiSessionDelegate (_ session: NISession, didRemove nearbyObjects: [NINearbyObject], "reason: NINearbyObject RemovalReason)," reason is the timeout. iOS18.0.1 does not call didRemove and fails to connect automatically after 10 minutes on the disconnected Accessory. iOS18.2 does not call didRemove. After 10 minutes, when the Accessory is not connected, it automatically connects and starts ranging. Therefore, I would like to ask what is updated in iOS18 UWB? Is there a document for reference, or can you provide the callback performance of each iOS version for UWB? The code is as follows: niConfiguration = try NINearbyAccessoryConfiguration(data: Data(AccessoryUwbConfigData)) uwbSession.run(niConfiguration)

Our product (rockhawk.ca) uses the Multipeer Connectivity framework for peer-to-peer communication between multiple iOS/iPadOS devices. My understanding is that MC framework communicates via three methods: 1) infrastructure wifi (i.e. multiple iOS/iPadOS devices are connected to the same wifi network), 2) peer-to-peer wifi, or 3) Bluetooth. In my experience, I don't believe I've seen MC use Bluetooth. With wifi turned off on the devices, and Bluetooth turned on, no connection is established. With wifi on and Bluetooth off, MC works and I presume either infrastructure wifi (if available) or peer-to-peer wifi are used. I'm trying to overcome two issues: Over time (since iOS 9.x), the radio transmit strength for MC over peer-to-peer wifi has decreased to the point that range is unacceptable for our use case. We need at least 150 feet range. We would like to extend this support to watchOS and the MC framework is not available. Regarding #1, I'd like to confirm that if infrastructure wifi is available, MC uses it. If infrastructure wifi is not available, MC uses peer-to-peer wifi. If this is true, then we can assure our customers that if infrastructure wifi is available at the venue, then with all devices connected to it, range will be adequate. If infrastructure wifi is not available at the venue, perhaps a mobile wifi router (battery operated) could be set up, devices connected to it, then range would be adequate. We are about to test this. Reasonable? Can we be assured that if infrastructure wifi is available, MC uses it? Regarding #2, given we are targeting minimum watchOS 7.0, would the available networking APIs and frameworks be adequate to implement our own equivalent of the MC framework so our app on iOS/iPadOS and watchOS devices could communicate? How much work? Where would I start? I'm new to implementing networking but experienced in using the MC framework. I'm assuming that I would write the networking code to use infrastructure wifi to achieve acceptable range. Many thanks! Tim

When transferring files in a Multipeer Session, using the Progress instances (returned by either sendResource in the sender or the delegate method session(didStartReceiving:) on the receiver) in a SwiftUI ProgressView will eventually cause a crash (EXC_BAD_ACCESS in swift_retain on com.apple.MCSession.syncQueue) I have created a small sample project that demonstrates the problem. It can be found at: https://github.com/eidria/Multipeer-Progress-Demo.git. A screen shot of the stack trace from a crash (crash.jpg) is in the “Images” folder. STEPS TO REPRODUCE Run the sample on two different hosts connected to the same network (project contains both iOS & macOS targets, bug manifests in any combination). When the second instance comes up, they will automatically find and connect to each other. When the “Send Files” button is enabled, clicking it will cause the sender to repeatedly send the file “Image.HEIC” from the “Images” folder to the receiver, which deletes it upon receipt of a successful transfer (i.e. delegate call back is called with a nil error). Subsequent transfers are triggered when the sender receives notice that the prior send completed successfully. Eventually, after some (usually small) number of files have been transferred, either the sender or receiver will crash in the middle of a transfer, with EXC_BAD_ACCESS in swift_retain on com.apple.MCSession.syncQueue. Commenting out the ProgressView in the file FileTransferView.swift will allow the apps to run in perpetuity.

Since Apple Multipeer framework does not really work without crashes, I implemented my own multipeer with the Network.framework. like let tcpOptions = NWProtocolTCP.Options.createDefault() let parameters = NWParameters(tls: NWProtocolTLS.Options(), tcp: tcpOptions) parameters.setDefaultSettings() let browser = NWBrowser( for: .bonjour( type: config.bonjourServiceType, domain: nil ), using: parameters ) and extension NWParameters { func setDefaultSettings() { self.includePeerToPeer = true self.requiredInterfaceType = .wifi self.preferNoProxies = true } } extension NWProtocolTCP.Options { static func createDefault() -> NWProtocolTCP.Options { let tcpOptions = NWProtocolTCP.Options() tcpOptions.enableKeepalive = true tcpOptions.keepaliveIdle = 10 // 10 seconds keepalive interval tcpOptions.noDelay = true // Disable Nagle's algorithm for low latency return tcpOptions } } it works well up to approx. 30 meter outside with free view. What's the max range for the peer to peer via bonjour? And is there a way to get longer distance than 30 meter?

We are currently developing an application that runs in the background and continuously scans for other nearby devices via peer-to-peer networking. Generally, the high-level goals are: Scan for nearby devices while the app is in the background state. We only need to discover devices that are also running our app. Read a small token of data from each peer device found (no need for full-duplex connection) Submit this token to our server via a background network request On Android we have demonstrated this functionality using both Bluetooth LE and WifiDirect service discovery, and background operation is easily achieved with Android services. We are currently trying to expand our application to support cross-platform compatibility between IOS and Android, including IOS<-->IOS and IOS<-->Android discovery (in the background). Is there a way to achieve this desired functionality on IOS?

I have an application that enables recording video from multiple iPhones through an iPad. It uses Multipeer Connectivity for all the device communication. When the user presses record on the iPad, it sends a command to each device in parallel and they start capturing video. But since network latency varies, I cannot guarantee that the recording start and stop times are consistent among all the iPhones. I need the frames to be exactly in sync. I tried using the system clock on each device for synchronizing the videos. If all the device system clocks were in sync within 3ms (30 frames per second), then it should be okay. But I tested and the clocks vary quite a bit, multiple seconds. So that won't work. I ultimately solved the problem by having a countdown timer on the iPad. The user puts the iPad in view of each phone with the countdown. Then later I use a python script to cut all the videos when the countdown timer goes to 0. But that's more work for the end user and requires manual work on our end. With a little ML text recognition, this could get better. Some people have suggested using a time server and syncing the clocks that way. I still haven't tried this out, and I'm not sure if it's even possible to run a NTP server on an iPad, and whether the NTP resolution will be below 3ms. I tried out Final Cut Camera and it has solved the synchronization problem. Each frame is in sync. The phones don't start and stop at exactly the same time, and they account for this by adding black frames to the front and/or back of videos to account for differences. I've searched online and other people have the same problem. I'd love to know how Apple was able to solve the synchronization issue when recording video from multiple iPhones from an iPad over what I assume is Multipeer Connectivity.

Hi, We try to geolocate with UWB signal an app in background with NXP UWB Kit. We use Nearby Interaction method in background Apple documentation indicate to use this class: NINearbyAccessoryConfiguration but we have this error when we try to create the session: NIERROR_ACCESSORY_PEER_DEVICE_UNAVAILABLE_FAILURE_REASON any body can help us to use successfully this functionnality ?

I understand that the Nearby Interaction framework is available on watchOS 8+, and I want to make a watch app that displays distance estimation between multiple watches (not iPhones) using UWB through Nearby Interactions. I see in the documentation that an iPhone can discover multiple device "discovery tokens" and create NISessions with them using the Multipeer Connectivity framework, but it looks like the Multipeer Connectivity framework is not available on watchOS? So, how might I make an independent watch app that can discover multiple nearby watches and setup NISessions with them? Thanks!

Since the Multipeer Connectivity framework no longer supports Bluetooth. (https://developer.apple.com/forums/thread/749346) Why does its official documentation still mention "In iOS, the framework uses infrastructure Wi-Fi networks, peer-to-peer Wi-Fi, and Bluetooth personal area networks for the underlying transport." ?(https://developer.apple.com/documentation/multipeerconnectivity) What is the purpose of using Bluetooth personal area networks for the underlying transport?

Hello, In this inquiry（https://developer.apple.com/forums/thread/747860）, I came across this conclusion. “Apple disabled TCP/IP networking over Bluetooth completely. Apple’s peer-to-peer networking APIs now run exclusively over Wi-Fi." I have three questions I would like to ask. The Multipeer Connectivity Framework supports Wi-Fi networks, peer-to-peer Wi-Fi, and Bluetooth personal area networks. Since the framework abstracts away the underlying protocols, we cannot specify which protocol to choose. Can this framework still establish a pure Bluetooth connection now? (Not just using Bluetooth for the discovery phase). Given that the framework supports Bluetooth protocols, why does it not require Bluetooth permissions but only local network permissions? Does the Bluetooth protocol supported by the framework have the capability to discover traditional Bluetooth devices and services that the Core Bluetooth framework can discover?

I've been recently working on a VisionOS app which uses CoreMl to identify specific body parts and display a window with information of the identified body part, since the use of Vision Pro's cameras is blocked, I'm using an iPhone to perform image classification, and then send the label to the headset using Multipeer Connectivity, I'd like to display a volume once the user selects a body part, could my iPhone return enough spatial information for me to be able to fully take advantage of Vision Pro's mixed reality capabilities?

Hello! We have an app that runs on two iPads, in two different modes, that communicate with one another using Apple's Multipeer Connectivity APIs. Last week, after upgrading to iPadOS 17.4 we have had MANY customer reports of erratic connectivity, only on iPadOS 17.4. The iPads connect for 30 seconds to a minute, disconnect, reconnect for a short time again, and repeat. Most of our customers are school districts who likely employee an MDM and we are working on verification of that in order to reproduce the issue in-house. Were there changes to the MPC framework in iPadOS 17.4 that could be causing sessions to be dropped? Are you aware of any interaction with device management software that could cause this?

I would like to connect to a POS working with android system to send and receive data (JSON ). Is it possible to connect to the POS android device using peer to peer connectivity? Like wifi direct in andriod system ? Note that I don't want them to be on the same wifi network (eg. local wifi network) and send and receive through the network.

Hi, to previse all of this, I am new to Swift and iOS app development. I have an Idea for an app, however, this includes Multiplayer connectivity for up to 10 people. I have been trying to look into what would be required to run this. I am confused if I need to invest in an external server or if I can run this through GameKit or CloudKit. Any help is appreciated. Thank you.

Hey devs! I recently started a project, a macOS app, which is like a Remote Desktop app but only on local network. For this I wanted to use the MultipeerConnectivity framework, and it's my first time using it. So I have already done the device discovery side that is working well as it is the easier part. Now I just need someone who knows how it works and who has time to explain me (as I couldn't find any documentation about this) how does work the OutputStream And InputStream in MC and if its a good choice for my needs. It has to be low latency and high resolution... I also have seen other frameworks such as WebRTC that I could combine with a local WebSocket Server, but as I'm new to live video streaming and that I don't know anyone that is experimented with this I wanted to ask there for your advices. Thank you in advance, TR-MZ (just an unknown Indie dev).

Hi everyone, I have an AR app that allows for collaborative sessions and synchronizes model state (e.g. rotation, can be changed via slider) using Multipeer Connectivity. The receiving peer parses the data and then uses DispatchQueue.main.async to update the UI (SwiftUI) and the model in SceneKit. Lately I have noticed that this synchronization seems to lag periodically. To analyze the issue better I compiled this minimal reproducible example: https://github.com/MrMuetze/MCSyncTest The repository includes a boiled down "Multipeer Connectivity" project that should make this issue reproducible on local devices (maybe even between one device and the simulator). I have also added a readme with a gif that shows the issue. The synchronization between devices worked like a treat for a long time but recently I have noticed that e.g. a rotation is not as smooth as before on the receiving device. A bit of debugging revealed that the messages are received quickly but then the work that needs to happen on the main thread is periodically delayed. In the example project the relevant code bit that should be executed on the main thread looks like this: func session(_: MCSession, didReceive data: Data, fromPeer _: MCPeerID) { print("received data") DispatchQueue.main.async { print("doing stuff") let doubleVal = data.to(type: Double.self) ?? 0.0 self.internalSliderValue = doubleVal self.sliderValue = doubleVal } } It updates a published variable sliderValue that is connected to a Slider and a Text UI element. Regularly (like every 500ms or so) the execution of work on the main thread seems to be delayed. After a short while all outstanding UI updates are executed at once which leads to visual stuttering. This can be observed by looking at the printed messages: ... received data &lt;-- normal behavior doing stuff received data doing stuff received data doing stuff received data &lt;-- hiccup starts received data received data received data doing stuff doing stuff doing stuff doing stuff received data &lt;-- returns to normal behavior doing stuff received data doing stuff ... I have tried to change the "Quality of Service" to .userInteractive as well as limiting the number of messages that are sent in a certain timeframe (I tried one message every 100ms). Both changes have not helped and even with a much lower number of messages the periodic stuttering remains. Using DispatchQueue.main.sync is also not a solution right now. It does bring the sequence back into original order but the periodic "freeze" of the queue is prevalent there as well. This then leads to a "laggy" execution of what happened on the sending peer device. I am not very familiar with Profiling an app and using Instruments, but I have captured some timings in regards to the usage of the main thread and some backtraces. From what I can understand the workload of the written code should not be the issue, but rather an underlying system function or library. I can provide more information in regards to the backtraces if needed. Right now I can't really say what would be useful. Below is an image that shows the main thread usage at the very top. This happens when the slider lags as shown in the gif. I am working with Xcode 15.2 and run the app on iOS 17.3. For devices I use an iPad Pro (2nd gen.) and an iPhone 15 Pro. The issue happens in Debug as well as in Release mode. I can't quite say when the stuttering appeared initially. I wonder if anyone is aware of any changes to iOS or underlying frameworks that could have caused this issue. I am interested in any information about this, if the issue can be resolved or if I have to look for alternative workarounds. Let me know if I can add any additional information. Best regards! Bjoern

Hi all, hope everyone is well. I'm seeking clarification regarding AirDrop functionality in regards to apps. For example, can the new AirDrop function within iOS17, whereby putting two iPhones together transfers user contact details to one another be utilised by an app? If not, please could I have clarification what bluetooth functionality within iPhone's an App may be able to utilise and could an app connect to AirDrop API's in any way? If the new AirDrop feature is not currently able to be utilised by apps, is this likely to change in the future with upcoming iOS updates or is it a set in stone thing? Apologies, I don't have the deepest understanding of this topic and any help is really appreciated, thank you.

The connection using MultipeerConnectivity between iPhones and iPads with iOS 17 or higher installed is not functioning. This issue was not observed on iOS 16 or earlier versions. Currently, when advertising from an iPhone, the iPad can detect the device, but the event handling to accept invitations on the iPhone is not being triggered correctly. Consequently, not responding to invitations is preventing the connection. While the Wi-Fi feature is enabled, previously, it was possible to establish connections without being connected to a specific Wi-Fi network. However, presently, connection seems to occur only when the iPad and iPhone are on the same network. Moreover, irregular connections are occurring between iPhones, yet there is no connection whatsoever between iPads and iPhones.