hi folks, im working on an application for downlink time of difference arrival. im using a DWM 3000 ultrawide band board to send DLTDoA pulses. i have followed the protocol in the FiRA 2.0 spec, and properly implemented the swift api, but im getting issues with the iPhones UWB radio chip(rose). i have no issues if i use another board as a receiver instead of my phone. specifically, im using the SP1 frame format, and am getting errors at the PHR stage. to my knowledge, the 0x18 SECDED error means that the PHR header could not be properly decoded. does anyone have advice on how to debug or next steps? its difficult since i cant get access to lower level logs of the chip to actually see whats going wrong. thanks.

We are developing UTipping, a digital tipping application, and are seeking technical guidance before implementation. Our intended experience is: The recipient opens the app and activates “Receive Tip”. The sender selects a tip amount and “Send Tip”. Both authenticated apps are unlocked, online, and in the foreground. The two iPhones are brought into very close physical proximity. The proximity interaction exchanges or resolves only a short-lived, opaque session identifier. No funds, card credentials, cryptograms, or payment-authorization data are exchanged through NFC. The sender confirms the resolved recipient and amount. Payment is processed separately through the backend and licensed payment infrastructure. Standard Core NFC appears to provide reader functionality for supported tags/protocols, but not a general application-controlled iPhone-to-iPhone peer/tag-emulation channel. We would appreciate guidance on: whether this interaction can be implemented using Core NFC; whether NFC & SE Platform or HCE / CardSession could provide the presenter role; whether one third-party iPhone can present a temporary application-controlled identifier to another third-party iPhone; whether both apps must remain foreground; and whether Nearby Interaction with BLE / Multipeer Connectivity is the recommended alternative for very-close-proximity recipient identification. The NFC/proximity interaction would only identify the intended recipient. The financial transaction is completely separate. Apple Developer Support previously referred us to engineering under case 102948761329. We have also submitted the detailed technical architecture through Feedback Assistant: FB24517831 Any guidance from Apple framework engineers regarding the supported architecture and entitlement path would be greatly appreciated.

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

I'm trying to work out why Channel Sounding won't start on my device, and I'd be grateful for any pointers on what condition I haven't satisfied. What I see On an iPhone 17 Pro Max running iOS 27.0 beta (24A5390f), queried after the central manager reaches .poweredOn as the documentation requires: if #available(iOS 27.0, *) { print(CBCentralManager.supports(.channelSounding)) // false print(NISession.deviceCapabilities.supportsBluetoothChannelSounding) // true } No accessory or connection is involved — both are local queries. Because supports(.channelSounding) is false, the Core Bluetooth path fails with CBError code 13 ("Channel Sounding is not supported by the local or remote device"). I also tried calling startChannelSoundingSession(:) anyway, past my own capability check, against a connected peer; the same code 13 comes back from peripheral(:didCompleteChannelSoundingSession:), so it isn't merely an advisory check. The Nearby Interaction path gets further — its capability check passes, so session.run(_:) is called with NINearbyAccessoryConfiguration(bluetoothChannelSoundingIdentifier:previousBluetoothIdentifier:) against a paired, connected reflector — and then invalidates with NIErrorCodeSessionFailed (-5887). Same result with isCameraAssistanceEnabled set to both true and false. Apple's own "Measuring Distance Between Devices Using Channel Sounding" sample behaves identically on this device, so it isn't my code. What I've ruled out Querying before .poweredOn — the value is read in centralManagerDidUpdateState when the state is .poweredOn. Hardware — this is an iPhone 17 Pro Max, and Nearby Interaction's own capability check reports the hardware as capable. The Language & Region setting — changing it makes no difference. Beta staleness — updated across two betas, no change. The reflector — it implements the Ranging Service GATT server and the reflector role, and ranges successfully against another unit of its own model. What I'm unsure about The header comment for CBCentralManagerFeatureChannelSounding reads: The hardware and region supports channel sounding That's the only mention of "region" I can find in any Channel Sounding documentation — WWDC26 session 369 lists the N1 chip and the accessory-side requirements, but nothing about region, and there's no API to query that condition. My device is a South Korea market unit operating in South Korea, so I'm wondering whether that's what I'm hitting, but I have no way to confirm it. I'd also be glad to be told I'm simply wrong about something more mundane. Questions What conditions cause supports(.channelSounding) to return false on a device that has the N1 chip? Is region genuinely one of them, and if so, is it determined by the market the device was sold in, its current location, or something else? Should NISession.deviceCapabilities.supportsBluetoothChannelSounding be expected to agree with the Core Bluetooth check, or does it intentionally report hardware capability only? If the latter, is there a supported way to check Channel Sounding availability before running a session? For anyone with Channel Sounding working: which path are you using — Core Bluetooth's startChannelSoundingSession(_:), or NISession with NINearbyAccessoryConfiguration? And does supports(.channelSounding) return true for you? Question 3 is mostly to help me tell whether this is specific to my device. Thanks — happy to share more logs or a minimal reproducer if it's useful.

