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.

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.

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.