Hello, We are developing applications using Apple's Nearby Interaction framework for continuous UWB ranging between an iPhone and a UWB-enabled accessory. We have identified a reproducible issue on iPhone 17 where, after running several prolonged UWB ranging sessions (sometimes more than 2 hours), the UWB ranging functionality eventually enters a state where it no longer operates correctly. Once the issue occurs, restarting the application does not recover the UWB functionality. The iPhone must be fully restarted before UWB ranging starts working normally again. We strongly believe the issue is not related to application-specific logic but is a OS issue Device: iPhone 17 UWB: U2 iOS: iOS 26 & iOS 27 beta 4 Framework: Nearby Interaction Steps to reproduce Establish a Nearby Interaction UWB ranging session between the iPhone 17 and a compatible UWB device. Keep the ranging session running continuously for a prolonged period. Repeat this process several times if needed, using long-running sessions. Eventually, the OS will stop delivering didUpdate OS callbacks with ranging distance. After the issue occurs, start a new Nearby Interaction session. Actual result Once the issue occurs, a newly started UWB ranging session only delivers one valid didUpdate ranging callback to the application. After this first callback, no further valid ranging updates are delivered. The issue persists when: the current ranging session is stopped; the application is completely terminated; the application is launched again; a new Nearby Interaction session is created. The only way we have found to recover the device is to fully restart the iPhone. After restarting the phone, Nearby Interaction UWB ranging works normally again. The issue is not in the UWB accessory, the accessory will keep doing valid ranging with other phones, this is only affecting the iPhone that entered the invalid UWB state. Expected result After stopping a Nearby Interaction session and creating a new session, UWB ranging should start normally again, regardless of how many previous ranging sessions have been executed. Terminating and relaunching the application should also release any application-owned resources associated with the previous session. Request Could you please investigate whether this behavior is related to the Nearby Interaction framework, the iPhone 17 UWB subsystem, or an internal UWB state that is not correctly reset between ranging sessions? If any other iOS developer has experienced similar behaviour it would be great if you can share your findings. Material delivered I am attaching a console log that I captured on my iPhone 17. Here the prolonged session was already executed and UWB already entered the invalid state. The iPhone and the UWB accessory are close to each other. We can observe that valid ranging notification (didUpdate) is only delivered for the first ranging round, following ranging rounds will lead to error (the OS does not deliver ranging distance notfs anymore. After this the only way to recover UWB technology is to restart the iPhone. Let us know if you need any additional information for debugging this issue. Feedback assistant issue identifier: FB24484779 logs-iphone17-uwb-issue.rtf

Hi, Apple recently announced DL-TDoA (Downlink TDoA) support on iOS26. This API is currently marked as Beta. We are working on integrating this functionality into our app, already added the APIs and tried to configure a new DL-TDoA session using NIDLTDOAConfiguration (the only parameter it takes is networkIdentifer). The session is configured but automatically invalidated by the OS. When is DL-TDoA expected to be fully supported by phones? Can we expect a detailed documentation or specification explaining how to arrange the session with the DT-Anchors (channel, ranging duration, ...)? Do we need Bluetooth LE connection with the anchors while running DL-TDoA? We already have the 4 DT-Anchors (1 initiator and 3 responders) ready, looking forward to be able to test this new exciting feature and get DL-TDoA measurements to trilaterate the phone position within a map. Regards.

Hello, Our team is working on a mobile app that uses Nearby Interaction framework (UWB technology) to get real-time high-accuracy ranging information with our third-party UWB-enabled device. So far everything works fine, background sessions included as explained in wwdc2022/10008 video. We are using Bluetooth LE to exchange the UWB parameters as recommended by Apple. Our next goal is to go for a full hands-free configuration of the UWB session. Let's think of an access control use case where UWB is used to measure the distance between the user and the door (credentials exchanged via Bluetooth). What we want to achieve is to start the UWB session without requiring the user to take the phone out of his wallet and open the access control app. What it works for us today is if the user starts the app, then switches off the screen and puts the phone into his pocket. The app is still running in background, so the Bluetooth Scan keeps working, the Bluetooth session starts, the UWB parameters exchanged and the UWB session started in the background, all good. But what if the user killed the app or never started it after reboot? How can we force the app to start from killed state when the BLE / UWB third-party accessory comes into proximity? iBeacon seems like a promising approach, but according to the forums, in iOS 16 the app will not be restarted from killed state. Is this correct? Any idea / suggestion about how to let the OS start our app when the user approaches the BLE / UWB accessory and the app is in killed state? Thanks in advance for your time. Regards.