I'm trying to get the new Bluetooth Channel Sounding distance measurement working between an iPhone 17 running iOS 27 Beta4 and a Nordic nRF54L15DK board. I enabled bonding in the latest ipt_reflector sample from Nordic. Someone get the sample working with iOS 27 beta1. I paired the board with AccessorySetupKit. I suspect that the Channel Sounding feature is subject to regional restrictions by country (China). Here's the code to check if CS is available on my iPhone func centralManagerDidUpdateState(_ central: CBCentralManager) { switch central.state { case .poweredOn: print("central update") if CBCentralManager.supports(.channelSounding) { print("Supports channel sounding - YES") } else { print("Supports channel sounding - NO") } if let id = pendingPeripheralIdentifier, let name = pendingPeripheralName { pendingPeripheralIdentifier = nil pendingPeripheralName = nil retrieveAndConnect(identifier: id, name: name) } case .poweredOff: connectionState = .bluetoothOff case .unauthorized: connectionState = .error("Bluetooth not authorized — check Settings") case .unsupported: connectionState = .error("BLE not supported on this device") default: break } } The console log shows [ASK] Session activated — accessories: 1 central update Supports channel sounding - NO [CS] startChannelSounding skipped — channelSounding not supported Please also check the topic. it's very similar.

Overview We are developing a BLE + UWB accessory. We need to initiate UWB ranging as quickly as possible after establishing a BLE connection with an iPhone. However, it consistently takes approximately 900–1000 ms from centralManager(_:didConnect:) until the notification subscription (setNotifyValue) reaches the accessory. Most of this delay does not appear to be caused by ATT throughput or accessory response times, but rather by internal iOS processing. Details (Observed Behavior and Measurements) We tested this by implementing code on the app side to delay calling discoverServices by 1 second, measuring the processing times for both scenarios (with vs. without delay). Elapsed time for each phase measured on the app side (CBPeripheralDelegate): Phase Calling discoverServices immediately after connection Delaying discoverServices by 1 second didConnect → discoverServices call 0.1 ms (1000 ms delay) discoverServices → didDiscoverServices 416 ms 26 ms didDiscoverServices → didDiscoverCharacteristics 90 ms 60 ms Key Observations: The most notable finding is that simply delaying the discoverServices call by 1 second reduces the discoverServices → didDiscoverServices duration from 416 ms to 26 ms. This suggests that iOS is performing some internal processing right after connection, during which ATT service discovery responses appear to be delayed/postponed. Pure ATT discovery (Services + Characteristics) completes in about 86 ms when delayed. The app calls setNotifyValue(true, for:) immediately without delay inside peripheral(_:didDiscoverCharacteristicsFor:error:). However, the accessory receives the CCCD write approximately 400 ms after discovery completes. (Note: This 400 ms is an estimate based on the difference with accessory-side measurements). On the accessory side, completion of the ATT MTU exchange was observed around 380 ms after connection. Hypothesis We hypothesize that during the "first ~1 second after connection," iOS is sequentially executing link-layer control procedures (e.g., Feature Exchange, Version Exchange, Data Length Update, PHY Update) as well as ATT MTU exchange. Because these procedures are processed sequentially, ATT service discovery responses may be deprioritized or queued behind them. We have isolated the issue on the accessory side: the peripheral responds immediately to all requests, confirming that accessory processing delays or ATT throughput limitations are not the cause. Questions Is taking several hundred milliseconds to ~1 second from connection establishment (didConnect) to the completion of service discovery and notification subscription expected behavior in iOS? Is our understanding correct that iOS (CoreBluetooth / Bluetooth Controller) is executing link-layer control procedures during this initial period? If not, what specifically is taking place? Are there any means to shorten this duration from the app side or via peripheral connection parameters? Given the significant difference in response time between calling discoverServices immediately vs. delaying it, is there any way to prioritize ATT traffic right after connection or accelerate these procedures? For accessories that need to begin ranging immediately after connecting, what are the recommended best practices to minimize latency before data communication can start?

