Hi, This is the code snippet in my driver for an usb uart device. I am trying to call standard cdc-acm command to set the Line Coding in the device, but fails with this error: "USBSendSetLineCoding - Failed : 0xe0005000, bytes transferred: 0" I guess the USB device is returning this error due to incorrect buffer or format. There is no proper documentation on how to use IOMemoryDescriptor when the data has to be passed down in a buffer to the usb stack. (IOUSBHostInterface->DeviceRequest()) Can anyone please point out what is wrong with this code and suggest a right method? void MyDriver::USBSendSetLineCoding(uint32_t BaudRate, uint8_t StopBits, uint8_t TX_Parity, uint8_t CharLength) { kern_return_t ret = kIOReturnSuccess; LineCoding *lineParms; uint16_t lcLen = sizeof(LineCoding)-1; lineParms = (LineCoding *)IOMalloc(lcLen); if (!lineParms) { MyDebugLog("USBSendSetLineCoding - allocate lineParms failed"); return; } bzero(lineParms, lcLen); lineParms->bCharFormat = StopBits - 2; lineParms->bParityType = TX_Parity - 1; lineParms->bDataBits = CharLength; OSSwapBigToHostInt32(BaudRate); lineParms->dwDTERate = BaudRate; IOBufferMemoryDescriptor* bufferDescriptor = nullptr; _controlInterface->CreateIOBuffer(kIOMemoryDirectionOut, lcLen, &bufferDescriptor); IOMemoryMap *map = nullptr; bufferDescriptor->CreateMapping(kIOMemoryMapReadOnly, 0, 0, 0, 0, &map); if(map == nullptr) { MyDebugLog("USBSendSetLineCoding - Failed to map memory in CreateMapping\n"); IOFree(lineParms, lcLen); bufferDescriptor->release(); return; } uint64_t ptr = map->GetAddress(); if(!ptr) { MyDebugLog("USBSendSetLineCoding - Failed to get Memory Address\n"); IOFree(lineParms, lcLen); bufferDescriptor->release(); map->release(); return; } memcpy(&ptr, lineParms, lcLen); uint8_t bmRequestType = kIOUSBDeviceRequestDirectionOut | kIOUSBDeviceRequestTypeClass | kIOUSBDeviceRequestRecipientInterface; uint16_t wValue = 0; uint16_t wIndex = _bControlInterfaceNumber; uint16_t bytesTransferred = 0; ret = _controlInterface->DeviceRequest(bmRequestType, kUSBSET_LINE_CODING, wValue, wIndex, lcLen, bufferDescriptor, &bytesTransferred, 1000); IOFree(lineParms, lcLen); map->release(); bufferDescriptor->release(); if (ret != kIOReturnSuccess) { MyDebugLog("USBSendSetLineCoding - Failed : 0x%x, bytes transferred: %d\n", ret, bytesTransferred); return; } return; } I am able to call DeviceRequest() successfully on the same interface for any other setting that requires no data buffer, such as, "ret = _controlInterface->DeviceRequest(bmRequestType, kUSBSEND_BREAK, wValue, wIndex, 0, NULL, &bytesTransferred, 1000);" So I think the "bufferDescriptor" is not properly created or the data is not copied correctly in this function for the failure. "ret = _controlInterface->DeviceRequest(bmRequestType, kUSBSET_LINE_CODING, wValue, wIndex, lcLen, bufferDescriptor, &bytesTransferred, 1000);" Any help is very much appreciated. Thanks in advance.

Starting with iOS 26, we've noticed that the accessoryImage in CPListItem is not working as expected in CarPlay. Previously, accessoryImage would appear in place of the accessoryType, but now it appears awkwardly next to the detailText, and the image itself is not rendering properly. We have submitted feedback to Apple multiple times, but the issue still persists in the latest beta releases. In general, there seem to be several CarPlay UI problems introduced in iOS 26. For example: In CPPointOfInterestTemplate, the pinImage is displayed at an excessively large size. Scroll positions in lists behave unexpectedly. CPInformationTemplate allows infinite scrolling, which seems unintended. Please take a look into these issues. Thank you.

