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?
Drivers
RSS for tagUnderstand the role of drivers in bridging the gap between software and hardware, ensuring smooth hardware functionality.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
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?
Topic:
App & System Services
SubTopic:
Drivers
We're seeing a consistent issue where iPads with the A16 chip fail to connect to our BLE device, which uses a Silicon Labs chip running Gecko SDK 3.x. All other Apple devices — including older iPads and iPhones — connect without any problems.
According to Silicon Labs, the issue stems from the iPad A16 sending an LL_CHANNEL_REPORTING_IND message (opcode 0x28) during connection establishment:
Per Silicon Labs:
"Currently the iPad 16 will send a message for LL_CHANNEL_REPORTING_IND (opcode 0x28).
This is a feature that is not supported in Gecko SDK 3.x.
Shortly after, the BLE module responds with an 'Unknown Response' (opcode 0x07), indicating that it does not support opcode 0x28
After this exchange the iPad stops sending meaningful transactions to the BLE module and eventually closes the connection.
The BLE Module is responding to this unknown request as specified in the BT Core Spec Volume 6 Part B."
Unfortunately, the firmware on these BLE modules cannot be updated remotely, and we've already shipped several thousand units to customers. Given how widely Silicon Labs' BLE modules are deployed, we suspect this issue could be affecting many other developers and products as well.
We’re hoping Apple might offer a workaround or allow us access — even internally or unofficially — to suppress or bypass this feature in CoreBluetooth for this specific scenario. For example, is there a way to disable LL_CHANNEL_REPORTING_IND or instruct the stack to ignore the unknown response from the peripheral?
We’re open to any workaround via CoreBluetooth (even private APIs or entitlements, if necessary) that would allow us to preserve compatibility without a mass recall. If there's an Apple engineer monitoring this, we'd be extremely grateful for guidance or escalation.
Thank you!
We have developed the driver for the ProCapture video capture card based on PCIDriverKit. The App can communicate with the driver through the UserClient API. Currently, there is an issue where, when the App starts, there is a small probability that it causes a driver crash. However, the crash stack trace does not point to our code but appears to be within the PCIDriverKit framework. We have spent several weeks debugging but still cannot identify the root cause of the crash. Could you please review the crash log and suggest any methods to help pinpoint the issue?
com.magewell.ProCaptureDriver-2025-09-15-153522.ips
com.magewell.ProCaptureDriver-2025-09-15-082500.ips
Dear Apple engineers,
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 do plug/unplug tests to verify the developed driver. The test always fails in about 100 cycles with a MacOS crash (panic).
The panic contains
“LLC Bus error (Unavailable) from cpu0: FAR=0xa40100008 LLC_ERR_STS/ADR/INF=0x80/0x300480a40100008/0x1400000005 addr=0xa40100008 cmd=0x18(ACC_CIFL2C_CMD_RD_LD: request for load miss in E or S state)”
At first we assumed that the issue is with hardware. But we did this test on different hosts (MacMini M3 and M4) with different units of our device.
The error points to the same physical address FAR=0xa40100008 even if the hosts are different.
The 2 full panic logs are attached (one for M4, another one for M3 host).
Could you share your understanding of the crash and give any hints on how we can fix it?
Please let us know if you need any additional data.
Thank you
M3 panic:
https://drive.google.com/file/d/1GJXd3tTW6ajdrHpFsJxO_tWWYKYIgcMc/view?usp=share_link
M4 panic:
https://drive.google.com/file/d/1SU-3aBSdhLsyhhxsLknzw9wGvBQ9TbJC/view?usp=share_link
Topic:
App & System Services
SubTopic:
Drivers
We want to allocate a block of contiguous memory (≤1M) for audio ring DMA usage, but we haven't found any explicit method in the DriverKit documentation for allocating contiguous memory.
I'm aware that IOBufferMemoryDescriptor::Create can be used in DriverKit to allocate memory and share it with user space. However, is the allocated memory physically contiguous? Can it guarantee that when I subsequently call PrepareForDMA in IODMACommand, there will be only one segment?
Could you please help review this? Thank you!
Dear Apple CS,
I’m working with NFC ISO15693 tags using NFCTagReaderSession / NFCISO15693Tag, and I’d like to read these tags in the background if possible.
Is there any way to read this tag type without triggering the system NFC popup that iOS normally shows?
Please note it will not be a public app, the app is meant for internal use for our employees only.
is there an option to submit a special request for this use case?
Thank you in advance!
Hi!
Following this ticket: https://developer.apple.com/forums/thread/808764?page=1#868010022
Is there any way to use the hardware RFID reading capabilities of an iPhone to read ISO15693 RF tags silently, and without a UI pop-up? Perhaps using other native iOS libraries than the NFC library?
If not, is there a way for a business to request this feature be allowed in internally used apps only?
I'm trying to implement a virtual serial port driver for my ham radio projects which require emulating some serial port devices and I need to have a "backend" to translate the commands received by the virtual serial port into some network-based communications. I think the best way to do that is to subclass IOUserSerial? Based on the available docs on this class (https://developer.apple.com/documentation/serialdriverkit/iouserserial), I've done the basic implementation below. When the driver gets loaded, I can see sth like tty.serial-1000008DD in /dev and I can use picocom to do I/O on the virtual serial port. And I see TxDataAvailable() gets called every time I type a character in picocom.
The problems are however, firstly, when TxDataAvailable() is called, the TX buffer is all-zero so although the driver knows there is some incoming data received from picocom, it cannot actually see the data in neither Tx/Rx buffers.
Secondly, I couldn't figure out how to notify the system that there are data available for sending back to picocom. I call RxDataAvailable(), but nothing appears on picocom, and RxFreeSpaceAvailable() never gets called back. So I think I must be doing something wrong somewhere. Really appreciate it if anyone could point out how should I fix it, many thanks!
VirtualSerialPortDriver.cpp:
constexpr int bufferSize = 2048;
using SerialPortInterface = driverkit::serial::SerialPortInterface;
struct VirtualSerialPortDriver_IVars
{
IOBufferMemoryDescriptor *ifmd, *rxq, *txq;
SerialPortInterface *interface;
uint64_t rx_buf, tx_buf;
bool dtr, rts;
};
bool VirtualSerialPortDriver::init()
{
bool result = false;
result = super::init();
if (result != true)
{
goto Exit;
}
ivars = IONewZero(VirtualSerialPortDriver_IVars, 1);
if (ivars == nullptr)
{
goto Exit;
}
kern_return_t ret;
ret = ivars->rxq->Create(kIOMemoryDirectionInOut, bufferSize, 0, &ivars->rxq);
if (ret != kIOReturnSuccess) {
goto Exit;
}
ret = ivars->txq->Create(kIOMemoryDirectionInOut, bufferSize, 0, &ivars->txq);
if (ret != kIOReturnSuccess) {
goto Exit;
}
IOAddressSegment ioaddrseg;
ivars->rxq->GetAddressRange(&ioaddrseg);
ivars->rx_buf = ioaddrseg.address;
ivars->txq->GetAddressRange(&ioaddrseg);
ivars->tx_buf = ioaddrseg.address;
return true;
Exit:
return false;
}
kern_return_t
IMPL(VirtualSerialPortDriver, HwActivate)
{
kern_return_t ret;
ret = HwActivate(SUPERDISPATCH);
if (ret != kIOReturnSuccess) {
goto Exit;
}
// Loopback, set CTS to RTS, set DSR and DCD to DTR
ret = SetModemStatus(ivars->rts, ivars->dtr, false, ivars->dtr);
if (ret != kIOReturnSuccess) {
goto Exit;
}
Exit:
return ret;
}
kern_return_t
IMPL(VirtualSerialPortDriver, HwDeactivate)
{
kern_return_t ret;
ret = HwDeactivate(SUPERDISPATCH);
if (ret != kIOReturnSuccess) {
goto Exit;
}
Exit:
return ret;
}
kern_return_t
IMPL(VirtualSerialPortDriver, Start)
{
kern_return_t ret;
ret = Start(provider, SUPERDISPATCH);
if (ret != kIOReturnSuccess) {
return ret;
}
IOMemoryDescriptor *rxq_, *txq_;
ret = ConnectQueues(&ivars->ifmd, &rxq_, &txq_, ivars->rxq, ivars->txq, 0, 0, 11, 11);
if (ret != kIOReturnSuccess) {
return ret;
}
IOAddressSegment ioaddrseg;
ivars->ifmd->GetAddressRange(&ioaddrseg);
ivars->interface = reinterpret_cast<SerialPortInterface*>(ioaddrseg.address);
SerialPortInterface &intf = *ivars->interface;
ret = RegisterService();
if (ret != kIOReturnSuccess) {
goto Exit;
}
TxFreeSpaceAvailable();
Exit:
return ret;
}
void
IMPL(VirtualSerialPortDriver, TxDataAvailable)
{
SerialPortInterface &intf = *ivars->interface;
// Loopback
// FIXME consider wrapped case
size_t tx_buf_sz = intf.txPI - intf.txCI;
void *src = reinterpret_cast<void *>(ivars->tx_buf + intf.txCI);
// char src[] = "Hello, World!";
void *dest = reinterpret_cast<void *>(ivars->rx_buf + intf.rxPI);
memcpy(dest, src, tx_buf_sz);
intf.rxPI += tx_buf_sz;
RxDataAvailable();
intf.txCI = intf.txPI;
TxFreeSpaceAvailable();
Log("[TX Buf]: %{public}s", reinterpret_cast<char *>(ivars->tx_buf));
Log("[RX Buf]: %{public}s", reinterpret_cast<char *>(ivars->rx_buf));
// dmesg confirms both buffers are all-zero
Log("[TX] txPI: %d, txCI: %d, rxPI: %d, rxCI: %d, txqoffset: %d, rxqoffset: %d, txlogsz: %d, rxlogsz: %d",
intf.txPI, intf.txCI, intf.rxPI, intf.rxCI, intf.txqoffset, intf.rxqoffset, intf.txqlogsz, intf.rxqlogsz);
}
void
IMPL(VirtualSerialPortDriver, RxFreeSpaceAvailable)
{
Log("RxFreeSpaceAvailable() called!");
}
kern_return_t IMPL(VirtualSerialPortDriver,HwResetFIFO){
Log("HwResetFIFO() called with tx: %d, rx: %d!", tx, rx);
kern_return_t ret = kIOReturnSuccess;
return ret;
}
kern_return_t IMPL(VirtualSerialPortDriver,HwSendBreak){
Log("HwSendBreak() called!");
kern_return_t ret = kIOReturnSuccess;
return ret;
}
kern_return_t IMPL(VirtualSerialPortDriver,HwProgramUART){
Log("HwProgramUART() called, BaudRate: %u, nD: %d, nS: %d, P: %d!", baudRate, nDataBits, nHalfStopBits, parity);
kern_return_t ret = kIOReturnSuccess;
return ret;
}
kern_return_t IMPL(VirtualSerialPortDriver,HwProgramBaudRate){
Log("HwProgramBaudRate() called, BaudRate = %d!", baudRate);
kern_return_t ret = kIOReturnSuccess;
return ret;
}
kern_return_t IMPL(VirtualSerialPortDriver,HwProgramMCR){
Log("HwProgramMCR() called, DTR: %d, RTS: %d!", dtr, rts);
ivars->dtr = dtr;
ivars->rts = rts;
kern_return_t ret = kIOReturnSuccess;
Exit:
return ret;
}
kern_return_t IMPL(VirtualSerialPortDriver, HwGetModemStatus){
*cts = ivars->rts;
*dsr = ivars->dtr;
*ri = false;
*dcd = ivars->dtr;
Log("HwGetModemStatus() called, returning CTS=%d, DSR=%d, RI=%d, DCD=%d!", *cts, *dsr, *ri, *dcd);
kern_return_t ret = kIOReturnSuccess;
return ret;
}
kern_return_t IMPL(VirtualSerialPortDriver,HwProgramLatencyTimer){
Log("HwProgramLatencyTimer() called!");
kern_return_t ret = kIOReturnSuccess;
return ret;
}
kern_return_t IMPL(VirtualSerialPortDriver,HwProgramFlowControl){
Log("HwProgramFlowControl() called! arg: %u, xon: %d, xoff: %d", arg, xon, xoff);
kern_return_t ret = kIOReturnSuccess;
Exit:
return ret;
}
I would like to write a driver that supports our custom USB-C connected device, which provides a serial port interface. USBSerialDriverKit looks like the solution I need. Unfortunately, without a decent sample, I'm not sure how to accomplish this. The DriverKit documentation does a good job of telling me what APIs exist but it is very light on semantic information and details about how to use all of these API elements. A function call with five unexplained parameters just is that useful to me.
Does anyone have or know of a resource that can help me figure out how to get started?
I am trying to open the CommunicationControl class IOUSBHostInterface in my USB driver, but it only seems to open on iPad Airs and not iPad Pros.
I'm calling
ivars->interruptInterface->Open(this, 0, NULL);
After retrieving the interruptInterface from the device's InterfaceIterator. I try and open this, but on iPad Pros it returns kIOReturnNotOpen. I've tried closing and reopening the IOUSBHostDevice, closing and reopening the Interface, AbortDeviceRequests before opening, etc. but it just seems to work on iPad Air and not iPad Pro.
I've tried on both iPadOS 17.6.1 and 18.2
Has anyone else seen this?
#4 Thread
NSInternalInconsistencyException
Call must be made on main thread
CoreFoundation ___exceptionPreprocess + 164
libsystem_pthread.dylib _start_wqthread + 8
#0 Thread
semaphore_wait_trap
libsystem_kernel.dylib semaphore_wait_trap + 8
libdispatch.dylib 0x00000001b96ed000 + 457547470247841612
UnityFramework Staticburst_initialize + 17597401577822386088
UnityFramework DllCanUnloadNow + 52172
UnityFramework. DllCanUnloadNow + 51292
UnityFramework DllCanUnloadNow + 421068
UnityFramework. Unityplcrash_async_mach_exception_get_siginfo + 5073080
UnityFramework. GlobalizationNative_GetTimeZoneDisplayName + 1585284
UnityFramework. GlobalizationNative_GetTimeZoneDisplayName + 926212
UnityFramework. 0x000000010ce18000 + 77478852
UnityFramework. GlobalizationNative_GetTimeZoneDisplayName + 124804
UnityFramework. GlobalizationNative_GetTimeZoneDisplayName + 124592
UnityFramework. _ZdaPvRKSt9nothrow_t + 2445400
UnityFramework. _ZdaPvRKSt9nothrow_t + 2502608
UnityFramework. _ZdaPvRKSt9nothrow_t + 2556896
UnityFramework. _ZdaPvRKSt9nothrow_t + 2555820
UnityFramework. _ZdaPvRKSt9nothrow_t + 211836
UnityFramework. _ZdaPvRKSt9nothrow_t + 1216980
UnityFramework. _ZdaPvRKSt9nothrow_t + 1145620
UnityFramework. _ZdaPvRKSt9nothrow_t + 1145684
UnityFramework. _ZdaPvRKSt9nothrow_t + 1146408
UnityFramework. UnitySendMessage + 6940844
UnityFramework. _Z12DecodeBase64PKhPhi + 138076
QuartzCore. 0x00000001b2d06000 + 193228
UIKitCore. UIApplicationMain + 1589427071078105428
UnityFramework. _Z12DecodeBase64PKhPhi + 11056988545834161928
Topic:
App & System Services
SubTopic:
Drivers
Two apps were built by different teams for the same account. One app disabled the network permission, and the other app could not access the network
i tried opening iMovie for the first time on my 2017 Macbook Air but i get an error saying that iMovie is too new to my mac but i was trying to run the built in one it says i need to downgrade it on the appstore but there is no option to downgrade
Topic:
App & System Services
SubTopic:
Drivers
I am getting an unexpected crash from IOService::Create() when attempting to create a new user-client. The crash is a nullptr exception in OSCopyInObjects(). The last call from my code was IOService::Create().
As far as I can tell, all the input parameters to Create() are correct, and the Info.plist is has the correct key and class information - indeed, if I corrupt these I get an error status return rather than a crash.
Any suggestions as to what could be causing this?
I suspect that the problem may be related from a change in the underlying application that is creating the user client. This was modified from a standard app to a daemon, following the advice here: https://developer.apple.com/documentation/xcode/signing-a-daemon-with-a-restricted-entitlement.
However, it is the driver that crashes - not the host opening the user client.
Hi there. I inadvertently deleted the Passwords app. The App Store is telling me restrictions are enabled so I can’t reinstall from the cloud. Not sure where to go from here. Help.
Topic:
App & System Services
SubTopic:
Drivers
I have USB DriverKit driver. When I use the log command below to get log, there is logs from my driver on my own M-series MacBook where the driver is built using developer account.
log stream | grep CompanyName
But on other mac like (M-series) Mac Mini, there is no log captured from driver though the driver is communicating with the machine correctly. The only log captured are from MacOS regarding CompanyName driver status/unload/load. The MacOS is Sonoma 14.7.2 and 14.7.3.
Please advise on how to get log from driver since writing to files is not allowed in DriverKit. I need logs to troubleshoot on Mac Mini.
Thanks.
I'm trying to iterate through a USB device but the iterator is always empty or contains only the matched interface:
Single interface in Iterator
This happens when my driver matches against the interface. Because I need to use 2 interfaces (control and cdc), I try to open the IOUSBHostDevice (copied from the interface) and iterate through the rest, but I only get the interface my dext matched with.
Empty Iterator
I decided to match against USB communication devices, thinking things would be different. However, this time the interface iterator is completely empty (provider is IOUSBHostDevice).
Here's a snippet of my code before iterating with IOUSBHostDevice->CopyInterface():
// teardown the configured interfaces.
result = device->SetConfiguration(ivars->Config, true);
__Require_noErr_Action(result, _failure_Out,
ELOG("IOUSBHostDevice::SetConfiguration failed 0x%x", result));
// open usb device
result = device->Open(this, 0, 0);
__Require_noErr_Action(result, _failure_Out,
ELOG("Failed to open IOUSBHostDevice"));
// Get interface iterator
result = device->CreateInterfaceIterator(&iterRef);
__Require_noErr_Action(result, _failure_Out,
ELOG("IOUSBHostDevice::CreateInterfaceIterator failed failed: 0x%x", result));
Hello Everyone,
I am trying to create a Fake SCSI target based on SCSIControllerDriverKit.framework and inherent from IOUserSCSIParallelInterfaceController, here is the code
kern_return_t IMPL(DRV_MAIN_CLASS_NAME, Start)
{
...
// Programmatically create a null SCSI Target
SCSIDeviceIdentifier nullTargetID = 0; // Example target ID, adjust as needed
ret = UserCreateTargetForID(nullTargetID, nullptr);
if (ret != kIOReturnSuccess) {
Log("Failed to create Null SCSI Target for ID %llu", nullTargetID);
return ret;
}
...
}
According the document UserCreateTargetForID, after creating a TargetID successfully, the framework will call the UserInitializeTargetForID()
The document said:
As part of the UserCreateTargetForID call, the kernel calls several APIs like UserInitializeTargetForID which run on the default dispatch queue of the dext.
But after UserCreateTargetForID created, why the UserInitializeTargetForID() not be invoked automatically?
Here is the part of log show
init() - Start
init() - End
Start() - Start
Start() - try 1 times
UserCreateTargetForID() - Start
Allocating resources for Target ID 0
UserCreateTargetForID() - End
Start() - Finished.
UserInitializeController() - Start
- PCI vendorID: 0x14d6, deviceID: 0x626f.
- BAR0: 0x1, BAR1: 0x200004.
- GetBARInfo() - BAR1 - MemoryIndex: 0, Size: 262144, Type: 0.
UserInitializeController() - End
UserStartController() - Start
- msiInterruptIndex : 0x00000000
- interruptType info is 0x00010000
- PCI Dext interrupt final value, return status info is 0x00000000
UserStartController() - End
Any assistance would be greatly appreciated!
Thank you in advance for your support.
Best regards, Charles