I'm trying to get Apple's new Bluetooth Channel Sounding distance measurement working between an iPhone running iOS 27 Beta and a Nordic nRF54L15-based board. The CS procedures appear to execute successfully over the air (Mode 0 + Mode 2 with Inline PCT), but the iOS sample app consistently returns 0 distance readings and occasionally throws Channel Sounding configuration failed. What specific validation does iOS 27 apply to CS results before surfacing them ? Are there known compatibility requirements for Nordic nRF54L15 with iOS Channel Sounding? (Nordic has indicated they're working on official support but have no timeline) Is there a publicly available hardware and/or firmware platform already available we can use to test? PacketLogger log nRF54L15 log

I am trying on iOS 16.1.1 the Nearby Interaction framework. I am testing it on two iPhones 14 Pro Max. The supportsDirectionMeasurement property returns false (!) and the direction property on the NINearbyObjects is nil. Has someone experienced the same issue?

I’m currently using Apple’s official sample code and configured my project strictly in accordance with the documentation at https://developer.apple.com/documentation/CoreBluetooth/measuring-distance-between-devices-using-channel-sounding. I’m leveraging an nRF54L15 development board to implement the Channel Sounding feature, yet I’m unable to retrieve valid distance or bearing measurements. My setup details are as follows: iOS 27 beta 2 running on an iPhone 17 Pro. I’d like to confirm whether any additional special configurations are required for the sample code to enable proper distance and bearing detection, as well as what extra setup steps are necessary on the nRF54L15 development board. Additionally, the following error keeps appearing during runtime: [CS] NISession being invalidated — error: Error Domain=com.apple.NearbyInteraction Code=-5887 "NIERROR_SESSION_FAILED_DESCRIPTION" UserInfo={NSLocalizedRecoverySuggestion=NIERROR_SESSION_FAILED_RECOVERY_SUGGESTION, NSLocalizedDescription=NIERROR_SESSION_FAILED_DESCRIPTION, NSLocalizedFailureReason=NIERROR_SESSION_FAILED_FAILURE_REASON}

Kind folks, Was all setup for online access to several Q&A sessions at this WWDC, even posted some questions. But other priorities on my project prevented me from attending. Did any of you hear any news on direction finding with 3rd party devices at this year's WWDC? My current understanding is that (for iPhones later than 15) the NI framework returns null for direction. Apple recommends use of the ARkit in conjunction with NI (tech session way back in WWDC22!) FYI, I've been trying hard to get any information on this topic. Would be happy to share what public information/speculation I've found (including how Apple get's such good range and direction info in their Find My app for their AirTag 2 😉). Perhaps we can set up a small discussion group for sharing insights and experiences with emerging UWB technology. Comments appreciated. Mike

Hello, I am currently working with the Nearby Interaction framework on iOS and exploring the capabilities of UWB-based communication. I would like to ask whether Nearby Interaction supports multicast communication over UWB. Specifically, is it possible for one device to interact simultaneously with multiple peer devices using UWB (e.g., broadcasting ranging or spatial information to multiple devices at once), or is the framework strictly limited to one-to-one peer interactions? If multicast is not supported, are there any recommended approaches or best practices for achieving similar functionality using the current APIs? Thank you for your help. Best regards,

