Nearby Interaction

RSS for tag

Locate and interact with nearby devices using distance, direction, and identifier.

Posts under Nearby Interaction tag

130 Posts

Post

Replies

Boosts

Views

Activity

Can't create a Live Activity from background
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?
1
0
1k
Mar ’26
Clarifying the intended scope of DL-TDoA ranging in Nearby Interaction
Does DL-TDoA ranging in the Nearby Interaction framework support building a traditional RTLS-style TDoA localization system, where a device’s absolute position is computed from time-difference measurements across multiple deployed anchors, or is DL-TDoA strictly limited to system-managed, relative ranging and direction estimation (distance/direction) between nearby devices? If DL-TDoA ranging in Nearby Interaction is not intended to support traditional RTLS-style TDoA localization, is there any public documentation or reference material that describes the intended DL-TDoA architecture, such as the expected system setup, device roles, and deployment constraints (for example, how ranging is expected to be performed between an iPhone and nearby accessories), beyond the high-level API documentation? Regards.
0
0
430
Jan ’26
ExtendedDistanceMeasurement in Nearby Interaction Framework not working on iOS 26
Problem Description: After upgrading to iOS 26, I discovered that the ExtendedDistanceMeasurement feature in the Nearby Interaction framework is not working as expected. On the same device model, the issue did not occur on iOS 18, but it is present on iOS 26 (including the latest iOS 26.2), and it has started affecting the functionality of my app. I hope this issue can be resolved as soon as possible. Problem Details: On iOS 26 and later versions (including iOS 26.2), when using an iPhone and an Apple Watch both equipped with second-generation UWB chips, enabling isExtendedDistanceMeasurementEnabled initiates the distance measurement process successfully, but the distance information fails to update. The real-time distance between the devices does not display within the app. Affected Devices and Versions: iPhone Model: iPhone 15 Pro Max iOS Version: iOS 26.2 Apple Watch Model: Apple Watch 10 watchOS Version: 26.2 Example Code: The issue can be reproduced by adding the following code from the official sample code: Nearby Interaction Framework Sample Code
1
1
396
Dec ’25
ExtendedDistanceMeasurement in Nearby Interaction Framework not working on iOS 26
Problem Description: After upgrading to iOS 26, I discovered that the ExtendedDistanceMeasurement feature in the Nearby Interaction framework is not working as expected. On the same device model, the issue did not occur on iOS 18, but it is present on iOS 26 (including the latest iOS 26.2), and it has started affecting the functionality of my app. I hope this issue can be resolved as soon as possible. Problem Details: On iOS 26 and later versions (including iOS 26.2), when using an iPhone and an Apple Watch both equipped with second-generation UWB chips, enabling isExtendedDistanceMeasurementEnabled initiates the distance measurement process successfully, but the distance information fails to update. The real-time distance between the devices does not display within the app. Affected Devices and Versions: iPhone Model: iPhone 15 Pro Max iOS Version: iOS 26.2 Apple Watch Model: Apple Watch 10 watchOS Version: 26.2 Example Code: The issue can be reproduced by adding the following code to the official sample code: Nearby Interaction Framework Sample Code private func didReceiveDiscoveryToken(_ token: NIDiscoveryToken) { if session == nil { initializeNISession() } if !didSendDiscoveryToken { sendDiscoveryToken() } os_log("running NISession with peer token: \(token)") let config = NINearbyPeerConfiguration(peerToken: token) // The issue can be reproduced by adding the following code to the official sample code // Enable extended distance measurement if both devices support it if NISession.deviceCapabilities.supportsExtendedDistanceMeasurement && token.deviceCapabilities.supportsExtendedDistanceMeasurement { config.isExtendedDistanceMeasurementEnabled = true } session?.run(config) } Problem Behavior: When either the iPhone or the Apple Watch does not support the second-generation UWB chip (i.e., deviceCapabilities.supportsExtendedDistanceMeasurement = false), the code works as expected. However, when both the iPhone and the Apple Watch support the second-generation UWB chip (i.e., deviceCapabilities.supportsExtendedDistanceMeasurement = true), the code fails to work, and the distance does not update — meaning the real-time distance between the devices is not displayed. Expectation: I hope this issue can be resolved soon, as it is impacting my app. The problem persists in the latest iOS 26.2, and has yet to be fixed.
0
0
153
Dec ’25
Идея для технического усовершенствования продуктов apple
Сегодня столкнулась с проблемой, что у телефона разъем лайтнинг, а у наушников тайпси. Не все владельцы айфонов имеют в распоряжении наушники этого же производителя и разъемы не всегда совпадают. Начала изучать реверсивную зарядку, думаю, это было ы отличной идеей для следующих продуктов
0
0
448
Nov ’25
Can Live Activity Enable Continuous Nearby Interaction (UWB) in Background with Third-Party Accessories?
Hi, I'm working on an app that integrates third-party UWB accessories using the Nearby Interaction framework. I want to display real-time data via Live Activities, and ideally, I hope the app can continue ranging/interacting with the accessory even when it's in the background—triggering updates in the Live Activity. Specifically: Can I use Live Activity to keep Nearby Interaction sessions running in the background, as long as the accessory is still nearby and connected? Or do I always need to initiate sessions in the foreground? Are there ways to maintain or trigger new Nearby Interaction sessions entirely in the background, when using third-party UWB accessories? Is there any official guidance regarding permissions, user authorization requirements, or restrictions for background ranging with third-party hardware? Are there recommended strategies or patterns for updating Live Activity widgets with data from Nearby Interaction or UWB accessories while backgrounded? (e.g. Bluetooth triggers, push notifications, background tasks) Any advice, experiences, or official recommendations would be greatly appreciated! I want to ensure my implementation is compliant and offers the best possible user experience. Thanks!
0
1
703
Nov ’25
[iOS 26] Unable to start TLS handshake connection to devices with self-signed certificates
Hi there, We are facing some issues regarding TLS connectivity: Starting with iOS 26, the operating system refuses to open TLS sockets to local devices with self-signed certificates over Wi-Fi. In this situation, connection is no longer possible, even if the device is detected on the network with Bonjour. We have not found a workaround for this problem. We've tryied those solutions without success: Added the 'NSAppTransportSecurity' key to the info.plist file, testing all its items, such as "NSAllowsLocalNetworking", "NSExceptionDomains", etc. Various code changes to use properties such as "sec_protocol_options_set_local_identity" and "sec_protocol_options_set_tls_server_name" to no avail. Brutally import the certificate files into the project and load them via, for example, "Bundle.main.url(forResource: "nice_INTERFACE_server_cert", withExtension: "crt")", using methods such as sec_trust_copy_ref and SecCertificateCopyData. Download the .pem or .crt files to the iPhone, install them (now visible under "VPN & Device Management"), and then flag them as trusted by going to "Settings -> General -> Info -> Trust". certificates" The most critical part seems to be the line sec_protocol_options_set_verify_block(tlsOptions.securityProtocolOptions, { $2(true) }, queue) whose purpose is to bypass certificate checks and validate all of them (as apps already do). However, on iOS26, if I set a breakpoint on leg$2(true),` it never gets there, while on iOS 18, it does. I'll leave as example the part of the code that was tested the most below. Currently, on iOS26, the handler systematically falls back to .cancelled: func startConnection(host: String, port: UInt16) { self.queue = DispatchQueue(label: "socketQueue") let tlsOptions = NWProtocolTLS.Options() sec_protocol_options_set_verify_block(tlsOptions.securityProtocolOptions, { $2(true) }, queue) let parameters = NWParameters(tls: tlsOptions) self.nwConnection = NWConnection(host: .init(host), port: .init(rawValue: port)!, using: parameters) self.nwConnection.stateUpdateHandler = { [weak self] state in switch state { case .setup: break case .waiting(let error): self?.connectionDidFail(error: error) case .preparing: break case .ready: self?.didConnectSubject.onNext(Void()) case .failed(let error): self?.connectionDidFail(error: error) case .cancelled: self?.didDisconnectSubject.onNext(nil) @unknown default: break } } self.setupReceive() self.nwConnection.start(queue: queue) } These are the prints made during the procedure. The ones with the dot are from the app, while the ones without are warnings/info from Xcode: 🔵 INFO WifiNetworkManager.connect():52 - Try to connect onto the interface access point with ssid NiceProView4A9151_AP 🔵 INFO WifiNetworkManager.connect():68 - Connected to NiceProView4A9151_AP tcp_output [C13:2] flags=[R.] seq=215593821, ack=430284980, win=4096 state=CLOSED rcv_nxt=430284980, snd_una=215593821 nw_endpoint_flow_failed_with_error [C13 192.168.0.1:443 in_progress channel-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], dns, uses wifi, LQM: unknown)] already failing, returning nw_connection_copy_protocol_metadata_internal_block_invoke [C13] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C13] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C13] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C13] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C14] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C14] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C14] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C14] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection [C14 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel [C14 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel nw_connection_copy_protocol_metadata_internal_block_invoke [C15] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C15] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C15] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C15] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C16] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C16] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C16] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C16] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection [C16 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel [C16 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel 🔴 ERROR InterfaceDisconnectedViewModel.connect():51 - Sequence timeout.
1
0
823
Oct ’25
Nearby Interaction / DL-TDoA (Beta): Need NITLDOA params; 16 Pro shows distance-only, 13 has direction
Apple recently announced DL-TDoA (Downlink TDoA) support on iOS 26, and the API is currently marked Beta. Using two iPhones (16 Pro and 13) on iOS 26.0 Beta, I’m starting a Nearby Interaction session and need to read NITLDOA parameters (address, carrier frequency offset, signal strength/RSSI), but I can’t find a supported way. I’m also seeing asymmetry: iPhone 13 reports distance+direction, while 16 Pro reports distance only. Is there a supported workflow/API to access those parameters, and any known device/OS constraints that would cause direction to be unavailable on 16 Pro?
0
2
603
Sep ’25
DL-TDoA support using Nearby Interaction framework
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.
0
4
623
Aug ’25
I am not enable to use Nearby Interactions.
Hello there, I am trying to add Nearby Interaction into my project, but it is not appear into +capabilities. I have already go to my account into developer account platform to try to add it from Identifiers: Then I search into my project to activated, but Nearby Interaction was not show: So, there is anything else that i have miss? please help :c
2
0
595
Aug ’25
Duplicate timestamps in UWB (Nearby Interaction) updates.
Hello, We are using NearbyInteraction to get the distance between an iPhone and Apple Watch. Overall it works pretty well, but we are noticing that it sometimes produces duplicate (or near duplicate) timestamps. Here is an example of the data produced (time is in seconds since scan start): 0: 1.882862 1: 1.88296 2: 1.981459 3: 1.981495 4: 2.080235 5: 2.080397 As you can see there's a pattern where two updates have very similar timestamps. This seems to only happen when using 2 U2 chips together. Is this an expected behavior? If so, why? The timestamps are calculated using: let bootTimeInterval = bootTime() func bootTime() -> TimeInterval { let uptime = ProcessInfo.processInfo.systemUptime let nowTimeIntervalSince1970 = Date().timeIntervalSince1970 return nowTimeIntervalSince1970 - uptime } // Then later on each NISession update... let timestamp = bootTimeInterval + ProcessInfo.processInfo.systemUptime The app produces unix timestamps but I have converted them to be relative to the start of the scan to be easier to read. Note that bootTimeInterval is calculated once at the start of the app, so all timestamps produced on a UWB update should be using the same clock. Things I've confirmed: The NISession is only able to connect to one device, so it is not coming from a different device. Any feedback is appreciated, thank you.
0
0
318
Aug ’25
UWB Background Ranging with Live Activities - iOS 18.4
I’m developing an app that uses UWB for proximity detection between users. I have questions about iOS 18.4’s new Live Activity background UWB capabilities. Live Activity Background UWB “Loophole” Apple’s documentation states that apps can continue UWB ranging in background with “any supported device” if a Live Activity is started as the app backgrounds - without requiring Bluetooth LE pairing. Key Questions: 1. Background initiation: Can new UWB sessions be initiated between devices while in background using Live Activities, or must sessions start in foreground first? 2. No pairing requirement: Does this iOS 18.4 Live Activity approach truly eliminate the need for Bluetooth LE pairing for background UWB ranging? 3. Session persistence: How long can UWB ranging continue in background with an active Live Activity? 4. Testing without entitlement: Can I test UWB functionality between multiple devices in Xcode without the Nearby Interaction entitlement approved yet? Context My app needs precise proximity detection between users in real-time. The Live Activity background capability would be essential since users need to put phones away while the ranging continues. This iOS 18.4 feature seems like it could be a game-changer for apps requiring background UWB functionality without the complexity of Bluetooth pairing. Has anyone successfully implemented this Live Activity + background UWB approach?
0
0
513
Jul ’25
APP Background Keep-Alive
Dear Apple: We are developing an app for file sharing between mobile devices. We want to create an iOS app that can continue sharing files with other devices even when it is running in the background. We are using WLAN channels for file sharing. Could you please advise on which background persistence measures we should use to ensure the iOS app can maintain file transfer when it goes to the background? Thank you.
1
0
368
Apr ’25
Issue with UWB ranging on DWM3001CDK using NINearbyAccessoryConfiguration in Background mode
Hi, I’m trying to perform UWB ranging between an iPhone and a Qorvo DWM3001CDK accessory using Apple NI’s NINearbyAccessoryConfiguration class. I’ve followed the steps described in the official Apple documentation (https://developer.apple.com/documentation/nearbyinteraction/ninearbyaccessoryconfiguration), specifically for enabling background mode using the init(accessoryData:bluetoothPeerIdentifier:) initializer. The configuration is successfully created, and background mode is enabled. However, when the iPhone starts the session, I doesn’t receive any ranging data from the DWM3001CDK, and the session ends with a timeout. Interestingly, if I use the init(data:) initializer, I can successfully receive ranging data, but this only works in foreground mode, which doesn’t meet my requirements. Steps I’ve followed: Used Core Bluetooth to discover and pair the accessory. Retrieved the configuration data from the accessory according to the third-party UWB device specifications. Initialized the configuration using NINearbyAccessoryConfiguration(accessoryData:bluetoothPeerIdentifier:) for background mode. Started the session with NISession.run(configuration). Waited for updates in the delegate method session(_:didUpdate:). Specific questions: Are there additional requirements for using init(accessoryData:bluetoothPeerIdentifier:) to enable background UWB ranging with the DWM3001CDK? Is there a known difference in how init(data:) and init(accessoryData:bluetoothPeerIdentifier:) handle the ranging process? Any advice or insights would be greatly appreciated. Thanks in advance!
1
0
649
Mar ’25
Using Google Maps in App to determine distance
So far, we have been using Google Maps to determine distance along a certain route for a MacOS app to register kilometers for a business administration app. But, this is no longer possible, as the login for google maps no longer works. I understand we would have to pay to continue using the Google Maps service as it was and we would have to make changes to the app. That would be ok, but I was just wondering does any developer on this forum have suggestions on how to resolve this issue? Or even maybe have suggestions, to make this work better than before. Three suggestions by chatgpt: use ANWB route planner using google maps, Pro6pp, or to useWisp.Software (something I haven't heard of before. Your suggestions and ideas are welcome. Also, if the Apple Developer team knows of a way how to do this in your app, your advice is more than welcome. Have a nice day!
2
0
837
Feb ’25
NIERROR_ACCESSORY_PEER_DEVICE_UNAVAILABLE_DESCRIPTION (Code=-5882) occurs when running NISession for Nearby Interaction.
Overview I am running a NearbyInteaction sample. Immediately after niSession.run(configuration!), func session(_ session: NISession, didInvalidateWith error: Error) is executed. The error is as follows, but I cannot find the cause. Error: bluetoothPeerIdentifier: AF5ADDC1-F731-7BAD-E8C5-9230E79F8C1A Session Invalidation Error: NIERROR_ACCESSORY_PEER_DEVICE_UNAVAILABLE_DESCRIPTION Error Details:Error Domain=com.apple.NearbyInteraction Code=-5882 "NIERROR_ACCESSORY_PEER_DEVICE_UNAVAILABLE_DESCRIPTION" UserInfo={NSLocalizedRecoverySuggestion=NIERROR_ACCESSORY_PEER_DEVICE_UNAVAILABLE_RECOVERY_SUGGESTION, NSLocalizedDescription=NIERROR_ACCESSORY_PEER_DEVICE_UNAVAILABLE_DESCRIPTION, NSLocalizedFailureReason=NIERROR_ACCESSORY_PEER_DEVICE_UNAVAILABLE_FAILURE_REASON} The sample application worked well at first. I want the application to run in the background, so I made the following changes and had problems. Before change: configuration = try NINearbyAccessoryConfiguration(data: configData) After change: configuration = try NINearbyAccessoryConfiguration( accessoryData: configData, bluetoothPeerIdentifier: peerIdentifier) I see no problem with the application. It works fine on device A. The problem occurs on device B. Device A: NXP QN9090 - NXP SR150 Device B: Nordic nRF52840 - NXP SR150 I have confirmed that the device shows up in the settings app after pairing & bonding the device. I have confirmed that the iPhone and nRF52840 are still connected to the BLE without any problems when the error occurs. Initialization code for NearbyInteraction: func setupAccessory(_ configData: Data, name: String) { updateInfoLabel(with: "Received configuration data from '\(name)'. Running session.") do { guard let discoveredPeripheral = dataChannel.getDiscoveredPeripheral() else { return } let peerIdentifier = discoveredPeripheral.identifier configuration = try NINearbyAccessoryConfiguration( accessoryData: configData, bluetoothPeerIdentifier: peerIdentifier) } catch { // Stop and display the issue because the incoming data is invalid. // In your app, debug the accessory data to ensure an expected // format. updateInfoLabel( with: "Failed to create NINearbyAccessoryConfiguration for '\(name)'. Error: \(error)" ) return } // Cache the token to correlate updates with this accessory. cacheToken(configuration!.accessoryDiscoveryToken, accessoryName: name) niSession.run(configuration!) } Environment Xcode 16.1 iPhone11 (iOS 17.6.1) Target UWB Chip: NXP SR150 Sample iOS Application: https://developer.apple.com/documentation/nearbyinteraction/implementing-spatial-interactions-with-third-party-accessories
1
0
668
Feb ’25
Can't create a Live Activity from background
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?
Replies
1
Boosts
0
Views
1k
Activity
Mar ’26
Clarifying the intended scope of DL-TDoA ranging in Nearby Interaction
Does DL-TDoA ranging in the Nearby Interaction framework support building a traditional RTLS-style TDoA localization system, where a device’s absolute position is computed from time-difference measurements across multiple deployed anchors, or is DL-TDoA strictly limited to system-managed, relative ranging and direction estimation (distance/direction) between nearby devices? If DL-TDoA ranging in Nearby Interaction is not intended to support traditional RTLS-style TDoA localization, is there any public documentation or reference material that describes the intended DL-TDoA architecture, such as the expected system setup, device roles, and deployment constraints (for example, how ranging is expected to be performed between an iPhone and nearby accessories), beyond the high-level API documentation? Regards.
Replies
0
Boosts
0
Views
430
Activity
Jan ’26
Detecting iPhone absence via UWB on macOS
I'm developing a proximity tool on macOS Tahoe 26.2 (M4 MacBook Pro) to detect when my iPhone leaves the immediate vicinity of my macbook. Does NearbyInteraction on macOS support persistent background sessions for detecting peer absence (didInvalidate/timeout), or is CoreBluetooth still required as the keep-alive trigger?
Replies
0
Boosts
0
Views
329
Activity
Jan ’26
ExtendedDistanceMeasurement in Nearby Interaction Framework not working on iOS 26
Problem Description: After upgrading to iOS 26, I discovered that the ExtendedDistanceMeasurement feature in the Nearby Interaction framework is not working as expected. On the same device model, the issue did not occur on iOS 18, but it is present on iOS 26 (including the latest iOS 26.2), and it has started affecting the functionality of my app. I hope this issue can be resolved as soon as possible. Problem Details: On iOS 26 and later versions (including iOS 26.2), when using an iPhone and an Apple Watch both equipped with second-generation UWB chips, enabling isExtendedDistanceMeasurementEnabled initiates the distance measurement process successfully, but the distance information fails to update. The real-time distance between the devices does not display within the app. Affected Devices and Versions: iPhone Model: iPhone 15 Pro Max iOS Version: iOS 26.2 Apple Watch Model: Apple Watch 10 watchOS Version: 26.2 Example Code: The issue can be reproduced by adding the following code from the official sample code: Nearby Interaction Framework Sample Code
Replies
1
Boosts
1
Views
396
Activity
Dec ’25
ExtendedDistanceMeasurement in Nearby Interaction Framework not working on iOS 26
Problem Description: After upgrading to iOS 26, I discovered that the ExtendedDistanceMeasurement feature in the Nearby Interaction framework is not working as expected. On the same device model, the issue did not occur on iOS 18, but it is present on iOS 26 (including the latest iOS 26.2), and it has started affecting the functionality of my app. I hope this issue can be resolved as soon as possible. Problem Details: On iOS 26 and later versions (including iOS 26.2), when using an iPhone and an Apple Watch both equipped with second-generation UWB chips, enabling isExtendedDistanceMeasurementEnabled initiates the distance measurement process successfully, but the distance information fails to update. The real-time distance between the devices does not display within the app. Affected Devices and Versions: iPhone Model: iPhone 15 Pro Max iOS Version: iOS 26.2 Apple Watch Model: Apple Watch 10 watchOS Version: 26.2 Example Code: The issue can be reproduced by adding the following code to the official sample code: Nearby Interaction Framework Sample Code private func didReceiveDiscoveryToken(_ token: NIDiscoveryToken) { if session == nil { initializeNISession() } if !didSendDiscoveryToken { sendDiscoveryToken() } os_log("running NISession with peer token: \(token)") let config = NINearbyPeerConfiguration(peerToken: token) // The issue can be reproduced by adding the following code to the official sample code // Enable extended distance measurement if both devices support it if NISession.deviceCapabilities.supportsExtendedDistanceMeasurement && token.deviceCapabilities.supportsExtendedDistanceMeasurement { config.isExtendedDistanceMeasurementEnabled = true } session?.run(config) } Problem Behavior: When either the iPhone or the Apple Watch does not support the second-generation UWB chip (i.e., deviceCapabilities.supportsExtendedDistanceMeasurement = false), the code works as expected. However, when both the iPhone and the Apple Watch support the second-generation UWB chip (i.e., deviceCapabilities.supportsExtendedDistanceMeasurement = true), the code fails to work, and the distance does not update — meaning the real-time distance between the devices is not displayed. Expectation: I hope this issue can be resolved soon, as it is impacting my app. The problem persists in the latest iOS 26.2, and has yet to be fixed.
Replies
0
Boosts
0
Views
153
Activity
Dec ’25
Идея для технического усовершенствования продуктов apple
Сегодня столкнулась с проблемой, что у телефона разъем лайтнинг, а у наушников тайпси. Не все владельцы айфонов имеют в распоряжении наушники этого же производителя и разъемы не всегда совпадают. Начала изучать реверсивную зарядку, думаю, это было ы отличной идеей для следующих продуктов
Replies
0
Boosts
0
Views
448
Activity
Nov ’25
Can Live Activity Enable Continuous Nearby Interaction (UWB) in Background with Third-Party Accessories?
Hi, I'm working on an app that integrates third-party UWB accessories using the Nearby Interaction framework. I want to display real-time data via Live Activities, and ideally, I hope the app can continue ranging/interacting with the accessory even when it's in the background—triggering updates in the Live Activity. Specifically: Can I use Live Activity to keep Nearby Interaction sessions running in the background, as long as the accessory is still nearby and connected? Or do I always need to initiate sessions in the foreground? Are there ways to maintain or trigger new Nearby Interaction sessions entirely in the background, when using third-party UWB accessories? Is there any official guidance regarding permissions, user authorization requirements, or restrictions for background ranging with third-party hardware? Are there recommended strategies or patterns for updating Live Activity widgets with data from Nearby Interaction or UWB accessories while backgrounded? (e.g. Bluetooth triggers, push notifications, background tasks) Any advice, experiences, or official recommendations would be greatly appreciated! I want to ensure my implementation is compliant and offers the best possible user experience. Thanks!
Replies
0
Boosts
1
Views
703
Activity
Nov ’25
[iOS 26] Unable to start TLS handshake connection to devices with self-signed certificates
Hi there, We are facing some issues regarding TLS connectivity: Starting with iOS 26, the operating system refuses to open TLS sockets to local devices with self-signed certificates over Wi-Fi. In this situation, connection is no longer possible, even if the device is detected on the network with Bonjour. We have not found a workaround for this problem. We've tryied those solutions without success: Added the 'NSAppTransportSecurity' key to the info.plist file, testing all its items, such as "NSAllowsLocalNetworking", "NSExceptionDomains", etc. Various code changes to use properties such as "sec_protocol_options_set_local_identity" and "sec_protocol_options_set_tls_server_name" to no avail. Brutally import the certificate files into the project and load them via, for example, "Bundle.main.url(forResource: "nice_INTERFACE_server_cert", withExtension: "crt")", using methods such as sec_trust_copy_ref and SecCertificateCopyData. Download the .pem or .crt files to the iPhone, install them (now visible under "VPN & Device Management"), and then flag them as trusted by going to "Settings -> General -> Info -> Trust". certificates" The most critical part seems to be the line sec_protocol_options_set_verify_block(tlsOptions.securityProtocolOptions, { $2(true) }, queue) whose purpose is to bypass certificate checks and validate all of them (as apps already do). However, on iOS26, if I set a breakpoint on leg$2(true),` it never gets there, while on iOS 18, it does. I'll leave as example the part of the code that was tested the most below. Currently, on iOS26, the handler systematically falls back to .cancelled: func startConnection(host: String, port: UInt16) { self.queue = DispatchQueue(label: "socketQueue") let tlsOptions = NWProtocolTLS.Options() sec_protocol_options_set_verify_block(tlsOptions.securityProtocolOptions, { $2(true) }, queue) let parameters = NWParameters(tls: tlsOptions) self.nwConnection = NWConnection(host: .init(host), port: .init(rawValue: port)!, using: parameters) self.nwConnection.stateUpdateHandler = { [weak self] state in switch state { case .setup: break case .waiting(let error): self?.connectionDidFail(error: error) case .preparing: break case .ready: self?.didConnectSubject.onNext(Void()) case .failed(let error): self?.connectionDidFail(error: error) case .cancelled: self?.didDisconnectSubject.onNext(nil) @unknown default: break } } self.setupReceive() self.nwConnection.start(queue: queue) } These are the prints made during the procedure. The ones with the dot are from the app, while the ones without are warnings/info from Xcode: 🔵 INFO WifiNetworkManager.connect():52 - Try to connect onto the interface access point with ssid NiceProView4A9151_AP 🔵 INFO WifiNetworkManager.connect():68 - Connected to NiceProView4A9151_AP tcp_output [C13:2] flags=[R.] seq=215593821, ack=430284980, win=4096 state=CLOSED rcv_nxt=430284980, snd_una=215593821 nw_endpoint_flow_failed_with_error [C13 192.168.0.1:443 in_progress channel-flow (satisfied (Path is satisfied), viable, interface: en0[802.11], dns, uses wifi, LQM: unknown)] already failing, returning nw_connection_copy_protocol_metadata_internal_block_invoke [C13] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C13] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C13] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C13] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C14] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C14] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C14] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C14] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection [C14 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel [C14 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel nw_connection_copy_protocol_metadata_internal_block_invoke [C15] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C15] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C15] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C15] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C16] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_protocol_metadata_internal_block_invoke [C16] Client called nw_connection_copy_protocol_metadata_internal on unconnected nw_connection nw_connection_copy_connected_local_endpoint_block_invoke [C16] Client called nw_connection_copy_connected_local_endpoint on unconnected nw_connection nw_connection_copy_connected_remote_endpoint_block_invoke [C16] Client called nw_connection_copy_connected_remote_endpoint on unconnected nw_connection [C16 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel [C16 192.168.0.1:443 tcp, tls, attribution: developer] is already cancelled, ignoring cancel 🔴 ERROR InterfaceDisconnectedViewModel.connect():51 - Sequence timeout.
Replies
1
Boosts
0
Views
823
Activity
Oct ’25
Nearby Interaction / DL-TDoA (Beta): Need NITLDOA params; 16 Pro shows distance-only, 13 has direction
Apple recently announced DL-TDoA (Downlink TDoA) support on iOS 26, and the API is currently marked Beta. Using two iPhones (16 Pro and 13) on iOS 26.0 Beta, I’m starting a Nearby Interaction session and need to read NITLDOA parameters (address, carrier frequency offset, signal strength/RSSI), but I can’t find a supported way. I’m also seeing asymmetry: iPhone 13 reports distance+direction, while 16 Pro reports distance only. Is there a supported workflow/API to access those parameters, and any known device/OS constraints that would cause direction to be unavailable on 16 Pro?
Replies
0
Boosts
2
Views
603
Activity
Sep ’25
DL-TDoA support using Nearby Interaction framework
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.
Replies
0
Boosts
4
Views
623
Activity
Aug ’25
I am not enable to use Nearby Interactions.
Hello there, I am trying to add Nearby Interaction into my project, but it is not appear into +capabilities. I have already go to my account into developer account platform to try to add it from Identifiers: Then I search into my project to activated, but Nearby Interaction was not show: So, there is anything else that i have miss? please help :c
Replies
2
Boosts
0
Views
595
Activity
Aug ’25
Duplicate timestamps in UWB (Nearby Interaction) updates.
Hello, We are using NearbyInteraction to get the distance between an iPhone and Apple Watch. Overall it works pretty well, but we are noticing that it sometimes produces duplicate (or near duplicate) timestamps. Here is an example of the data produced (time is in seconds since scan start): 0: 1.882862 1: 1.88296 2: 1.981459 3: 1.981495 4: 2.080235 5: 2.080397 As you can see there's a pattern where two updates have very similar timestamps. This seems to only happen when using 2 U2 chips together. Is this an expected behavior? If so, why? The timestamps are calculated using: let bootTimeInterval = bootTime() func bootTime() -> TimeInterval { let uptime = ProcessInfo.processInfo.systemUptime let nowTimeIntervalSince1970 = Date().timeIntervalSince1970 return nowTimeIntervalSince1970 - uptime } // Then later on each NISession update... let timestamp = bootTimeInterval + ProcessInfo.processInfo.systemUptime The app produces unix timestamps but I have converted them to be relative to the start of the scan to be easier to read. Note that bootTimeInterval is calculated once at the start of the app, so all timestamps produced on a UWB update should be using the same clock. Things I've confirmed: The NISession is only able to connect to one device, so it is not coming from a different device. Any feedback is appreciated, thank you.
Replies
0
Boosts
0
Views
318
Activity
Aug ’25
Found Possible WiFi Exploit
was that Spokane, Washington my fresh my fresh basket and they’re using a expired Wi-Fi certification domain through godaddy.com that expire April 30, 2020 I have a complete information on it if anybody needs me to forward it or wants to examine it their selves but be wary when you connected to the Wi-Fi over at my fresh basket at in Spokane, Washington
Replies
1
Boosts
0
Views
649
Activity
Jul ’25
UWB Background Ranging with Live Activities - iOS 18.4
I’m developing an app that uses UWB for proximity detection between users. I have questions about iOS 18.4’s new Live Activity background UWB capabilities. Live Activity Background UWB “Loophole” Apple’s documentation states that apps can continue UWB ranging in background with “any supported device” if a Live Activity is started as the app backgrounds - without requiring Bluetooth LE pairing. Key Questions: 1. Background initiation: Can new UWB sessions be initiated between devices while in background using Live Activities, or must sessions start in foreground first? 2. No pairing requirement: Does this iOS 18.4 Live Activity approach truly eliminate the need for Bluetooth LE pairing for background UWB ranging? 3. Session persistence: How long can UWB ranging continue in background with an active Live Activity? 4. Testing without entitlement: Can I test UWB functionality between multiple devices in Xcode without the Nearby Interaction entitlement approved yet? Context My app needs precise proximity detection between users in real-time. The Live Activity background capability would be essential since users need to put phones away while the ranging continues. This iOS 18.4 feature seems like it could be a game-changer for apps requiring background UWB functionality without the complexity of Bluetooth pairing. Has anyone successfully implemented this Live Activity + background UWB approach?
Replies
0
Boosts
0
Views
513
Activity
Jul ’25
Nearby entitlement for third party accessories
How do I gain access to the com.apple.developer.nearby-interaction entitlement for third-party accessory use with Qorvo DWM3001CDK? I've read the documentation but it is not available in Xcode Capabilities. What is the approval process?
Replies
1
Boosts
0
Views
558
Activity
Jun ’25
The frequency of uwb background ranging
Is there a way to increase the frequency of UWB background ranging?
Replies
0
Boosts
0
Views
216
Activity
Apr ’25
APP Background Keep-Alive
Dear Apple: We are developing an app for file sharing between mobile devices. We want to create an iOS app that can continue sharing files with other devices even when it is running in the background. We are using WLAN channels for file sharing. Could you please advise on which background persistence measures we should use to ensure the iOS app can maintain file transfer when it goes to the background? Thank you.
Replies
1
Boosts
0
Views
368
Activity
Apr ’25
Issue with UWB ranging on DWM3001CDK using NINearbyAccessoryConfiguration in Background mode
Hi, I’m trying to perform UWB ranging between an iPhone and a Qorvo DWM3001CDK accessory using Apple NI’s NINearbyAccessoryConfiguration class. I’ve followed the steps described in the official Apple documentation (https://developer.apple.com/documentation/nearbyinteraction/ninearbyaccessoryconfiguration), specifically for enabling background mode using the init(accessoryData:bluetoothPeerIdentifier:) initializer. The configuration is successfully created, and background mode is enabled. However, when the iPhone starts the session, I doesn’t receive any ranging data from the DWM3001CDK, and the session ends with a timeout. Interestingly, if I use the init(data:) initializer, I can successfully receive ranging data, but this only works in foreground mode, which doesn’t meet my requirements. Steps I’ve followed: Used Core Bluetooth to discover and pair the accessory. Retrieved the configuration data from the accessory according to the third-party UWB device specifications. Initialized the configuration using NINearbyAccessoryConfiguration(accessoryData:bluetoothPeerIdentifier:) for background mode. Started the session with NISession.run(configuration). Waited for updates in the delegate method session(_:didUpdate:). Specific questions: Are there additional requirements for using init(accessoryData:bluetoothPeerIdentifier:) to enable background UWB ranging with the DWM3001CDK? Is there a known difference in how init(data:) and init(accessoryData:bluetoothPeerIdentifier:) handle the ranging process? Any advice or insights would be greatly appreciated. Thanks in advance!
Replies
1
Boosts
0
Views
649
Activity
Mar ’25
Using Google Maps in App to determine distance
So far, we have been using Google Maps to determine distance along a certain route for a MacOS app to register kilometers for a business administration app. But, this is no longer possible, as the login for google maps no longer works. I understand we would have to pay to continue using the Google Maps service as it was and we would have to make changes to the app. That would be ok, but I was just wondering does any developer on this forum have suggestions on how to resolve this issue? Or even maybe have suggestions, to make this work better than before. Three suggestions by chatgpt: use ANWB route planner using google maps, Pro6pp, or to useWisp.Software (something I haven't heard of before. Your suggestions and ideas are welcome. Also, if the Apple Developer team knows of a way how to do this in your app, your advice is more than welcome. Have a nice day!
Replies
2
Boosts
0
Views
837
Activity
Feb ’25
NIERROR_ACCESSORY_PEER_DEVICE_UNAVAILABLE_DESCRIPTION (Code=-5882) occurs when running NISession for Nearby Interaction.
Overview I am running a NearbyInteaction sample. Immediately after niSession.run(configuration!), func session(_ session: NISession, didInvalidateWith error: Error) is executed. The error is as follows, but I cannot find the cause. Error: bluetoothPeerIdentifier: AF5ADDC1-F731-7BAD-E8C5-9230E79F8C1A Session Invalidation Error: NIERROR_ACCESSORY_PEER_DEVICE_UNAVAILABLE_DESCRIPTION Error Details:Error Domain=com.apple.NearbyInteraction Code=-5882 "NIERROR_ACCESSORY_PEER_DEVICE_UNAVAILABLE_DESCRIPTION" UserInfo={NSLocalizedRecoverySuggestion=NIERROR_ACCESSORY_PEER_DEVICE_UNAVAILABLE_RECOVERY_SUGGESTION, NSLocalizedDescription=NIERROR_ACCESSORY_PEER_DEVICE_UNAVAILABLE_DESCRIPTION, NSLocalizedFailureReason=NIERROR_ACCESSORY_PEER_DEVICE_UNAVAILABLE_FAILURE_REASON} The sample application worked well at first. I want the application to run in the background, so I made the following changes and had problems. Before change: configuration = try NINearbyAccessoryConfiguration(data: configData) After change: configuration = try NINearbyAccessoryConfiguration( accessoryData: configData, bluetoothPeerIdentifier: peerIdentifier) I see no problem with the application. It works fine on device A. The problem occurs on device B. Device A: NXP QN9090 - NXP SR150 Device B: Nordic nRF52840 - NXP SR150 I have confirmed that the device shows up in the settings app after pairing & bonding the device. I have confirmed that the iPhone and nRF52840 are still connected to the BLE without any problems when the error occurs. Initialization code for NearbyInteraction: func setupAccessory(_ configData: Data, name: String) { updateInfoLabel(with: "Received configuration data from '\(name)'. Running session.") do { guard let discoveredPeripheral = dataChannel.getDiscoveredPeripheral() else { return } let peerIdentifier = discoveredPeripheral.identifier configuration = try NINearbyAccessoryConfiguration( accessoryData: configData, bluetoothPeerIdentifier: peerIdentifier) } catch { // Stop and display the issue because the incoming data is invalid. // In your app, debug the accessory data to ensure an expected // format. updateInfoLabel( with: "Failed to create NINearbyAccessoryConfiguration for '\(name)'. Error: \(error)" ) return } // Cache the token to correlate updates with this accessory. cacheToken(configuration!.accessoryDiscoveryToken, accessoryName: name) niSession.run(configuration!) } Environment Xcode 16.1 iPhone11 (iOS 17.6.1) Target UWB Chip: NXP SR150 Sample iOS Application: https://developer.apple.com/documentation/nearbyinteraction/implementing-spatial-interactions-with-third-party-accessories
Replies
1
Boosts
0
Views
668
Activity
Feb ’25