We are currently planning to develop a third‑party hardware accessory that supports Wi‑Fi Aware using AccessorySetupKit on iOS, based on the official documentation: https://developer.apple.com/documentation/accessorysetupkit/ Before finalizing our hardware and firmware design, we would like to better understand the real‑world behavior and user experience of Wi‑Fi Aware in actual third‑party accessories. Specifically, we would like to ask: Existing Third‑Party Hardware Are there any commercially available third‑party accessories (not Apple products) that already support Wi‑Fi Aware via AccessorySetupKit? If so, are there any public examples, reference designs, or recommended products we can purchase to observe the real onboarding, discovery, and pairing experience? Reference or Evaluation Hardware Does Apple provide any reference hardware, evaluation kits, or recommended vendor solutions (for example, based on common Wi‑Fi chipsets) that are known to work well with Wi‑Fi Aware on iOS? Are there specific Wi‑Fi chipset vendors that have validated interoperability with AccessorySetupKit? Practical Behavior and Limitations In real usage, what are the typical discovery latency, reliability, and background/foreground behavior developers should expect? Are there known limitations or best practices when designing hardware that relies on Wi‑Fi Aware for initial accessory discovery and setup? Our goal is to evaluate the feasibility and user experience of Wi‑Fi Aware for third‑party accessories by testing against existing implementations or recommended hardware, before investing heavily in custom hardware development. Any guidance, examples, or pointers to existing accessories or partners would be greatly appreciated.

Hi, We are facing the issue of commissioning our Matter device to google home through iOS device will be 100% failed. Here is our test summary regarding the issue: TestCase1 [OK]: Commissioning our Matter 1.4.0 device to Google Nest Hub 2 by Android device (see log DoorWindow_2.0.1_Google_Success.txt ) TestCase2 [NG]: Commissioning Matter 1.4.0 device to Google Nest Hub 2 by iPhone13 or iPhone16 (see log DoorWindow_2.0.1_Google_by_iOS_NG.txt ) TestCase3 [OK]: Commissioning our Matter 1.3.0 device to Google Nest Hub 2 by iPhone13 In TestCase2, we noticed that device was first commissioned to iOS(Apple keychain) then iOS opened a commissioning window again to commission it in Google’s ecosystem, and the device was failed at above step 2, so we also tried: Commissioning the device to Apple Home works as expected, next share the device to Google Home app on iOS, this also fails. Commissioning the device to Apple Home works as expected, next share the device to Google Home app on Android, this works as expected and device pops up in Google home of iOS as well. Could you help check what's the issue of TestCase2? Append the environment of our testing: NestHub 2 version Google Home APP version

Hi, We are facing the issue of commissioning our Matter device to google home through iOS device will be 100% failed. Here is our test summary regarding the issue: TestCase1 [OK]: Commissioning our Matter 1.4.0 device to Google Nest Hub 2 by Android device (see log DoorWindow_2.0.1_Google_Success.txt ) TestCase2 [NG]: Commissioning Matter 1.4.0 device to Google Nest Hub 2 by iPhone13 or iPhone16 (see log DoorWindow_2.0.1_Google_by_iOS_NG.txt ) TestCase3 [OK]: Commissioning our Matter 1.3.0 device to Google Nest Hub 2 by iPhone13 In TestCase2, we noticed that device was first commissioned to iOS(Apple keychain) then iOS opened a commissioning window again to commission it in Google’s ecosystem, and the device was failed at above step 2, so we also tried: Commissioning the device to Apple Home works as expected, next share the device to Google Home app on iOS, this also fails. Commissioning the device to Apple Home works as expected, next share the device to Google Home app on Android, this works as expected and device pops up in Google home of iOS as well. Could you help check what's the issue of TestCase2? Append the environment of our testing: NestHub 2 version Google Home app version