I have an app that uses nearby with a custom accessory. works great on iPhone 11-13, starting with iPhone 14, one must use ARkit to get angles we have two problems ARkit is light sensitive, and we do not control the lighting where this app would run.. the 11-13 action works great even in the dark. (our users are blind, this is an accessibility app) ARkit wants to be foreground, but our uses cannot see it, and we have a voice oriented UI that provides navigation instructions.. IF ARkit is foreground, our app doesn't work. with iPhone 15 ProMax, on IOS 18, I got an error, access denied. (not permission denied) now that I am on IOS 26.. bt scan doesn't happen also fails same way on iPhone 17 on IOS26, can't callback now as release signing is no longer done this same code works ok on iOS 17.1 on iPhone 12. Info.plist here info.txt if(SearchedServices == [] ){ services = [TransferService.serviceUUID,QorvoNIService.serviceUUID] } logger.info( "scannerready, starting scan for peripherals \(services) and devices \(IDs)") filteredIDs=IDs; scanning=true; centralManager.scanForPeripherals(withServices: services, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true]) the calling code dataChannel.autoConnect=autoConnect; dataChannel.start(x,ids) // datachannel.start is above self.scanning = true; return "scanning started"; ... log output services from js = and devices= 5FE04CBB services in implementation = bluetooth ready, starting scan for peripherals [] and devices ["5FE04CBB"] scannerready, starting scan for peripherals [6E400001-B5A3-F393-E0A9-E50E24DCCA9E, 2E938FD0-6A61-11ED-A1EB-0242AC120002] and devices ["5FE04CBB"] ⚡️ TO JS {"value":"scanning started"}

Given that Apple is a Sponsor level member of the FIRa Consortium (on UWB interoperability) and the FIRa 3.0 spec has been released, are there any improvements in the Nearby Interaction framework for UWB direction tracking? It appears that NI returns null for direction-found with third-party UWB device currently.

I’m exploring a visionOS interaction pattern where nearby Apple Vision Pro users have opted in ahead of time, such as when entering a shared venue, and a physical gesture like a handshake triggers a lightweight exchange of user-approved information between their devices. I’m not asking about identifying strangers, accessing raw camera data, or tracking another person without consent. I’m trying to understand the most automatic Apple-supported architecture for this kind of privacy-preserving nearby interaction. What is the recommended approach on visionOS? Specifically: Can a visionOS app use ARKit hand tracking to detect the current user’s own gesture, then combine that with nearby peer discovery or ranging through Nearby Interaction, Network framework, Multipeer Connectivity, Bluetooth, Wi-Fi, or another supported API? Is there a supported way for two nearby Vision Pro devices to exchange a small user-approved payload after prior opt-in, without requiring users to manually start SharePlay or confirm every individual exchange? If SharePlay or Group Activities is the recommended path for shared spatial context, is there a supported alternative for venue-scale or multi-user interactions that should not be limited to a small active SharePlay group? What are the privacy and App Review boundaries for this pattern? Should developers assume the app cannot identify nearby people, observe another person’s body or hands, or trigger an exchange unless both users have explicit opt-in and clear awareness? If a mostly passive gesture-triggered exchange is not supported today, what is the closest Apple-recommended design pattern?

