Hello, I am a Bluetooth Engineer at Google investigating an interoperability bug between an Android device and AirPods 4. When requesting an L2CAP connection (with PSM = AVDTP) to the AirPods during SDP service discovery, The AirPods L2CAP layer incorrectly responds with a "refused - no resources available" status followed by a Pending status and a Success status. This violates the specification, which says that the request has been fully rejected after the refused status and should not receive followup responses. I suspect the "no resources available" response is a bug. This prevents A2DP from working with the AirPods. This bug does not exist with AirPods 2 firmware. Here is a packet capture: 1602 1969-12-31 16:07:04.805261 0.062473 localhost () Apple_6b:db:09 (AirPods) L2CAP 17 Sent Connection Request (AVDTP, SCID: 0x22c6) 1603 1969-12-31 16:07:04.810953 0.005692 controller host HCI_EVT 8 Rcvd Number of Completed Packets 1604 1969-12-31 16:07:04.811078 0.000125 Apple_6b:db:09 (AirPods) localhost () SDP 27 Rcvd Service Search Attribute Request : Device Information: [Bluetooth Profile Descriptor List 0x0009] 1605 1969-12-31 16:07:04.821249 0.010171 localhost () Apple_6b:db:09 (AirPods) SDP 19 Sent Service Search Attribute Response 1606 1969-12-31 16:07:04.876396 0.055147 controller host HCI_EVT 8 Rcvd Number of Completed Packets 1607 1969-12-31 16:07:04.876464 0.000068 Apple_6b:db:09 (AirPods) localhost () L2CAP 21 Rcvd Connection Response - Refused - no resources available (SCID: 0x22c6) 1608 1969-12-31 16:07:04.942539 0.066075 Apple_6b:db:09 (AirPods) localhost () SDP 41 Rcvd Service Search Attribute Request : Unknown: [Bluetooth Profile Descriptor List 0x0009] 1609 1969-12-31 16:07:04.951052 0.008513 localhost () Apple_6b:db:09 (AirPods) SDP 19 Sent Service Search Attribute Response 1610 1969-12-31 16:07:05.010605 0.059553 controller host HCI_EVT 8 Rcvd Number of Completed Packets 1611 1969-12-31 16:07:05.080593 0.069988 Apple_6b:db:09 (AirPods) localhost () SDP 27 Rcvd Service Search Attribute Request : GATT: [Bluetooth Profile Descriptor List 0x0009] 1612 1969-12-31 16:07:05.087636 0.007043 localhost () Apple_6b:db:09 (AirPods) SDP 19 Sent Service Search Attribute Response 1613 1969-12-31 16:07:05.209417 0.121781 controller host HCI_EVT 8 Rcvd Number of Completed Packets 1614 1969-12-31 16:07:05.279491 0.070074 Apple_6b:db:09 (AirPods) localhost () L2CAP 21 Rcvd Connection Response - Pending (SCID: 0x22c6) 1615 1969-12-31 16:07:05.280731 0.001240 Apple_6b:db:09 (AirPods) localhost () L2CAP 21 Rcvd Connection Response - Success (SCID: 0x22c6, DCID: 0x0406) Please file this bug with the AirPods Bluetooth team.

Right now, I am scanning for specific BLE peripherals with my iPad app, using this: [self.cbCentralManager scanForPeripheralsWithServices:serviceUUIDsToScanFor options:@{CBCentralManagerScanOptionAllowDuplicatesKey:@YES}]; I have the "CBCentralManagerScanOptionAllowDuplicatesKey" set true because I need to be able to detect when a peripheral is no longer advertising, so I capture each "didDiscoverPeripheral" callback and set a 3-second timer that notifies the user that that peripheral is no longer in range if another didDiscoverPeripheral hasn't been received in that time. The peripherals all advertise at 100ms intervals. What's weird is that if I leave the scan on for a long time, the advertising packets slow down, and eventually one of those timers times out, around about one or two minutes for the first instance, and then every 10-20 seconds after that. I've checked with ATS for all the BLE traffic, and there are indeed > 3-second gaps in the advertising packets that the iPad sees, so it's not my code introducing the gap. Is there some reason long-running scans should not be done on iPadOS (both 18 and 26.1 used)? I've tested out switching my scan to "stopScan" and restart it every 10 seconds, and that seems to have resolved the issue, but it's unclear why that would matter (and that does not seem like an appropriate use of the stop and start scans). Thanks!

Hi all, I’m facing a device-specific issue in a live production iOS app distributed privately via the App Store . The app crashes immediately after login on one client’s iPhone, while the same account works fine on other devices. There’s no crash log generated in Analytics, and the app just pops to the home screen. Environment: App: Production app on App Store iOS version: 26.3 Devices: Only one device exhibits the crash; other iPhones work fine Login flow: App calls an API and writes the response to a local SQLite database immediately after login Distribution: App Store (Privately). The user is install via the redemption codes. Observations: All users on the problematic device crash immediately after login. The crash does not occur on any other devices, including the same iOS version. The client had already uninstalled and reinstalled the app via App Store cloud download, but the crash persisted. No crash log appears in Analytics or Xcode (process just terminates). Device restart had not been attempted before reinstall. App does not use Keychain tokens; local DB is only SQLite in the app sandbox. Hypotheses so far: Corrupted binary or cached app installation on that device SQLite database corruption or write failure Device-specific OS/environment issue (temp files, file locks, provisioning) iOS watchdog silently terminating the app during post-login DB write Language / region differences unlikely Questions: Is it possible for a device to retain a corrupted app binary or cached installation even after uninstall + cloud download reinstall from the App Store? Can uninstalling, restarting the device, and reinstalling guarantee a fresh binary and sandbox? Are there any known iOS behaviors where a local SQLite write could trigger an instant crash on one device only, without generating crash logs? Any other suggestions for diagnosing this device-specific post-login crash in a live production environment? Thanks in advance for any guidance — this issue is affecting a client’s live usage, and we’d like to understand the root cause and best way to resolve it safely.