Hello, We are developing an iAP2 accessory and encountering an issue during the Identification phase. Issue: Authentication: ✅ Successful Identification: ❌ IdentificationInformation rejected (0x1D03) Product Plan Status: "Submitted" (in MFi Portal) What we've verified: ProductPlanUID matches MFi Portal All required parameters per R43 Table 101-9 are included Parameters are in ascending order by ID Message format appears correct Observation: iPhone accepts the message format but still rejects IdentificationInformation, suggesting the issue may be related to Product Plan configuration or status rather than parameter format. Questions: Can a Product Plan with status "Submitted" complete iAP2 identification, or does it need to be "Approved"? Are there any Product Plan configuration requirements that might not be visible in MFi Portal? Should we configure "Control Message Lists" in Product Plan? (We don't see this option in Portal) We can provide additional technical details through secure channels if needed. Thank you for your assistance.

When trying to use the MIDI Maestro app by Singular Sound, BLE peripherals experience unwanted connection-parameter renegotiation and disconnections on iOS 26, beta iOS 26.2 does not fix this issue. iOS 26 BLE communications are being sent too fast to be read correctly by the hardware device, and iOS 26.2 refuses communication altogether.

Title iOS App detecting external USB mass storage connection without user interaction Background We are developing an iOS application that connects to an action camera device via Bluetooth and Wi-Fi for control and data transfer. In addition to wireless connectivity, our product requirements include supporting USB Mass Storage mode, where the camera (or a generic USB flash drive) is connected to an iPhone using a Lightning / USB-C adapter and appears in the Files app as an external drive. Requirement Our app needs to detect when an external USB mass storage device is connected or disconnected, with the following constraints: The app is already running in the foreground No user interaction is performed (no button tap, no document picker, no import UI) The USB device can be: A generic USB flash drive An empty USB drive (no photos or videos) The app only needs to know: Whether an external USB storage device has been connected or removed No need to access device identity, vendor info, or low-level USB details The expected behavior is simply to update the app’s internal state or UI when a USB storage device becomes available. Investigation Performed We have already investigated and tested the following public and documented approaches, all of which did not provide a reliable or any notification for USB mass storage insertion: ExternalAccessory / MFi Not applicable for generic USB storage devices Darwin notifications / CoreFoundation Using notify_register_dispatch and CFNotificationCenterGetDarwinNotifyCenter System USB / storage related notifications do not fire for third-party apps File system APIs NSFileManager mountedVolumeURLsIncludingResourceValuesForKeys On iPhone, external USB drives visible in the Files app are not exposed as mounted volumes to third-party apps FileProvider / DocumentPicker Only provides access after explicit user interaction No background or passive notification of availability ImageCaptureCore Limited to PTP camera devices Does not apply to generic USB mass storage Based on our testing, none of the public APIs provide a way to detect USB mass storage insertion automatically without user interaction. Question to Apple We would like to confirm the official platform behavior and capability boundary: Is there any public, documented, App Store–approved API on iOS that allows a third-party app to be notified when a generic USB mass storage device is connected or disconnected, without user interaction? If not: Is this limitation intentional by platform design? Is the recommended approach to rely exclusively on user-initiated document access flows (e.g. document picker, import UI)? Are there any recommended best practices for apps that need to update their UI or internal state based on the availability of external USB storage devices? Our goal is to ensure that our implementation fully complies with iOS platform guidelines and App Store Review requirements. Environment iOS versions tested: iOS 18 (latest public release) Devices: iPhone models with Lightning / USB-C USB devices: generic USB flash drives (including empty drives) Closing We appreciate clarification on whether this capability is intentionally restricted on iOS and how Apple recommends designing user experience around external USB storage access. Thank you for your guidance.

where can i get apple's all device hardware vid and pid ?

iOS 26.2 Beta 23C5044b Phone's battery reports 0% Health, leaving it on multiple chargers (high/low wattage) doesn't change anything. Icon changes to charging. Changed the battery with a high quality aftermarket of ~70% charge, same issue. Unable to remove beta or update to RC2 due to the 20% minimum required... not sure what to do.