I've made a dext and a user client that overrides IOUserSCSIPeripheralDeviceType00, with the object of writing device firmware to the driver. I can gain and relinquish exclusive access to the device, I can call UserReportMediumBlockSize and get back a sensible answer (512). I can build command parameters with the INQUIRY macro from IOUserSCSIPeripheralDeviceHelper.h and send that command successfully using UserSendCB, and I receive sensible-looking Inquiry data from the device. However, what I really want to do is send a WriteBuffer command (opcode 0x3B), and that doesn't work. I have yet to put a bus analyzer on it, but I don't think the command goes out on the bus - there's no valid sense data, and the error returned is 0xe00002bc, or kIOReturnError, which isn't helpful. This is the code I have which doesn't work. kern_return_t driver::writeChunk(const char * buf, size_t atOffset, size_t length, bool lastOne) { DebugMsg("writeChunk %p at %ld for %ld", buf, atOffset, length); SCSIType00OutParameters outParameters; SCSIType00InParameters response; memset(&outParameters, 0, sizeof(outParameters)); memset(&response, 0, sizeof(response)); SetCommandCDB(&outParameters.fCommandDescriptorBlock, 0x3B, // byte 0, opcode WriteBuffer command lastOne ? 0x0E : 0x0F, // byte 1 mode: E=save deferred, F = download and defer save 0, // byte 2 bufferID (atOffset >> 16), // byte 3 (atOffset >> 8), // byte 4 atOffset, // byte 5 (length >> 16), // byte 6 (length >> 8), // byte 7 length, // byte 8 0, // control, byte 9 0, 0, 0, 0, 0, 0); // bytes 10..15 outParameters.fLogicalUnitNumber = 0; outParameters.fBufferDirection = kIOMemoryDirectionOut; outParameters.fDataTransferDirection = kSCSIDataTransfer_FromInitiatorToTarget; outParameters.fTimeoutDuration = 1000; // milliseconds outParameters.fRequestedByteCountOfTransfer = length; outParameters.fDataBufferAddr = reinterpret_cast<uint64_t>(buf); uint8_t senseBuffer[255] = {0}; outParameters.fSenseBufferAddr = reinterpret_cast<uint64_t>(senseBuffer); outParameters.fSenseLengthRequested = sizeof(senseBuffer); kern_return_t retVal = UserSendCDB(outParameters, &response); return retVal; }

Dear Apple engineers and DriverKit developers, We have developed a DriverKit (DEXT) driver for an HBA RAID controller. The RAID controller is connected to hosts through Thunderbolt (PCIe port of the Thunderbolt controller). We use an IO script to verify the developed driver. The test fails after a few (10-12) hours of running with an error: “BUG IN CLIENT OF LIBDISPATCH: dispatch_sync called on queue already owned by current thread”. We inspected the stack trace of the crash report. This error happens in the interrupt handler. Thread 5 Crashed: 0 libdispatch.dylib 0x19671aa8c __DISPATCH_WAIT_FOR_QUEUE__ + 484 1 libdispatch.dylib 0x19671a5d0 _dispatch_sync_f_slow + 152 2 DriverKit 0x195d3fc1c IODispatchQueue::DispatchSync_f(void*, void (*)(void*)) + 296 3 DriverKit 0x195d40860 IOInterruptDispatchSourceThread(void*) + 380 4 libsystem_pthread.dylib 0x1968a3738 _pthread_start + 140 5 libsystem_pthread.dylib 0x1968ac6c8 thread_start + 8 On our side we created 5 DispatchQueue(s) for the interrupt processing and configured 5 interrupt handlers using ConfigureInterrupts(kIOInterruptTypePCIMessagedX, 1, 5). It gives 5 interrupts, as requested and it is not clear what is the reason for the issue. Our code samples are below uint32_t configureInterrupts(uint32_t requested, uint32_t required)  {      const kern_return_t ret = ioPCIdevice->ConfigureInterrupts(kIOInterruptTypePCIMessagedX, required, requested);      if (ret != kIOReturnSuccess)          return 0;      uint64_t interruptType = 0;      uint32_t interruptsCount = 0;      uint32_t interruptIndex = 0;        for ( ;; ++interruptIndex) {          if (IOInterruptDispatchSource::GetInterruptType(ioPCIdevice, interruptIndex, &interruptType) != kIOReturnSuccess)              break;          if ((interruptType & kIOInterruptTypePCIMessagedX) == 0)              continue;          ++interruptsCount;      }      return interruptsCount;  }  ..... // Create DQs     for(int i = 0; i < maxInterrupts; ++i) {          ret = IODispatchQueue::Create(INTERRUPT_DQ_NAME, 0, 0, &ivars->interruptQueue[i]);          if (kIOReturnSuccess != ret || nullptr == ivars->interruptQueue[i]) {              GH_PRINT_ERR("Interrupts queue %d creation failed with error %d", i, ret);              return false;          }      } ..... // Link DQ with interrupt   for(int index = 0; index < maxInterrupts; ++ index) {      kern_return_t ret = CreateActionHandleInterruptRequest(size, &ivars->interruptActions[index]);      if (kIOReturnSuccess != ret) {          GH_PRINT_ERR("Create action for interrupt handler %u failed.", index);          return ;      }      ret = IOInterruptDispatchSource::Create(ivars->PCI_io.dev, index, ivars->interruptQueue[index], &ivars->interruptSources[index]);      if (kIOReturnSuccess != ret || nullptr == ivars->interruptSources[index]) {          GH_PRINT_ERR("Creating interrupt source %u failed for interrupt index %u.", index, index);          return ;      }      ret = ivars->interruptSources[index]->SetHandler(ivars->interruptActions[index]);      if (kIOReturnSuccess != ret) {          GH_PRINT_ERR("Setting the handler for interrupt source %u failed.", index);          return ;      }      ivars->contexts[index] = ivars->interruptActions[index]->GetReference();      }  ..... // definition for interrupt handler void    HandleInterruptRequest ( OSAction *action, uint64_t count, uint64_t time) TYPE (IOInterruptDispatchSource::InterruptOccurred);  Do you have any clue how we can fix this error? Or directions and ways for investigation? Please let us know if you need more details.

We are looking for a solution (API, Frameworks) that would allow us to block any type of external device, including storage devices, HIDs, network adapters, and Bluetooth devices according with dynamic rules that comes from management server . This feature is important for endpoint security solutions vendors, and it can be implemented on other platforms and older versions of macOS using the IOKit framework and kexts. I have found one solution that can control the usage only of "storage" devices with the EndpointSecurity framework in conjunction with the DiskArbitration framework. This involves monitoring the MOUNT and OPEN events for /dev/disk files, checking for devices as they appear, and ejecting them if they need to be blocked.. Also, I have found the ES_EVENT_TYPE_AUTH_IOKIT_OPEN event in EndpointSecurity.framework, but it doesn't seem to be useful, at least not for my purposes, because ES doesn't provide AUTH events for some system daemons, such as configd (it only provides NOTIFY events). Furthermore, there are other ways to communicate with devices and their drivers apart from IOKit. DriverKit.framework does not provide the necessary functionality either, as it requires specific entitlements that are only available to certain vendors and devices. Therefore, it cannot be used to create universal drivers for all devices, which should be blocked. Any advice would be greatly appreciated!

Environment iPad：10th iOS：18.1 Printer：EPSON PX-S730 Problem In iOS18.1, When printing with AirPrint, PrintCenter is no longer displayed on AppSwitcher. In iOS17, PrintCenter was displayed on AppSwitcher. Question Is this a specification change? I would like to know if there is a way to check PrintCenter on AppSwitcher in the same way as iOS17. Ref No information after iOS18.1 update. https://support.apple.com/ja-jp/109349 There is no mention of AirPrint updates in the AppleDeveloper release notes. https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-18-release-notes https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-18_1-release-notes

I am trying to add a few properties to an IOUSBHostDevice but the SetProperties is returning kIOReturnUnsupported. The reason I am trying to modify the IOUSBHostDevice's properties is so we can support a MacBook Air SuperDrive when it is attached to our docking station devices. The MacBook Air SuperDrive needs a high powered port to run and this driver will help the OS realize that our dock can support it. I see that the documentation for SetProperties says: The default implementation of this method returns kIOReturnUnsupported. You can override this method and use it to modify the set of properties and values as needed. The changes you make apply only to the current service. Do I need to override IOUSBHostDevice? This is my current Start implementation (you can also see if in the Xcode project): kern_return_t IMPL(MyUserUSBHostDriver, Start) { kern_return_t ret = kIOReturnSuccess; OSDictionary * prop = NULL; OSDictionary * mergeProperties = NULL; bool success = true; os_log(OS_LOG_DEFAULT, "&gt; %s", __FUNCTION__); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); ret = Start(provider, SUPERDISPATCH); __Require(kIOReturnSuccess == ret, Exit); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); ivars-&gt;host = OSDynamicCast(IOUSBHostDevice, provider); __Require_Action(NULL != ivars-&gt;host, Exit, ret = kIOReturnNoDevice); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); ret = ivars-&gt;host-&gt;Open(this, 0, 0); __Require(kIOReturnSuccess == ret, Exit); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); ret = CopyProperties(&amp;prop); __Require(kIOReturnSuccess == ret, Exit); __Require_Action(NULL != prop, Exit, ret = kIOReturnError); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); mergeProperties = OSDynamicCast(OSDictionary, prop-&gt;getObject("IOProviderMergeProperties")); mergeProperties-&gt;retain(); __Require_Action(NULL != mergeProperties, Exit, ret = kIOReturnError); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); OSSafeReleaseNULL(prop); ret = ivars-&gt;host-&gt;CopyProperties(&amp;prop); __Require(kIOReturnSuccess == ret, Exit); __Require_Action(NULL != prop, Exit, ret = kIOReturnError); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); os_log(OS_LOG_DEFAULT, "%s : %s", "USB Product Name", ((OSString *) prop-&gt;getObject("USB Product Name"))-&gt;getCStringNoCopy()); os_log(OS_LOG_DEFAULT, "%s : %s", "USB Vendor Name", ((OSString *) prop-&gt;getObject("USB Vendor Name"))-&gt;getCStringNoCopy()); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); success = prop-&gt;merge(mergeProperties); __Require_Action(success, Exit, ret = kIOReturnError); os_log(OS_LOG_DEFAULT, "%s:%d", __FUNCTION__, __LINE__); ret = ivars-&gt;host-&gt;SetProperties(prop); // this is no working __Require(kIOReturnSuccess == ret, Exit); Exit: OSSafeReleaseNULL(mergeProperties); OSSafeReleaseNULL(prop); os_log(OS_LOG_DEFAULT, "err ref %d", kIOReturnUnsupported); os_log(OS_LOG_DEFAULT, "&lt; %s %d", __FUNCTION__, ret); return ret; }

We are developing an iOS app that communicates with a device using an NXP NTAG 5 chip in ISO15693 pass-through mode. While the app works flawlessly on older iPhone models (iPhone 8, SE, X) and most Android devices, we are experiencing severe reliability issues on iPhone 12, 13, 14, and 15. Issue Summary On newer iPhones (12–15), 90% of communication attempts fail. Retry strategies do not work, as the NFC session is unexpectedly canceled while handling CoreNFC custom commands. The issue is not consistent—sometimes all requests fail immediately, while other times, a batch of reads might succeed unexpectedly before failing again. Technical Details The failure occurs while executing the following request, which should return 256 bytes: tag.customCommand(requestFlags: .highDataRate, customCommandCode: commandCode, customRequestParameters: Data(byteArray)) { (responseData, error) in } The returned error is: -[NFCTagReaderSession transceive:tagUpdate:error:]:897 Error Domain=NFCError Code=100 "Tag connection lost" UserInfo={NSLocalizedDescription=Tag connection lost} For reference, we tested a comparable STM ST25 chip in ISO15693 and NDEF mode, and the exact same issue occurs. Observations and Debugging Attempts Positioning of the NFC antenna has been tested extensively. Disabling Bluetooth and Wi-Fi does not improve reliability. Rebooting the device or waiting between attempts sometimes improves success rates but does not provide a structural fix. When reading multiple blocks (e.g., 15 blocks of 256 bytes each): The process often fails within the first three blocks. After multiple failures, it may suddenly succeed in reading all blocks in one go before returning to a series of failures. The nfcd logs suggest issues at the low-level NFC and SPMI layers, indicating potential hardware or firmware-related problems: error 17:36:18.289099+0100 nfcd phOsalNfc_LogStr:65 NCI DATA RSP : Timer expired before data is received! error 17:36:18.292936+0100 nfcd NFHardwareSerialQuerySPMIError:1339 "Invalid argument" errno=22 setsockopt: SYSPROTO_CONTROL:IO_STOCKHOLM_SPMIERRORS error 17:36:18.293036+0100 nfcd phTmlNfc_SpmiDrvErrorStatus:1157 "Invalid argument" errno=22 Failed to query SPMI error registers error 17:36:18.293235+0100 nfcd phOsalNfc_LogStr:65 phLibNfc_SpmiStsRegInfoNtfHandler: Read Spmi Status Failed - pInfo set to NULL error 17:36:18.293313+0100 nfcd _Callback_NFDriverNotifyGeneral:2353 Unknown notification: 0x5b error 17:36:18.294163+0100 nfcd phOsalNfc_LogStr:65 Target Lost!! error 17:36:18.294678+0100 nfcd -[_NFReaderSession handleSecureElementTransactionData:appletIdentifier:]:164 Unimplemented error 17:36:18.294760+0100 nfcd -[_NFReaderSession handleSecureElementTransactionData:appletIdentifier:]:164 Unimplemented error 17:36:18.320132+0100 nfcd phOsalNfc_LogStr:65 ISO15693 XchgData,PH_NCINFC_STATUS_RF_FRAME_CORRUPTED Detected by NFCC during Data Exchange error 17:36:18.320291+0100 nfcd phOsalNfc_LogU32:74 phNciNfc_ChkDataRetransmission: Re-transmitting Data pkt Attempt..=1 error 17:36:18.622050+0100 nfcd phOsalNfc_LogStr:65 NCI DATA RSP : Timer expired before data is received! error 17:36:18.625857+0100 nfcd NFHardwareSerialQuerySPMIError:1339 "Invalid argument" errno=22 setsockopt: SYSPROTO_CONTROL:IO_STOCKHOLM_SPMIERRORS error 17:36:18.625919+0100 nfcd phTmlNfc_SpmiDrvErrorStatus:1157 "Invalid argument" errno=22 Failed to query SPMI error registers error 17:36:18.626132+0100 nfcd phOsalNfc_LogStr:65 phLibNfc_SpmiStsRegInfoNtfHandler: Read Spmi Status Failed - pInfo set to NULL error 17:36:18.626182+0100 nfcd _Callback_NFDriverNotifyGeneral:2353 Unknown notification: 0x5b error 17:36:18.626899+0100 nfcd phOsalNfc_LogStr:65 Target Lost!! error 17:36:18.627482+0100 nfcd -[_NFReaderSession handleSecureElementTransactionData:appletIdentifier:]:164 Unimplemented error 17:36:18.627568+0100 nfcd -[_NFReaderSession handleSecureElementTransactionData:appletIdentifier:]:164 Unimplemented error 17:36:18.833174+0100 nfcd -[_NFReaderSession handleSecureElementTransactionData:appletIdentifier:]:164 Unimplemented error 17:36:19.145289+0100 nfcd phOsalNfc_LogStr:65 NCI DATA RSP : Timer expired before data is received! error 17:36:19.149233+0100 nfcd NFHardwareSerialQuerySPMIError:1339 "Invalid argument" errno=22 setsockopt: SYSPROTO_CONTROL:IO_STOCKHOLM_SPMIERRORS error 17:36:19.149353+0100 nfcd phTmlNfc_SpmiDrvErrorStatus:1157 "Invalid argument" errno=22 Failed to query SPMI error registers error 17:36:19.149730+0100 nfcd phOsalNfc_LogStr:65 phLibNfc_SpmiStsRegInfoNtfHandler: Read Spmi Status Failed - pInfo set to NULL error 17:36:19.149797+0100 nfcd _Callback_NFDriverNotifyGeneral:2353 Unknown notification: 0x5b error 17:36:19.150463+0100 nfcd phOsalNfc_LogStr:65 Target Lost!! Any solutions? Has anyone else encountered similar behavior with CoreNFC on iPhone 12–15? Could this be related to changes in NFC hardware or power management in newer iPhone models? Any suggestions on possible workarounds or alternative approaches would be greatly appreciated.

I read that iPadOS supports driverkit, and, presumably, the same serial FTDI UARTs as macOS. Has this been migrated to USB-C iPhones on iOS 18? After some searching, the developer doc is not clear, and web responses are contradictory. We are currently using it for a wired sensor option of our BlueTooth HR sensor. When it is used in wired config, the radios are turned off. This is important to some of our customers. Since Lightning MFI sensors are being discontinued with Apple killing Lightning, we would love to have an alternative for iOS. -- Harald

Hello Everyone, I have noticed an inconsistency in the KEXT status between the System Information Extensions section and the output of the kextstat command. In System Information, the extension appears as loaded: ACS6x: Version: 3.8.3 Last Modified: 2025/3/10, 8:03 PM Bundle ID: com.Accusys.driver.Acxxx Loaded: Yes Get Info String: ACS6x 3.8.4 Copyright (c) 2004-2020 Accusys, Ltd. Architectures: arm64e 64-Bit (Intel): No Location: /Library/Extensions/ACS6x.kext/ Kext Version: 3.8.3 Load Address: 0 Loadable: Yes Dependencies: Satisfied Signed by: Developer ID Application: Accusys, Inc (K3TDMD9Y6B) Issuer: Developer ID Certification Authority Signing time: 2025-03-10 12:03:20 +0000 Identifier: com.Accusys.driver.Acxxx TeamID: K3TDMD9Y6B However, when I check using kextstat, it does not appear as loaded: $ kextstat | grep ACS6x Executing: /usr/bin/kmutil showloaded No variant specified, falling back to release I use a script to do these jobs echo " Change to build/Release" echo " CodeSign ACS6x.kext" echo " Compress to zip file" echo " Notary & Staple" echo " Unload the old Acxxx Driver" echo " Copy ACS6x.kext driver to /Library/Extensions/" echo " Change ACS6x.kext driver owner" echo " Loaded ACS6x.kext driver" sudo kextload ACS6x.kext echo " Rebiuld system cache" sudo kextcache -system-prelinked-kernel sudo kextcache -system-caches sudo kextcache -i / echo " Reboot" sudo reboot But it seems that the KEXT is not always loaded successfully. What did I forget to do? Any help would be greatly appreciated. Best regards, Charles

I have Windows drives on my Mac but I didn't get the Wellness boot Campdrivers how can I install them

I’m experiencing a persistent issue with the new USB-C lossless audio feature on AirPods Max (firmware 7E101). I’m using original Apple USB-C to USB-C cable and have tested this setup across multiple Apple devices, including: • iPhone (running iOS 18.5 beta) • iPad Pro with USB-C • MacBook Pro (15.5 Beta) ❗️Problem: Despite Apple’s announcement that AirPods Max now support wired lossless audio over USB-C, I’m unable to get any audio output via USB-C on any device. • On iPhone: I disabled Bluetooth, connected via USB-C — no sound. • On MacBook: The device is shown as “AirPods Max USB Audio” in System Information > USB, but it does not appear in Sound settings or Audio MIDI Setup as an available output. • On iPad Pro: Same behavior — no audio output. Other details: • I performed a factory reset of the headphones, but the LED flashes red instead of the expected amber → white sequence. (Apple’s documentation does not mention red flash behavior during reset — might indicate an error state.) • The issue is not isolated to the iOS 18.5 beta — since the same behavior occurs on macOS and iPadOS. What works: • Bluetooth audio still works fine. • The cable and USB-C ports function with other audio devices. ⸻ Summary: It looks like: • USB audio is being detected on a hardware level (at least on Mac), • but software support for output (especially on macOS/iPadOS) is either not implemented, disabled, or bugged — possibly connected to iOS 18.5 beta or broader OS-level limitations.

Hello everyone. I have been developing PCIe device driver through Thunderbolt. However, it was confirmed that up to three devices connected to the daisy chain worked normally, but the fourth device failed to operate the _CopyDeviceMemoryWithIndex() function for connection with the BAR0 App and did not work properly. The standard specification of Thunderbolt 3/4 is said to be supported by daisy chain connection up to 6-device, but in reality, it is only 3 units, so I ask the forum for technical confirmation. Of course total 4 device by 2-port x 2-device daisy chain connecting has working well. The PCI entry in System information indicates that all devices have normal load of the PCIe device driver. Thank you.

We’re looking for a reliable way to determine whether an iPad device supports DriverKit. Since there doesn't appear to be a direct public API for this, our current approach is as follows: Retrieve the device’s model identifier (e.g., "iPad14,8") and the iOS/iPadOS version. Map the model identifier to a known iPad model and its associated chip. If the device has an M-series chip, we assume it supports DriverKit. For future-proofing, we plan to assume that any future iPad with a model identifier of iPad15,* or higher will contain an M-series chip and therefore support DriverKit. We have a couple of questions: Is there a more reliable or official API to determine the chip version or DriverKit support? Is it reasonable to rely on the assumptions outlined in steps 2 and 3 for determining DriverKit compatibility?

I have reference some related post for this issue: https://developer.apple.com/documentation/xcode-release-notes/xcode-16-release-notes#Foundation https://developer.apple.com/forums/thread/762711 Unfortunately, I'm facing the similar issues even though using Xcode Version 16.2 (16C5032a). we have the following build environment: Xcode version: Xcode 16.2 (16C5032a) macOS Version: macOS 14.7.4 (23H420) Everything builds and install fine. But when attempting to plug on Device on macOS 14.7.4 it crashes immediately with what appears to be a missing Foundation symbol. Crashed Thread: 0 Exception Type: EXC_CRASH (SIGABRT) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: Namespace DYLD, Code 4 Symbol missing Symbol not found: __ZThn48_N21IOUserNetworkEthernet25registerEthernetInterfaceE10ether_addrPP24IOUserNetworkPacketQueuejP29IOUserNetworkPacketBufferPoolS5_ Referenced from: &lt;ECE57ABF-0633-3C3B-8427-FB25CC706343&gt; /Library/SystemExtensions/*/com.asix.dext.pciedevice Expected in: &lt;CDEB3490-B1E0-3D60-80CE-59C0682A4B03&gt; /System/DriverKit/System/Library/Frameworks/NetworkingDriverKit.framework/NetworkingDriverKit (terminated at launch; ignore backtrace) Thread 0 Crashed: 0 dyld 0x1041da4c8 __abort_with_payload + 8 1 dyld 0x1041e50cc abort_with_payload_wrapper_internal + 104 2 dyld 0x1041e5100 abort_with_payload + 16 3 dyld 0x1041767f0 dyld4::halt(char const*, dyld4::StructuredError const*) + 304 4 dyld 0x1041732ec dyld4::prepare(dyld4::APIs&amp;, dyld3::MachOAnalyzer const*) + 3888 5 dyld 0x104171ef4 start + 1868 Thread 0 crashed with ARM Thread State (64-bit): x0: 0x0000000000000006 x1: 0x0000000000000004 x2: 0x000000016bdd2810 x3: 0x0000000000000172 x4: 0x000000016bdd2410 x5: 0x0000000000000000 x6: 0x000000016bdd1400 x7: 0x000000016bdd1460 x8: 0x0000000000000020 x9: 0x000000016bdd237c x10: 0x000000000000000a x11: 0x0000000000000000 x12: 0x0000000000000038 x13: 0x0000000000000000 x14: 0x0000000188e77f9d x15: 0x0000000000008000 x16: 0x0000000000000209 x17: 0x000000010416f37c x18: 0x0000000000000000 x19: 0x0000000000000000 x20: 0x000000016bdd2410 x21: 0x0000000000000172 x22: 0x000000016bdd2810 x23: 0x0000000000000004 x24: 0x0000000000000006 x25: 0x00000000000000a8 x26: 0x000000016bdd32d8 x27: 0x000000010405e090 x28: 0x0000000000000001 fp: 0x000000016bdd23e0 lr: 0x00000001041e50cc sp: 0x000000016bdd23a0 pc: 0x00000001041da4c8 cpsr: 0x80001000 far: 0x0000000000000000 esr: 0x56000080 Address size fault Binary Images: 0x10416c000 - 0x1041f7fff dyld (*) &lt;4fe051cf-29dc-3f02-890b-33144fa09253&gt; /usr/lib/dyld 0x10402c000 - 0x10403ffff com.asix.dext.pciedevice (0.1.6) &lt;ece57abf-0633-3c3b-8427-fb25cc706343&gt; /Library/SystemExtensions/*/com.asix.dext.pciedevice 0x0 - 0xffffffffffffffff ??? (*) &lt;00000000-0000-0000-0000-000000000000&gt; ??? External Modification Summary: Calls made by other processes targeting this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by this process: task_for_pid: 0 thread_create: 0 thread_set_state: 0 Calls made by all processes on this machine: task_for_pid: 0 thread_create: 0 thread_set_state: 0 VM Region Summary: ReadOnly portion of Libraries: Total=8612K resident=0K(0%) swapped_out_or_unallocated=8612K(100%) Writable regions: Total=12.2M written=0K(0%) resident=0K(0%) swapped_out=0K(0%) unallocated=12.2M(100%) Is it expected that this should work? Is this a known issue? Is there any workaround for it? Should I file feedback or a DTS?

Hi All, We've been working on a new CarPlay-supported App and are hoping for advice on how to achieve this. We have completed the CarPlay Entitledment Request, but have not received any response from Apple. Given we're close to launch on Android, we'd love to have these projects completed together. Any advice on how to make contact with the approvals team, or suggestions on how long this will normally take? If they're no longer taking applications or rejection is high, any guidance would be greatly appreciated too!

I have a dext that creates a periodic timer on its own dispatch queue. The callback is declared as follows: virtual void HandleTimer( OSAction *action, uint64_t time ) TYPE(IOTimerDispatchSource::TimerOccurred); The timer is allocated as follows: CreateActionHandleTimer( size, &ivars->TimerHandler ); IODispatchQueue::Create( "TimerQueue", 0, 0, &ivars->TimerDispatchQueue ); IOTimerDispatchSource::Create( ivars->TimerDispatchQueue, &ivars->TimerDispatchSrc ); I can start up the timer and it works just fine. However, in my Stop() method, when trying to shut the timer down, I get an assertion in OSAction::Cancel() for TimerHandler: Assertion failed: (queue), function Cancel, file uioserver.cpp, line 4401. What does this assertion indicate or is the source code available? If so, where? I'm using macOS 15.5. Note I am attempting to cancel the handler after the dispatch source and queue are canceled and the cleanup methods have been called (which is working). But, cancelling TimerHandler first also asserts.

I need to implement an app that exchanges data with peripherals through TypeC on Apple 15 phones, but I have two questions that I need to ask for help: Which library is used to communicate with peripherals through the TypeC port of the Apple mobile phone? Do peripherals need to pass MFi authentication before they can communicate with the App?

I am currently developing a kiosk system that incorporates an iPad along with a custom peripheral device. The two components are intended to communicate via USB serial. I have encountered a critical issue while working with the official DriverKit sample code provided at the following link: https://developer.apple.com/documentation/driverkit/communicating-between-a-driverkit-extension-and-a-client-app Model info : iPad Pro 12.9-inch (5th generation / M1 chipset) iPadOS 18.4.1 App Stops Functioning After Repeated Builds When I first build and run the sample code without any modifications, it works as expected. However, after making changes and running the app repeatedly on the iPad, it eventually reaches a state where the app stops functioning completely — no logs are printed, and device communication fails. Reinstalling the app or rebooting the iPad does not resolve the issue. Even when I revert to the original, unmodified sample code, the problem persists. Surprisingly, if I generate a new Bundle Identifier, the app functions normally again. I would like to ask: What could be causing this behavior? Have similar cases been reported before? For your reference, I’ve attached a video demonstrating the issue and the source code used during the recording: Source Code: https://drive.google.com/file/d/14whvWwuhrmS5VoR3sSKyNT-GpTPC_c_8/view?usp=sharing Video: https://drive.google.com/file/d/1SfqIkEphSDrvg-CKS6KBcJ1VBP3cPqCC/view?usp=sharing Request for USB Serial Communication Reference Currently, due to the issue above, I am unable to obtain a device instance at all. Even assuming this is resolved, I noticed that the sample code does not include any implementation or reference material for USB serial communication itself. Is there any official sample code or documentation available that demonstrates USB serial communication between an iPad and an external device using DriverKit? Difficulty Debugging Due to Missing os_log Output Another challenge I'm facing is the inability to view os_log output while connecting the USB device to the iPad. This significantly hinders the debugging process during DriverKit development. Are there any recommended or supported methods for accessing logs and debugging effectively in this environment?

I want to update my iPhone 15 Pro to iOS 26 from iOS 18.5. I downloaded ipsw firmware. But iTunes and Apple Devices App requires update version of app for update to iOS 26. But I use last version of iTunes / Apple Devices, which was realised 2 May, 2025. That mean Apple need to update their apps for adaptation it to iOS 26 update?