Hello Apple Developer Technical Support Team, I’m working on an iOS banking/security SDK and we’re trying to match an Android feature that reads payment cards via NFC (EMV). On Android, this is implemented using an NFC scanning screen (e.g., “NfcScanActivity”) that can read EMV data from contactless credit/debit cards. Could you please clarify the current iOS capabilities and App Store policy around this? On iOS, is it currently possible for a third-party App Store app to read contactless credit/debit cards using Core NFC (i.e., accessing EMV application data/AIDs from payment cards)? If this is possible, what are the supported APIs/frameworks and any entitlement requirements (if applicable)? If this is not possible for App Store apps, could you recommend the closest acceptable alternatives for achieving a similar user outcome? For example: Using Apple Pay / PassKit flows for payment-related experiences Card scanning alternatives (camera-based OCR) for capturing card details (if allowed) Using an external certified card reader accessory (MFi) and required approach/entitlements Any other Apple-recommended approach for “card verification / identification” without reading EMV NFC data Our goal is not to bypass security restrictions, but to provide a compliant solution on iOS comparable to Android’s NFC-based card reading, or to adopt an Apple-approved alternative if direct EMV reading is not supported. If helpful, I can share a brief technical summary of the Android behavior and the exact data we need to obtain (e.g., whether it’s card presence verification vs. reading specific EMV tags). Thank you for your guidance. Best regards, Imran

Hello Apple Developer Technical Support Team, I’m working on an iOS banking/security SDK and we’re trying to match an Android feature that reads payment cards via NFC (EMV). On Android, this is implemented using an NFC scanning screen (e.g., “NfcScanActivity”) that can read EMV data from contactless credit/debit cards. Could you please clarify the current iOS capabilities and App Store policy around this? On iOS, is it currently possible for a third-party App Store app to read contactless credit/debit cards using Core NFC (i.e., accessing EMV application data/AIDs from payment cards)? If this is possible, what are the supported APIs/frameworks and any entitlement requirements (if applicable)? If this is not possible for App Store apps, could you recommend the closest acceptable alternatives for achieving a similar user outcome? For example: Using Apple Pay / PassKit flows for payment-related experiences Card scanning alternatives (camera-based OCR) for capturing card details (if allowed) Using an external certified card reader accessory (MFi) and required approach/entitlements Any other Apple-recommended approach for “card verification / identification” without reading EMV NFC data Our goal is not to bypass security restrictions, but to provide a compliant solution on iOS comparable to Android’s NFC-based card reading, or to adopt an Apple-approved alternative if direct EMV reading is not supported. If helpful, I can share a brief technical summary of the Android behavior and the exact data we need to obtain (e.g., whether it’s card presence verification vs. reading specific EMV tags). Thank you for your guidance. Best regards, Anis

EASession(accessory:forProtocol:) always returns nil — MFI accessory iAP2 Platform: iOS 17+ | Hardware: Custom MFI-certified accessory (USB-C, iAP2) | Language: Swift Problem We have a custom MFI-certified accessory communicating over USB-C using ExternalAccessory. The app calls EASession(accessory:forProtocol:) after receiving EAAccessoryDidConnect but it always returns nil. We never get past session creation. What we have verified We captured a sysdiagnose on-device and analysed the accessoryd-packets log. The full iAP2 handshake completes successfully at the OS level: USB attach succeeds MFI auth certificate is present and Apple-issued Auth challenge and response complete successfully IdentificationInformation is accepted by iOS — protocol string and Team ID are correct EAAccessoryDidConnect fires as expected iOS sends StartExternalAccessoryProtocolSession — the OS-level session is established So the hardware, MFI auth, protocol string, and Team ID are all correct. Despite this, EASession(accessory:forProtocol:) returns nil in the app. We also confirmed: Protocol string in UISupportedExternalAccessoryProtocols in Info.plist matches the accessory exactly Protocol string in code matches Info.plist App entitlements are correctly configured EAAccessoryManager.shared().registerForLocalNotifications() is called before connection Current connection code @objc private func accessoryDidConnect(_ notification: Notification) { guard let accessory = notification.userInfo?[EAAccessoryKey] as? EAAccessory else { return } DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) { self.tryConnectToAccessory() } } private func tryConnectToAccessory() { DispatchQueue.main.asyncAfter(deadline: .now() + 3.0) { for accessory in EAAccessoryManager.shared().connectedAccessories { let session = EASession(accessory: accessory, forProtocol: "") // session is always nil here } } } Questions The packet log shows a ~4 second gap between EAAccessoryDidConnect firing and iOS internally completing session readiness (StartExternalAccessoryProtocolSession). Is there a reliable way to know when iOS Is it actually ready to grant an EASession, rather than using a fixed delay? Is there a delegate callback or notification that fires when the accessory protocol session is ready to be opened, rather than relying on EAAccessoryDidConnect + an arbitrary delay? Are there any known conditions on iOS 17+ under which EASession returns nil even though the iAP2 handshake completed successfully at the OS level? Is retrying EASession after a nil result a supported pattern, or does a nil result mean the session will never succeed for that connection? Any guidance appreciated.

目前这个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?