I have poked around the web looking for a good example to do this and I haven't found a working example. I need to connect to a USB Device, its multiple ports and supports what looks to be a root port and 4 other ports I am no expert in USB but I do know how to write a kext and client drivers, but thats really not the way to solve this. I need to display the serialized output from these USB ports for a development board. I would rather do this on my Mac than have to cobble up a Linux machine and mess around with Linux. Here is the output from ioreg MCHP-Debug@03100000 <class IOUSBHostDevice, id 0x105f6fdc2, registered, matched, active, busy 0 (20 ms), retain 27> MCHP-Debug@0 <class IOUSBHostInterface, id 0x105f6fdc8, registered, matched, active, busy 0 (13 ms), retain 5> +-o MCHP-Debug@0 <class IOUSBHostInterface, id 0x105f6fdc8, registered, matched, active, busy 0 (13 ms), retain 5> +-o MCHP-Debug@1 <class IOUSBHostInterface, id 0x105f6fdc9, registered, matched, active, busy 0 (11 ms), retain 5> +-o MCHP-Debug@2 <class IOUSBHostInterface, id 0x105f6fdcb, registered, matched, active, busy 0 (9 ms), retain 5> | | | | | +-o MCHP-Debug@3 <class IOUSBHostInterface, id 0x105f6fdcc, registered, matched, active, busy 0 (7 ms), retain 5> I have been able to open a inservice to the device at the top level, but I get an error when I use. usbHostInterface = [[IOUSBHostInterface alloc] initWithIOService:usbDevice options: IOUSBHostObjectInitOptionsNone queue: queue error: &error interestHandler: handler]; Error:Failed to create IOUSBHostInterface. with reason: Unable to obtain configuration descriptor. Assertion failed: (usbHostInterface), function main, file main.m, line 87. I started using DeviceKit but I received signing errors and I shouldn't have to go down that path just to dump data from a USB port? Any suggestions would be great, most of the Apple documentation on USB ports is like 20 years old and the new stuff pushes you towards DeviceKit.

We have developed an accessory that supports Find My. When using the Find My app to set it up, it occasionally gets stuck at the final " setting up"" interface. The app just stays like that. We would like to know what could cause this situation and how to resolve it. Thanks a lot.

We have an app that connects to an external device that we developed in-house that measures electroencephalography (EEG), as well as PPG and IMU. This is not a medical device and we have stated that many times but the app review process keeps rejecting the app for the same reason 1.4.1 - Safety physical harm because they say it is connecting to a medical device. We have submitted documentation for FCC certification for safety but we do not have FDA certification because it is not used for medical purposes - purely wellness. Despite several messages explaining it is not a medical device the response is always the same without actually addressing any of the supporting documents we have sent. Any help to find a way to explain to the Apple team that not all EEG devices are medical and in fact most are NOT FDA approved would be appreciated as it seems like whoever is reviewing the app doesn't understand that.

Device: iPhone [model], iOS 18.6.2 Xcode: 16.0.x Team: Individual paid Apple Developer Program (not Personal Team), shows as my full name in Xcode I’m trying to use CoreNFC via NFCTagReaderSession in a small SwiftUI app (part of a larger project). So far I’ve done: • Enrolled in the Apple Developer Program (individual). • Confirmed that in Certificates, Identifiers & Profiles → Identifiers, my App ID for com.<…> has Near Field Communication Tag Reading enabled. • Created an iOS App Development provisioning profile for that App ID, including: • my Apple Development certificate • my iPhone device • Downloaded the profile, double-clicked it, and set it in Xcode under Signing & Capabilities with: • Team = my full-name team • “Automatically manage signing” off, using the custom profile. • Added the NFC Scan capability in Signing & Capabilities. • Added Privacy - NFC Scan Usage Description (NFCReaderUsageDescription) in Info.plist with a non-empty string. The app builds and runs on device. When I start the session: func beginScanning() { print("NFCTagReaderSession.readingAvailable =", NFCTagReaderSession.readingAvailable) session = NFCTagReaderSession(pollingOption: [.iso14443, .iso15693], delegate: self, queue: nil) session?.alertMessage = "Hold your iPhone near your Ori tag." session?.begin() } func tagReaderSession(_ session: NFCTagReaderSession, didInvalidateWithError error: Error) { print("NFC session invalidated:", error.localizedDescription) } readingAvailable is false, and I immediately see: NFC session invalidated: Session invalidated unexpectedly Earlier in this process I was seeing XPC sandbox messages like: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.nfcd.service.corenfc was invalidated: failed at lookup with error 159 - Sandbox restriction." Those went away after I created the explicit iOS App Development profile and pointed the target at it, but the session still invalidates right away and readingAvailable never becomes true. Safari can read NDEF URL tags on this device, so the NFC hardware is working. Question: Is there anything else required on the App ID / provisioning / team side to enable CoreNFC with NFCTagReaderSession for an individual (non-enterprise) developer account? Or any known issues where readingAvailable stays false even with NFC Tag Reading enabled and a custom iOS App Development profile? Any hints on what I might still be missing would be greatly appreciated.

