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.
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
Hello, dear Apple engineers.
We have recently tried to pair our Android phones and iPhones via BLE SMP, but have encountered a very high probability of pairing failures. Through PacketLogger and Android phone HCI, we have determined that the issue is caused by the iOS side sending an SMP Pairing Failed message during the SMP process. Please help us analyze the reason for this.
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
Hello everyone,
I'm developing a CarPlay app and am trying to test it with the dock on the right side of the screen, as is standard for right-hand drive vehicles like those in Japan.
Currently, the CarPlay Simulator always displays the dock on the left, and I can't find an option to change its position. This is important for ensuring a proper user experience for my target market.
Has anyone figured out how to configure the simulator for RHD layouts? Any guidance on how to move the dock to the right would be greatly appreciated.
Thanks in advance for your help!
Hi,
We were planning on using DriverKit to develop a USB Driver on IOS for iPhone. Within the DriverKit website, it say 'IOS16.0+' which lead us to believe it was compatible with iPhones running IOS16.0+.
However, it appears DriverKit is only available for iPads running iPadOS, and computers running macOS.
Are there any alternatives that would allow us to create a device specific USB driver for an iPhone running IOS?
Hi everyone,
We are experiencing an issue with SMS messages sent from our banking app (iOS) to our customers. The SMS are being delivered by the carrier, but on iOS devices some of them appear to be filtered or blocked, and users don’t see them in the Messages app.
This seems to be related to new SMS filtering rules on iOS (possibly affecting financial institutions and transactional SMS).
• Has anyone faced a similar situation?
• Are there specific Apple guidelines or best practices for SMS sender IDs / content to avoid being filtered?
• Is there any official documentation from Apple regarding these new SMS filtering mechanisms?
Any guidance or experiences would be greatly appreciated.
Thanks in advance!
We have a management application which manages security enable and disable for an external PCIe based storage device using Kernel Extension(SCSI Architecture Model Family for External USB Mass Storage devices which deals with IOSCSIBlockCommandsDevice, IOSCSIPeripheralDeviceType00 and IOBlockStorageService)
Now the issue we are facing is when we try to unlock the device using security code (already being set) , we will relink the device using VU command (RelinkBridge). Even-though both the commands are successful , the device is not getting relinked due to which we are not able to use the device for storage.
If someone have faced similar issue or any pointer on how to resolve this issue , it would be helpful.
Thanks in advance.
1) The circumstances:
iPADOS~>18, USB still-imaging-gadget, 1-3 gadgets might connect simultaneously via USB-hub, proprietary DExt,
UserClient App in developers' iPADs or in TestFlight.
= 1 variation A) UserClientApp has attribute [Background modes][Enable external communications].
= 1 variation B) "active USB-hub" vs "passive".
= 1 variation C) "ConsoleApp logs iPAD" vs "ConsoleApp is not started".
= 1 the term "zombie" below assume issue:
== after plug-in ConsoleApp logs "IOUsbUserInterface::init", "::start";
== UserClient never receives respective callback from IOServiceAddMatchingNotification
== further IOKit APIs "teardown", "restart" and "re-enumeration of connected gadgets" doesn't reveal the zombie (while it sees another simultaneous gadget);
== unplug of the gadget logs "IOUsbUserInterface::stop".
=2) The situation when UserClient is in foreground:
~ everything is fine.
Note in MAC OS everything (same DExt and UserClient-code) works fine in background and in foreground.
=3) The situation when UserClient is in background (beneath ~"Files" or "Safari"):
=3A) "1A=true" phys plugin causes zombie in ~1/20 cases (satisfactory)
=3B) "1A=false" phys plugin causes zombie in ~1/4 cases (non-satisfactory)
=3C) "1 variation B" and "1 variation C" reduce zombies by ~>30%.
=3D) ConsoleApp logs with filter "IOAccessory" (~about USB-energy) always look similar by my eyes.
=4) From Apple-store:
"The app declares support for external-accessory in the UIBackgroundModes"..."The external accessory background mode is intended for apps that communicate with hardware accessories through the External Accessory framework."..."Additionally, the app must be authorized by MFi,"
=5) My wish/ask:
=5 option A) A clue to resolve the "zombie-plugin-issue in background" in a technical manner.
= E.g. find a straightforward solution that ~elevates UserClient's "privileges" in background like [Enable external communication]...
E.g. what ConsoleApp-logs to add/watch to reveal my potential bugs in DExt or in UserClient?
=5 option B) A way to pursue Apple-store to accept (without MFI) an UserClientApp with [Enable external communication].
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.
Topic:
App & System Services
SubTopic:
Drivers
I have a USB-device with three interfaces:
Vendor-Specific Bulk
CDC Serial Control
CDC Serial Data
To configure the vendor specific bulk endpoints I need to send vendor specific control requests to endpoint 0. I'm using libusb for this task. As long as the interfaces for the CDC serial port are present I get an access error when trying to send vendor control requests.
If I disable these CDC interfaces I can send vendor control request without any problems:
Is this by design or ist there any possibility to send vendor control requests to the USB device while a CDC driver is active?
Topic:
App & System Services
SubTopic:
Drivers
Hello everyone,
I am migrating a legacy KEXT to a DriverKit (DEXT) architecture. While the DEXT itself is working correctly, I am completely blocked by a code signing issue when trying to establish the UserClient connection from our SwiftUI management app.
Project Goal & Status:
Our DEXT (com.accusys.Acxxx.driver) activates successfully (systemextensionsctl list confirms [activated enabled]).
The core functionality is working (diskutil list shows the corresponding disk device node).
The Core Problem: The userclient-access Signing Error
To allow the app to connect to the DEXT, the com.apple.developer.driverkit.userclient-access entitlement is required in the app's .entitlements file.
However, as soon as this entitlement is added, the build fails.
Both automatic and manual signing fail with the same error:
`Provisioning profile ... doesn't match the entitlements file's value for the ... userclient-access entitlement.`
This build failure prevents the generation of an .app bundle, making it impossible to inspect the final entitlements with codesign.
What We've Confirmed:
The necessary capabilities (like DriverKit Communicates with Drivers) are visible and enabled for our App ID on the developer portal.
The issue persists on a clean system state and on the latest macOS Sequoia 15.7.1.
Our Research and Hypothesis:
We have reviewed the official documentation "Diagnosing issues with entitlements" (TN3125).
According to the documentation, a "doesn't match" error implies a discrepancy between the entitlements file and the provisioning profile.
Given that we have tried both automatic and manual profiles (after enabling the capability online), our hypothesis is that the provisioning profile generation process on Apple's backend is not correctly including the approved userclient-access entitlement into the profile file itself. The build fails because Xcode correctly detects this discrepancy.
Our Questions:
Did we misunderstand a step in the process, or is the issue not with the entitlement request at all? Alternatively, are there any other modifications we can make to successfully connect our App to the DEXT and trigger NewUserClient?
Thank you for any guidance.