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.

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

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?

as i want to tract activity of iphone user using core motion framework , guide me through .

Hello everybody, I have a never ending issue with appstore review, an need a QUICK HELP ! I am submitting a new app (oral training), for Iphones only. I disabled other devices (such as Ipas) via Xcode. In the appstore informations form, it is obligatory to provide ipad screens, so I provided screens showing Iphone experience. Appstore team asked me to remove it because I don't authorize Ipads. But if I remove those screens, form cannot be sent. I don't understantd how to proceed. Thanks for the help Regards Jean

Will UVC native support come for the Iphone as well? So, using external cameras with the ipad is greatly beneficial, but for the iphone, it can make it a production powerhouse! So, have there been discussions around bringing UVC support for the Iphone as well? and if so, what were your conclusions?

Dear Sir, I have some questions of IC firmware development of Find My. Any rule request that item must include dual bank feature in IC? I am using Nordic SDK_Connect SDK, Apple has own SDK? If yes, can I download it to use? In Find-My, Apple has service UUID in bluetooth IC? Thank you. Best regards, Sam Ng

Hey everyone, how’s it going? I’d like to know if, by enrolling in Apple’s MFi program, I’ll gain access to develop my own tags and my own app to track them using Apple’s Find network. I also read that there’s an estimated cost of $4 per device—does that apply to each device produced, or only at the time of registering the device, with no fee for additional units?

How to remove Matter accessory connection artefacts? This appears after connecting and then removing a Matter test accessory. Please see attached screenshot:

when I go to software and update it says can’t check for updateS.

I updated my iPhone to 26 and I just went to to to see if my iPhone was up to date I went and see but a came across this

Hi everyone, while testing HKWorkoutSession with HKLiveWorkoutBuilder on iOS 26 Beta (cycling workout), I noticed the following behavior: – Starting a cycling HKWorkoutSession automatically connects to my Bluetooth heart rate monitor and records HR into HealthKit ✅ – However, my Bluetooth cycling power meter and cadence sensor (standard BLE Cycling Power & CSC services) are not connected automatically, and no data is recorded into HealthKit ❌ On Apple Watch, when starting a cycling workout, these sensors do connect automatically and their data is written to HealthKit — which is exactly what I would expect on iOS as well. Question: Is this by design, or is support for power and cadence sensors planned for iOS in the same way as on watchOS? Or do we, as developers, need to implement the BLE Cycling Power and CSC profiles ourselves (via CoreBluetooth) if we want these metrics? Environment: – iOS 26 Beta – HKWorkoutSession & HKLiveWorkoutBuilder (cycling) – Bluetooth HRM connects automatically – BLE power & cadence sensors do not This feature would make it much easier to develop cycling apps with full HealthKit integration, and also create a more consistent user experience compared to watchOS. Thanks for any insights!

I am developing an app that communicates with external BLE device over GATT. The device has a secure-read characteristic exposing some of it's data and requires pairing/bonding in order to communicate with it. I was able to pair and connect with the device using AccessorySetupKit and .bluetoothPairingLE option: let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = CBUUID(string: serviceUUID) descriptor.supportedOptions = [.bluetoothPairingLE] let picketItem = ASPickerDisplayItem(name: name, productImage: image, descriptor: descriptor) In this case when setting up accessory, I was prompted to compare passkeys and after confirming I can read the characteristic etc. Then I tried adding .confirmAuthorization to picker item and problems started: let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = CBUUID(string: serviceUUID) descriptor.supportedOptions = [.bluetoothPairingLE] let picketItem = ASPickerDisplayItem(name: name, productImage: image, desc pickerItem.setupOptions = [.confirmAuthorization] When setting up, I can see a passkey to be confirmed, but when confirmed the setup ui get's suck in loading state. Under the hood in logs, I can see that my app has connected to peripheral and was able to read the characteristic. I am unsure why the ui is stuck in loading state in this case. What is the difference when using .confirmAuthorization option and what should be the proper flow of events to setup accessory and then access protoected characteristic?