Hi, we have developed an application that streams data from two BLE peripherals at a rate of 14.5kbps per peripheral. Until now, our devices streamed in near real time with no lag on all Apple devices with Bluetooth 5.0 or greater. Since the release of the iPhone 17 series and the iPad A16, we have reports from users of the data being streamed at significantly lower rates than expected. Any help here would be greatly appreciated as our customers are being affected by this change.

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!

Im running macOS Tahoe and I have the proper nvram boot-args , however when I try to poke the log stream im not getting any verb information related to the card im using. The audio system im using is AppleHDA.kext from the Beta 1 KDK. I've tried asking AI it doesn't make a difference what it suggests to me..... In the meantime of while im asking for assistance what ill do is go ahead and let it template me a kernel extension that I guess just traffics it to the Log for me and hopefully this isn't filtered out as what I suspect is it saying is happening is is that it actually masks some of the information. Why am I doing this? not For the Linux Driver its so I can see from the Log where it came from as this is what the developer said he did GitHub/davidjo/snd_hda_macbookpro is the kabylake iMac.

Since I updated my iPhone 13 to this new update I have two problems First: the battery discharges too fast or it gets stuck and doesn't discharge until I turn it off and turn it back on. Second: I see in my screen time a page that I had never seen is called imasdk.googleapis.com which I had never occupied and they tell me that it is a failure of the new update I hope you can help me fix that, since this mobile phone is new and already brings the faults by the ios

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?

Hi everyone — I’m developing an iOS passkey/password manager where the private key material must be stored on a physical device (NFC card / USB token). I’m hitting a hard limitation: CoreNFC is not available for use from app extensions, which prevents an appex (e.g. password/credential provider or other extension) from talking directly to an NFC card during an authentication flow.  My questions: 1. Is there any plan to make CoreNFC (or some limited NFC-API) available to app extensions in a future iOS version? If not, could Apple clarify why (security/entitlements/architecture reasons)? 2. Are there any recommended/approved workarounds for a passkey manager extension that needs to access a physical NFC token during authentication? (For example: background tag reading that launches the containing app, or some entitlement for secure NFC card sessions.) I’ve read about background tag reading, but that seems to be about system/OS handling of tags rather than giving extensions direct NFC access.  3. Is the only supported pattern for my use case to have the containing app perform NFC operations and then share secrets with the extension via App Groups / Keychain Sharing / custom URL flow? (I’m already evaluating App Groups / Keychain access groups for secure sharing, but I’d like official guidance.)  Implementation details that may help responders: • Target: iOS (latest SDK), building a Credential Provider / password manager extension (appex). • Intended physical token: NFC smartcard / ISO7816 contactless (so CoreNFC APIs like NFCISO7816Tag would be ideal). • Security goals: private key never leaves the physical token; extension should be able to trigger/sign during a browser/app AutoFill flow. Possible alternatives I’m considering (open to feedback): designing the UX so that the extension opens the main app (only possible for Today widget in a supported way) which runs the NFC flow and stores/returns a short-lived assertion to the extension. Are any of these patterns sanctioned / recommended by Apple for credential providers?  Thanks — any pointers to docs, entitlement names, or example apps/samples would be extremely helpful.

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.

Hi everyone, I submitted an app for review and was met with a rejection for unresolved issues. This was what was asked in the rejection: Provide detailed answers to the following questions: -Does your app interact with any hardware? Would that be referring to the camera/microphone of the device? My app uses haptics when you select an option. I didn't see anything in connect where I needed to specify the use of haptics. Also, does this mean that when the reviewer answers me I have to resubmit as a version 1.1? I'm not sure what I would need to change. This is my first app so I'm not entirely sure on the procedure.