I'm developing a spatial tracking app using a Qorvo DWM3001CDK (MFi-certified UWB accessory) with NINearbyAccessoryConfiguration. On iPhone 15 (iOS 26.3.1, second-generation UWB chip): supportsDirectionMeasurement = false NINearbyObject.direction is always nil NINearbyObject.distance works correctly (~63Hz) Camera Assistance (isCameraAssistanceEnabled=true) provides horizontalAngle only after ARKit convergence (~10s), and only while the phone is moving On iPhone 12/13 (first-generation UWB chip), direction works correctly with the same accessory. My questions: Is the removal of instantaneous direction measurement for third-party accessories on second-generation UWB devices intentional? Or is this a regression that will be fixed in a future iOS update? If intentional, what is the recommended approach for apps that need real-time direction to a UWB accessory on iPhone 15/16? Camera Assistance requires phone movement and only works with stationary targets, which doesn't work for our use case (tracking a moving object with the phone mounted on a gimbal). Are there any plans to provide instantaneous direction measurement for NINearbyAccessoryConfiguration on second-generation UWB devices? Environment: iPhone 15, iOS 26.3.1 Qorvo DWM3001CDK (FiRa + MFi certified) NINearbyAccessoryConfiguration with isCameraAssistanceEnabled=true Shared ARSession Thank you.

目前这个findmy 设备是已经通过MFI认证，不过后续想的在”Find My “应用上像 AirTag 一样支持UWB测距功能。 寻找了相关资料，在这篇文章《Nearby-Interaction-Accessory-Protocol-Specification-Release-R4》中找到了UWB的相关功能，但是需要我们自己开发第三方应用。 所以需要怎么做才可以做到像airtag 一样在“Find My”应用上显示距离和方向

The FindMy device is currently MFI certified, but we plan to support UWB ranging functionality in the Find My app, similar to AirTag. After searching for relevant information, I found the relevant UWB functions in this article "Nearby-Interaction-Accessory-Protocol-Specification-Release-R4", but we need to develop third-party applications ourselves. So how can we make it display distance and direction in the "Find My" app like AirTag does?

Hello, I am developing with the Nearby Interaction framework using third-party UWB accessories (Murata SR040/SR150). I observed a difference between U1-based and U2-based iPhones: iPhone 12 Pro (U1 chip) NINearbyObject.direction returns valid 3D vector (x, y, z). Distance and direction both work as expected. iPhone 15 Pro and iPhone 16 Pro (U2 chip) NINearbyObject.direction is always nil. Only distance is returned (around 0.35–0.40 m in my test). Effectively behaves as "distance-only mode". Environment: Hardware: iPhone 12 Pro, iPhone 15 Pro iOS version: 18.5 Accessory: Murata UWB SR040 / SR150 App: Using NINearbyAccessoryConfiguration with BLE-based discovery Info.plist includes NSNearbyInteractionUsageDescription Camera assistance was tested both ON and OFF Expectation: I expected the U2 chip to behave consistently with U1, i.e. provide direction vectors when possible. Instead, on iPhone 15 Pro, direction is always unavailable (nil) while distance is returned correctly. Questions: Is this an intentional limitation for U2 chip + third-party accessories? Is there a new requirement (e.g. certification, firmware update, capability flags) to enable direction on U2 devices? Could this be related to NIDeviceCapability or the new Extended Distance Measurement (EDM) mode in U2? Thanks in advance for any clarification.

We are evaluating the new behavior mentioned in the Nearby Interaction documentation for iOS 18.4+, which states: “In iOS 18.4 and later, your app can continue ranging in the background with any supported device if the app starts a Live Activity as it goes to the background." Could you clarify what situations are considered “can continue ranging” versus cases where it will not continue? Specifically, if my app: starts a NISession in the foreground starts a Live Activity with that data then the app goes to background should the NI session still deliver ranging updates so the app can update the Live Activity? also, my app already enable Background Modes capability

Our app is using the CLLocationManager to wake up the app near an iBeacon and then tries to connect to the accessory via bluetooth and UWB. For this to work in the background we need to create a Live Activity and show the user that the app is doing something. When the app is in the foreground or just recently got into the inactivity mode this works fine and we can use CoreBluetooth/NearbyInteraction even when the app then enters the background mode. But when the app is longer in the background creating a Live Activity via Activity.request() throws an ActivityAuthorizationError.visibility. According to the documentation the LiveActivityIntent is able to workaround this background restriction but I get the same exception when I create the LiveActivity from the perform() method. Is there another API to create Live Activities? Do I need to prepare the LiveActivityIntent somehow?