Dear Apple Developer / MFi Program Support, I am exploring technical possibilities for screen sharing and remote interaction between iOS devices and external hardware (e.g., embedded systems, in-vehicle systems) for a prototype we are currently developing. I have reviewed the public iOS developer documentation, but I would appreciate your guidance and clarification on the following advanced use cases, particularly in the context of MFi or enterprise-level integrations: Full-Screen Sharing of iOS Device Is it possible to mirror or stream the entire iOS screen, even when the app is running in the background or not in the foreground? Does ReplayKit or any other framework under the MFi or enterprise entitlements allow full-device screen capture outside the app context? Remote Touch Injection and Control Is there any officially supported mechanism, under MFi or otherwise, that allows external systems to remotely control an iOS device’s touch interface (e.g., simulate gestures, taps, swipes)? Are any of the following permitted under special entitlements: Access to IOHIDEventSystem or similar private APIs for input injection? Communication over USB or network to relay control commands that simulate direct user interaction? Hardware-Level Integration and Entitlements Does the MFi Program allow: Use of private frameworks or entitlements to build low-level integrations for iOS device control or mirroring? Communication over USB/Lightning/USB-C to enable bi-directional interaction (streaming out, commands in)? What are the specific APIs or entitlements available under MFi that enable these use cases? Can you provide references to documentation, SDKs, or prerequisites for companies seeking such capabilities? Eligibility and Certification Process What are the criteria to be approved for the MFi program with access to such advanced capabilities? Can PoC or early-stage research prototypes be eligible, or is MFi access restricted to commercial production intent? How long does it typically take to gain access to these entitlements (assuming NDA and certification requirements are met)? Alternative Pathways If MFi access is not feasible in the short term, is there any Apple-supported alternative path (e.g., test device provisioning, enterprise signing, custom profiles) that permits more advanced capabilities for prototyping purposes? We are not looking to publish this as a general App Store app at this stage, but rather to demonstrate feasibility as part of an innovation prototype that may lead to further OEM-level engagement in the future. Thank you for your support and guidance. Best regards,