Hello, We are working with Nearby Interaction (UWB) technology to provide high-accurate location use cases to our customers. According to Apple's documentation, in order to enable background sessions starting iOS16, the two devices need to be paired. The accessory needs to implement Nearby service and mandated encrypted characteristic. https://developer.apple.com/documentation/nearbyinteraction/ninearbyaccessoryconfiguration So far we tested this with "PIN-based" secure pairing and everything works fine. Can you confirm if "Just works" PIN-less pairing is expected to work as well here? The documentation is not clear on this respect. We would basically indicate IoNone local capabitilities for the accessory gap parameters if this is expected to work. Thanks in advance! Regards.

Hi all, Recently I updated my app, which is using NearbyInteraction framework and was working great in iOS 15.x, to use new NearbyInteraction APIs introduced in iOS16. The main reason I want to test new APIs is to enable background sessions as explained in WWDC2022-10008. Actually background session is working ok with my third-party accessory, I can bring the app to the background and then back to the foreground and the Nearby Session does not get invalidated. However, I noticed that now using latest API the direction I receive is always null. I am using this API to create the session: "init(accessoryData:bluetoothPeerIdentifier:)" The ranging starts, but distance is nil in didUpdate delegate callback: "func session(_ session: NISession, didUpdate nearbyObjects: [NINearbyObject])" This same code was working before, I would get the direction out of myObject.direction. I tested setting isCameraAssistanceEnabled to true, even tried adding ARSession as in WWDC just in case, but direction and estimated horizontal and vertical angles are always nil. Is there anything I am missing? Any hint how to get this fixed? Regards.

Hello, We are a company working on Ultra Wideband solutions and, hence, using Apple's NearbyInteraction framework to establish UWB Ranging sessions with our UWB-enabled third-party accessory. This week we were excited about the new background UWB Ranging session possibility, which opens new use cases. The wwdc2022 10008 video that provides the technical details for this feature indicates that the third-party accessory is responsible to expose the Nearby Interaction GATT Server. We don't manage to get full details about what needs to be implemented to by compliant with Apple's framework. The URL below indicates that full BLE details should be explained in the "Nearby Interaction Accessory Protocol Specification" but we don't see any info there. https://developer.apple.com/documentation/nearbyinteraction/ninearbyaccessoryconfiguration https://developer.apple.com/nearby-interaction/specification/ Can someone indicate us where the find full details for this background Nearby Interaction feature? Thanks in advance. Regards.

Hello, We are working on a custom solution that uses iPhones (iOS 15.x) configured as peripherals, to advertise themselves and then connect to a central. We are facing an issue when trying to communicate two iPhones with the same central simultaneously. The connection between the central and 1 iPhone is ok, however, as soon as we try to communicate two devices, the second iPhone would not respond to MTU Request and the connection does not go through. Attached the sniffer logs where we can see that the last exchanged packet (before the empty PDUs) is a LL_REJECT_IND_EXT from the BLE Central to the iPhone, because of procedure collision. If we look at the previous message sent by the Central, it is an LL_CONNECTION_UPDATE_IND. Inside this procedure, an “Instant” is given to the iPhone: instant 14 That means that the new parameters will be effective on event counter 14. According to the BLE spec, while a procedure with instant is ongoing, another procedure with instant must not be initiated. However, as you can see, the iPhone initiates a PHY Req at instant 9. Our undestanding is tha the iPhone should not send this request as this is out of spec. This is why the Central sends the rejection message. The iPhone is probably in a wrong state that would explain why it doesn’t answer to the MTU request. As a workaround, would it be possible to disable Phy 2M on the iPhone to avoid this reported issue? Thanks a lot for your support. Regards.