Hello, The application I'm working on must report new hardware connections. To retrieve connected displays information and monitor new connections, I'm using the "Core Graphics" framework (see recommendation https://developer.apple.com/forums/thread/779945). The monitoring logic relies on a callback function which invokes when the local display configuration changes(kCGDisplayAddFlag/kCGDisplayRemoveFlag). #import <Cocoa/Cocoa.h> static void displayChanged(CGDirectDisplayID displayID, CGDisplayChangeSummaryFlags flags, void *userInfo) { uint32_t vendor = CGDisplayVendorNumber(displayID); if (flags & kCGDisplayAddFlag) { if (vendor == kDisplayVendorIDUnknown) { NSLog(@"I/O Kit cannot identify the monitor. kDisplayVendorIDUnknown. displayId = %u", displayID); return; } NSLog(@"%u connected. vendor(%u)", displayID, vendor); } if (flags & kCGDisplayRemoveFlag) { NSLog(@"%u disconnected", displayID); } } int main(int argc, const char * argv[]) { @autoreleasepool { CGDisplayRegisterReconfigurationCallback(displayChanged, NULL); NSApplicationLoad(); CFRunLoopRun(); } return 0; } The test environment is a Mac mini with an external display connected via HDMI. Everything works correctly until the system enters sleep mode. Upon wakeup, the app reports two displays: the first with vendor ID kDisplayVendorIDUnknown and the second with the expected vendor ID. Why does Core Graphics report two connections during wakeup? Is there any way to avoid this? Thank you in advance.

I am working on an app that requires the usage of CoreBluetooth – using both its CBPeripheralManager and CBCentralManager classes. Our app works with other phones and hardware peripherals to exchange data – so we wanted to explore adding AccessorySetupKit to streamline the hardware connection process. AccessorySetupKit has been integrated (while CBPeripheralManager is turned off) and works great, but even with ASK added to our app's plist file and not in use, CBPeripheralManager fails with error: Cannot create a CBPeripheralManager while using AccessorySetupKit framework. Is there any workaround or suggested path forward here? We'd still really like to use ASK while keeping our existing functionality, but are not seeing a clear way to do so.

I have some logic which requires NFC support on the device. This is what I'm using to make sure that it's available: isNFCMissing = !NFCNDEFReaderSession.readingAvailable && !NFCTagReaderSession.readingAvailable && !NFCVASReaderSession.readingAvailable Is it possible for isNFCMissing to be true even if the device has an NFC chip. The minimum iOS version for the application is 16 which is only supported on devices with an NFC chip to begin with.

Hi everyone, I am developing a .NET MAUI Mac Catalyst app (sandboxed) that communicates with a custom vendor-specific HID USB device. Within the Catalyst app, I am using a native iOS library (built with Objective-C and IOKit) and calling into it via P/Invoke from C#. The HID communication layer relies on IOHIDManager and IOUSBInterface APIs. The device is correctly detected and opened using IOHIDManager APIs. However, IOHIDDeviceRegisterInputReportCallback never triggers — I don’t receive any input reports. To investigate, I also tried using low-level IOKit USB APIs via P/Invoke from my Catalyst app, calling into a native iOS library. When attempting to open the USB interface using IOUSBInterfaceOpen() or IOUSBInterfaceOpenSeize(), both calls fail with: kIOReturnNotPermitted (0xe00002e2). — indicating an access denied error, even though the device enumerates and opens successfully. Interestingly, when I call IOHIDDeviceSetReport(), it returns status = 0, meaning I can successfully send feature reports to the device. Only input reports (via the InputReportCallback) fail to arrive. I’ve confirmed this is not a device issue — the same hardware and protocol work perfectly under Windows using the HIDSharp library, where both input and output reports function correctly. What I’ve verified •Disabling sandboxing doesn’t change the behavior. •The device uses a vendor-specific usage page (not a standard HID like keyboard/mouse). •Enumeration, open, and SetReport all succeed — only reading input reports fails. •Tried polling queues, in queues Input_Misc element failed to add to the queues. •Tried getting report in a loop but no use.

Problem Description: Since Our USB hubs are capable of sending Vendor Defined Messages (VDMs) over a USB Type-C cable connection, they can programmatically place iOS, iPadOS, and macOS devices into DFU mode—without requiring any physical button interaction. Recently, we identified an issue when invoking DFU mode on an iPhone 15 using this method. Upon entering DFU mode, the device enumerates with USB Product ID 0x1881 (“Debug USB” – KIS interface). At that point, the deviceinterfaced daemon (launched by launchd) immediately detects the device and claims exclusive access to the USB interface. As a result, when our API Service attempts to communicate with the device through standard IOKit methods, it fails with the following error: 0xe00002c5 ((iokit/common) exclusive access and device already open) This prevents our libraries from reading the iBoot string (USB serial number string) that Apple devices normally expose in standard or recovery modes—information that includes ECID, CPID, CPRV, CPFM, BDID, and SCEP. This creates a significant barrier, as our API service becomes unable to perform subsequent device restoration operations as we missed the critical information. Request for Guidance: I’ve included the following context for your analysis and review. Using the launchctl unload command can temporarily stop it; however, I’d like to know if there’s an API-level mechanism to programmatically prevent deviceinterfaced from claiming access from within our API Service. Could you please advise on the following points? 1.  Managing deviceinterfaced Access • What is the proper way to stop or prevent deviceinterfaced from claiming exclusive access in this case, so that the API Service can read device information and starts restoring the device from that point? • Is there a recommended method or entitlement that allows third-party services to communicate with Apple devices while they are in Debug USB (KIS) mode? 2.  Guidelines and API Access • Are there any Apple-supported APIs or developer guidelines that would permit controlled access to the iBoot interface without conflicting with deviceinterfaced?

I have an iOS/iPadOS app and 'm trying to communicate with usb smart card reader using CryptoTokenKit on all platforms (ios/ipados/macos). Minimal Repro Code import CryptoTokenKit import SwiftUI struct ContentView: View { @State var status = "" var body: some View { VStack { Text("Status: \(status)") } .padding() .onAppear { let manager = TKSmartCardSlotManager.default if manager != nil { status = "Initialized" } else { status = "Unsupported" } } } } And my entitlement file has only one key: com.apple.security.smartcard = YES Behavior • iPadOS (on device): status = "Initialized" ✅ • macOS (native macOS app, with the required CryptoTokenKit entitlement): status = "Initialized" ✅ • macOS (Designed for iPad, regardless of CryptoTokenKit entitlement): status = "Unsupported" → TKSmartCardSlotManager.default is nil ❌ Expectation Given that the same iPadOS build initializes TKSmartCardSlotManager, I expected the iPad app running in Designed for iPad mode on Apple silicon Mac to behave the same (or to have a documented limitation). Questions Is CryptoTokenKit (and specifically TKSmartCardSlotManager) supported for iPad apps running on Mac in Designed for iPad mode? If support exists, what entitlements / capabilities are required for USB smart-card access in this configuration? If not supported, is Mac Catalyst the correct/only path on macOS to access USB smart-card readers via CryptoTokenKit? Are there recommended alternatives for iPad apps on Mac (Designed for iPad) to communicate with USB smart-card readers (e.g., ExternalAccessory, DriverKit, etc.), or is this scenario intentionally unsupported? Thanks!