Kevin's Guide to DEXT Signing The question of "How do I sign a DEXT" comes up a lot, so this post is my attempt to describe both what the issue are and the best current solutions are. So... The Problems: When DEXTs were originally introduced, the recommended development signing process required disabling SIP and local signing. There is a newer, much simpler process that's built on Xcode's integrated code-signing support; however, that newer process has not yet been integrated into the documentation library. In addition, while the older flow still works, many of the details it describes are no longer correct due to changes to Xcode and the developer portal. DriverKit's use of individually customized entitlements is different than the other entitlements on our platform, and Xcode's support for it is somewhat incomplete and buggy. The situation has improved considerably over time, particularly from Xcode 15 and Xcode 16, but there are still issues that are not fully resolved. To address #1, we introduced "development" entitlement variants of all DriverKit entitlements. These entitlement variants are ONLY available in development-signed builds, but they're available on all paid developer accounts without any special approval. They also allow a DEXT to match against any hardware, greatly simplifying working with development or prototype hardware which may not match the configuration of a final product. Unfortunately, this also means that DEXT developers will always have at least two entitlement variants (the public development variant and the "private" approved entitlement), which is what then causes the problem I mentioned in #2. The Automatic Solution: If you're using Xcode 16 or above, then Xcode's Automatic code sign support will work all DEXT Families, with the exception of distribution signing the PCI and USB Families. For completeness, here is how that Automatic flow should work: Change the code signing configuration to "Automatic". Add the capability using Xcode. If you've been approved for one of these entitlements, the one oddity you'll see is that adding your approved capability will add both the approved AND the development variant, while deleting either will delete both. This is a visual side effect of #2 above; however, aside from the exception described below, it can be ignored. Similarly, you can sign distribution builds by creating a build archive and then exporting the build using the standard Xcode flow. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Note: This document is specifically focused on what happens after a DEXT has passed its initial code-signing checks. Code-signing issues are dealt with in other posts. Preliminary Guidance: Using and understanding DriverKit basically requires understanding IOKit, something which isn't entirely clear in our documentation. The good news here is that IOKit actually does have fairly good "foundational" documentation in the documentation archive. Here are a few of the documents I'd take a look at: IOKit Fundamentals IOKit Device Driver Design Guidelines Accessing Hardware From Applications Special mention to QA1075: "Making sense of IOKit error codes",, which I happened to notice today and which documents the IOReturn error format (which is a bit weird on first review). Those documents do not cover the full DEXT loading process, but they are the foundation of how all of this actually works. Understanding the IOKitPersonalities Dictionary The first thing to understand here is that the "IOKitPersonalities" is called that because it is in fact a fully valid "IOKitPersonalities" dictionary. That is, what the system actually uses that dictionary "for" is: Perform a standard IOKit match and load cycle in the kernel. The final driver in the kernel then uses the DEXT-specific data to launch and run your DEXT process outside the kernel. So, working through the critical keys in that dictionary: "IOProviderClass"-> This is the in-kernel class that your in-kernel driver loads "on top" of. The IOKit documentation and naming convention uses the term "Nub", but the naming convention is not consistent enough that it applies to all cases. "IOClass"-> This is the in-kernel class that your driver loads on top of. This is where things can become a bit confused, as some families work by: Routing all activity through the provider reference so that the DEXT-specific class does not matter (PCIDriverKit). Having the DEXT subclass a specific subclass which corresponds to a specific kernel driver (SCSIPeripheralsDriverKit). This distinction is described in the documentation, but it's easy to overlook if you don't understand what's going on. However, compare PCIDriverKit: "When the system loads your custom PCI driver, it passes an IOPCIDevice object as the provider to your driver. Use that object to read and write the configuration and memory of your PCI hardware." Versus SCSIPeripheralsDriverKit: Develop your driver by subclassing IOUserSCSIPeripheralDeviceType00 or IOUserSCSIPeripheralDeviceType05, depending on whether your device works with SCSI Block Commands (SBC) or SCSI Multimedia Commands (SMC), respectively. In your subclass, override all methods the framework declares as pure virtual. The reason these differences exist actually comes from the relationship and interactions between the DEXT families. Case in point, PCIDriverKit doesn't require a specific subclass because it wants SCSIControllerDriverKit DEXTs to be able to directly load "above" it. Note that the common mistake many developers make is leaving "IOUserService" in place when they should have specified a family-specific subclass (case 2 above). This is an undocumented implementation detail, but if there is a mismatch between your DEXT driver ("IOUserSCSIPeripheralDeviceType00") and your kernel driver ("IOUserService"), you end up trying to call unimplemented kernel methods. When a method is "missing" like that, the codegen system ends up handling that by returning kIOReturnUnsupported. One special case here is the "IOUserResources" provider. This class is the DEXT equivalent of "IOResources" in the kernel. In both cases, these classes exist as an attachment point for objects which don't otherwise have a provider. It's specifically used by the sample "Communicating between a DriverKit extension and a client app" to allow that sample to load on all hardware but is not something the vast majority of DEXT will use. Following on from that point, most DEXT should NOT include "IOMatchCategory". Quoting IOKit fundamentals: "Important: Any driver that declares IOResources as the value of its IOProviderClass key must also include in its personality the IOMatchCategory key and a private match category value. This prevents the driver from matching exclusively on the IOResources nub and thereby preventing other drivers from matching on it. It also prevents the driver from having to compete with all other drivers that need to match on IOResources. The value of the IOMatchCategory property should be identical to the value of the driver's IOClass property, which is the driver’s class name in reverse-DNS notation with underbars instead of dots, such as com_MyCompany_driver_MyDriver." The critical point here is that including IOMatchCategory does this: "This prevents the driver from matching exclusively on the IOResources nub and thereby preventing other drivers from matching on it." The problem here is that this is actually the exceptional case. For a typical DEXT, including IOMatchCategory means that a system driver will load "beside" their DEXT, then open the provider blocking DEXT access and breaking the DEXT. DEXT Launching The key point here is that the entire process above is the standard IOKit loading process used by all KEXT. Once that process finishes, what actually happens next is the DEXT-specific part of this process: IOUserServerName-> This key is the bundle ID of your DEXT, which the system uses to find your DEXT target. IOUserClass-> This is the name of the class the system instantiates after launching your DEXT. Note that this directly mimics how IOKit loading works. Keep in mind that the second, DEXT-specific, half of this process is the first point your actual code becomes relevant. Any issue before that point will ONLY be visible through kernel logging or possibly the IORegistry. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

We have developed an IOPCIFamily based custom KEXT to communicate with Thunderbolt interface storage device. This KEXT is working fine with Apple machines with Intel CPUs in all types of machines (iMac, iMac Pro and MacBooks). We tested this KEXT with Apple Silicon M1 machine where we are observing crash for the very first command we send to the Thunderbolt device. We observed that there is difference in number of bits in Physical Address we use for preparing command PRPs. In Intel machines we get 28-Bit Physical Address whereas in M1 we are getting 36-Bit address used for PRPs. We use inTaskWithPhysicalMask api to allocate memory buffer we use for preparing command PRPs. Below are the options we have used for this: options: kIOMemoryPhysicallyContiguous | kIODirectionInOut capacity: 16kb physicalMask: 0xFFFFF000UL (We want 4kb aligned memory) According to below documentation, we have to use inTaskWithPhysicalMask api to get memory below 4gb. https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/64bitPorting/KernelExtensionsandDrivers/KernelExtensionsandDrivers.html#//apple_ref/doc/uid/TP40001064-CH227-SW1 Some devices can only handle physical addresses that fit into 32 bits. To the extent that it is possible to use 64-bit addresses you should do so, but for these devices, you can either use IODMACommand or the initWithPhysicalMask method of IOBufferMemoryDescriptor to allocate a bounce buffer within the bottom 4 GB of physical memory. So just want to know what's the difference between Intel and ARM64 architecture with respect to physical memory access. Is there any difference between byte order for physical memory address..?? Crash log is given below: panic(cpu 0 caller 0xfffffe0016e08cd8): "apciec[0:pcic0-bridge]::handleInterrupt: Request address is greater than 32 bits linksts=0x99000001 pcielint=0x00020000 linkcdmsts=0x00000800 (ltssm 0x11=L0)\n" Debugger message: panic Memory ID: 0x6 OS release type: User OS version: 20C69 Kernel version: Darwin Kernel Version 20.2.0: Wed Dec 2 20:40:21 PST 2020; root:xnu-7195.60.75~1/RELEASEARM64T8101 Fileset Kernelcache UUID: 3E6AA74DF723BCB886499A5AAB34FA34 Kernel UUID: 48F71DB3-6C91-3E62-9576-3A1DCEF2B536 iBoot version: iBoot-6723.61.3 secure boot?: YES Paniclog version: 13 KernelCache slide: 0x000000000dbfc000 KernelCache base: 0xfffffe0014c00000 Kernel slide: 0x000000000e73c000 Kernel text base: 0xfffffe0015740000 Kernel text exec base: 0xfffffe0015808000 machabsolutetime: 0x12643a9c5 Epoch Time: sec usec Boot : 0x5fe06736 0x0009afbc Sleep : 0x00000000 0x00000000 Wake : 0x00000000 0x00000000 Calendar: 0x5fe067fd 0x0006569d CORE 0 recently retired instr at 0xfffffe0015971798 CORE 1 recently retired instr at 0xfffffe0015972c5c CORE 2 recently retired instr at 0xfffffe0015972c5c CORE 3 recently retired instr at 0xfffffe0015972c5c CORE 4 recently retired instr at 0xfffffe0015972c60 CORE 5 recently retired instr at 0xfffffe0015972c60 CORE 6 recently retired instr at 0xfffffe0015972c60 CORE 7 recently retired instr at 0xfffffe0015972c60 Panicked task 0xfffffe166ce9e550: 75145 pages, 462 threads: pid 0: kernel_task Panicked thread: 0xfffffe166d053918, backtrace: 0xfffffe306cb4b6d0, tid: 141 lr: 0xfffffe0015855f8c fp: 0xfffffe306cb4b740 lr: 0xfffffe0015855d58 fp: 0xfffffe306cb4b7b0 lr: 0xfffffe0015977f5c fp: 0xfffffe306cb4b7d0 lr: 0xfffffe0015969914 fp: 0xfffffe306cb4b880 lr: 0xfffffe001580f7e8 fp: 0xfffffe306cb4b890 lr: 0xfffffe00158559e8 fp: 0xfffffe306cb4bc20 lr: 0xfffffe00158559e8 fp: 0xfffffe306cb4bc90 lr: 0xfffffe0015ff03f8 fp: 0xfffffe306cb4bcb0 lr: 0xfffffe0016e08cd8 fp: 0xfffffe306cb4bd60 lr: 0xfffffe00166bc778 fp: 0xfffffe306cb4be30 lr: 0xfffffe0015f2226c fp: 0xfffffe306cb4be80 lr: 0xfffffe0015f1e2f4 fp: 0xfffffe306cb4bec0 lr: 0xfffffe0015f1f050 fp: 0xfffffe306cb4bf00 lr: 0xfffffe0015818c14 fp: 0x0000000000000000 Kernel Extensions in backtrace: com.apple.driver.AppleEmbeddedPCIE(1.0)[4F37F34B-EE1B-3282-BD8B-00009B954483]@0xfffffe00166b4000->0xfffffe00166c7fff dependency: com.apple.driver.AppleARMPlatform(1.0.2)[5CBA9CD0-E248-38E3-94E5-4CC5EAB96DE1]@0xfffffe0016148000->0xfffffe0016193fff dependency: com.apple.driver.IODARTFamily(1)[88B19766-4B19-3106-8ACE-EC29201F00A3]@0xfffffe0017890000->0xfffffe00178a3fff dependency: com.apple.iokit.IOPCIFamily(2.9)[5187699D-1DDC-3763-934C-1C4896310225]@0xfffffe0017c48000->0xfffffe0017c63fff dependency: com.apple.iokit.IOReportFamily(47)[93EC9828-1413-3458-A6B2-DBB3E24540AE]@0xfffffe0017c64000->0xfffffe0017c67fff com.apple.driver.AppleT8103PCIeC(1.0)[35AEB73B-D51E-3339-AB5B-50AC78740FB8]@0xfffffe0016e04000->0xfffffe0016e13fff dependency: com.apple.driver.AppleARMPlatform(1.0.2)[5CBA9CD0-E248-38E3-94E5-4CC5EAB96DE1]@0xfffffe0016148000->0xfffffe0016193fff dependency: com.apple.driver.AppleEmbeddedPCIE(1)[4F37F34B-EE1B-3282-BD8B-00009B954483]@0xfffffe00166b4000->0xfffffe00166c7fff dependency: com.apple.driver.ApplePIODMA(1)[A8EFA5BD-B11D-3A84-ACBD-6DB25DBCD817]@0xfffffe0016b0c000->0xfffffe0016b13fff dependency: com.apple.iokit.IOPCIFamily(2.9)[5187699D-1DDC-3763-934C-1C4896310225]@0xfffffe0017c48000->0xfffffe0017c63fff dependency: com.apple.iokit.IOReportFamily(47)[93EC9828-1413-3458-A6B2-DBB3E24540AE]@0xfffffe0017c64000->0xfffffe0017c67fff dependency: com.apple.iokit.IOThunderboltFamily(9.3.2)[11617399-2987-322D-85B6-EF2F1AD4A794]@0xfffffe0017d80000->0xfffffe0017e93fff Stackshot Succeeded Bytes Traced 277390 (Uncompressed 703968) ** System Information: Apple Silicon M1 BigSur 11.1 Model: Macmini9,1 Any help or suggestion is really appreciated. Thanks

Hello forum, I'm trying to build communications between a non-MFi HID device (say, a keyboard with a USB-C port) and an iOS device over a MFi-licensed cable with Swift, what framework would you suggest? The USB-C cable is MFi-licensed. The keyboard is not MFi-licensed.

Hello Everyone, I am trying to develop a DriverKit for RAID system, using PCIDriverKit & SCSIControllerDriverKit framework. The driver can detect the Vendor ID and Device ID. But before communicating to the RAID system, I would like to simulate a virtual Volume using a memory block to talk with macOS. In the UserInitializeController(), I allocated a 512K memory for a IOBufferMemoryDescriptor* volumeBuffer, but fail to use Map() to map memory for volumeBuffer. result = ivars->volumeBuffer->Map( 0, // Options: Use default 0, // Offset: Start of the buffer ivars->volumeSize, // Length: Must not exceed buffer size 0, // Flags: Use default nullptr, // Address space: Default address space &mappedAddress // Output parameter ); Log("Memory mapped completed at address: 0x%llx", mappedAddress); // this line never run The Log for Map completed never run, just restart to run the Start() and makes this Driver re-run again and again, in the end, the driver eat out macOS's memory and system halt. Are the parameters for Map() error? or I should not put this code in UserInitializeController()? Any help is appreciated! Thanks in advance. Charles

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, We are experiencing some issues with our USB accessory unexpectedly charging the iOS device it is connected with only when the iOS device supports USB-C and is on iOS 18+ The following is a description of the discrepancy we note between iOS versions: After performing a USB Role switch, our Accessory becomes a typical USB Device and the Apple device becomes the USB host. with iOS 17: 
 The Accessory then sends a PowerSourceUpdate message to the iOS 17 device via iAP2 protocol. Apple device has a USB Type C Connector. * We are specifying: AvailableCurrentForDevice = 0 mA  DeviceBatteryShouldChargeIfPowerIsPresent = 1. Three observations: iPad Battery Settings page -  we observe  'Last charged to…' (indicating no charging) On the Lumify App running (iOS 17), we observe that UIKit.current.batteryState indicated 'Not charging' Battery icon on top right of the screen indicates 'No Charging' with iOS 18: The same Accessory sends the same PowerSourceUpdate message to the iOS 18 device via iAP2 protocol using USB Type C Connector. We are specifying the same: AvailableCurrentForDevice = 0 mA DeviceBatteryShouldChargeIfPowerIsPresent = 1. We observe: iPad Battery Settings page -  we observe  'Charging'  On the Lumify App running (iOS 18), we observe that UIKit.current.batteryState indicated 'Charging' Battery icon on top right of the screen indicates 'No Charging' Please could you help us understand why the Battery status is showing as 'Charging' in the Settings page and with the 'UIKit.current.batteryState' even though we have specified 'AvailableCurrentForDevice = 0 mA'?
 Since our accessory is heavily reliant on the Battery status / Charging state, is there potentially another way we get an accurate battery charging status that we are missing? Or are there other suggestions outside of what we do currently to ensure our accessory does not place the iOS18 device into a charging state?

I'm working on a project to allow HID input from macOS to a connected iOS device. Are we prohibited from matching to a connected iPhone with DriverKit? I see the attribute kCDCDoNotMatchThisDevice for my iPhone is YES when looking at the IO registry and my dext does not initialize

When plugging in my matched USB device I see the logs below. It seems the kernelmanagerd process is sandboxed and can't write out the reason my Dext failed to load. Is there somewhere else I can look for this info? default 11:03:22.175152-0700 kernelmanagerd Received kext load notification: me.keithg.MyUserUSBInterfaceDriver default 11:03:22.177637-0700 kernel 1 duplicate report for Sandbox: icdd(2124) allow file-read-data /Library/Image Capture/Devices error 11:03:22.177681-0700 kernel Sandbox: kernelmanagerd(545) deny(1) file-write-create /private/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/com.apple.kernelmanagerd/TemporaryItems com.apple.libcoreservices error 11:03:22.177711-0700 kernelmanagerd mkdir: path=/var/folders/zz/zyxvpxvq6csfxvn_n0000000000000/T/com.apple.kernelmanagerd/TemporaryItems/ mode= -rwx------: [1: Operation not permitted] error 11:03:22.179361-0700 kernel Sandbox: kernelmanagerd(545) deny(1) file-write-create /private/var/db/loadedkextmt.plist.sb-5a00fc77-LNttZF com.apple.libcoreservices error 11:03:22.177755-0700 kernelmanagerd _dirhelper_relative_internal: error for path <private>: [1: Operation not permitted] com.apple.accessories default 11:03:22.177674-0700 WindowServer Sending analytics event... (eventName: com.apple.ioport.transport.USB.published) error 11:03:22.179913-0700 kernelmanagerd Failed to write extension load report plist.

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.

Hi Apple support, We requested the 4 HID-related Entitlements back in December 2024. Similarly to another post here in the forums that was completely ignored, our request has NOT been processed for months. Mailing the support staff results in boilerplate email responses with no content, calling them results in a chat with very nice people who are unable to help since they can't seem to reach the entitlement team directly. Having to wait for MONTHS when dealing with one of the biggest and supposedly best companies in the world is beyond disappointing. Can anyone help? Is there anyone else that has had this same issue and that has found a work-around? I can share all necessary details. Thanks, Matteo

Hello everyone, I’m working on implementing hardware interrupt handling in DriverKit and came across the InterruptOccurred method in IOInterruptDispatchSource. I noticed that its declaration ends with a TYPE macro: virtual void InterruptOccurred(OSAction* action, uint64_t count, uint64_t time) TYPE(IOInterruptDispatchSource::InterruptOccurred); This structure seems similar to how Timer Events are set up, where an event is linked to a callback and triggered by a timer. I’m attempting to use a similar approach, but for hardware-triggered interrupts rather than timer events. I’m currently in the trial-and-error phase of the implementation, but if anyone has a working example or reference on how to properly implement and register InterruptOccurred, it would be greatly appreciated! Best regards, Charles

Since updating to iOS18.4.1, I can no longer remove Waze from operating in Carplay. It was working perfectly prior to this update where I could view the Waze map on my iPhone 12 Pro, rather than the Carplay map. I prefer to use my iPhone map rather than the Carplay map. Now as soon as I open Waze, despite my having customized and removing it from the Carplay list, while the icon is removed, it continues to open in Carplay! Help! I cannot use Waze using the Carplay maps! Anyone have a solution?

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 units, 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. And the PCI entry in System information app indicates that all devices have normal load of the PCIe device driver.

Hi, our CoreAudio server plugin supports different clock sources. A switch might result in a change of the selectable sample rates (and other settings). On a clock source switch the plugin reconfigures the set of available kAudioStreamPropertyAvailablePhysicalFormats and announces the change via AudioServerPlugInHostInterface::PropertiesChanged(). However at least the Audio MIDI Setup seems to ignore to update it's UI. The changes are first reflected after selecting another device and re-selecting the device of interest. (Latest macOS, M4 macMini) Is this a bug? Or is our CoreAudio server plugin required to indicate the change in the list of available audio formats differently? Thanks!

VirtIO provides macOS VM users on Intel with integrations like Shared Folders, Shared Clipboard or Drag and Drop files. After updating VM to macOS 15.4, the VirtIO is no longer available, and we see that the functionality listed above doesn't work. Please fix it.

Hello all, I am interested in developing a small driver that would facilitate host-to-host communication via Thunderbolt 4/5. While I am aware of features such as Thunderbolt Bridge/Thunderbolt Networking, I find that for my application the overhead is too great. I am interested in sharing a simple, static memory buffer between the two hosts for IO and with some synchronisation primitives. The idea being that the communication is facilitated between different platforms. Would it be possible to develop a driver/service like this? Currently, going through the documentation, to use PCIDriverKit specifying a Vendor and Product Ids is required, so I doubt that this is a viable path. I know that Linux exposes the "XDomain" protocol to announce thunderbolt services (This is the same protocol that is used in macOS to discover Thunderbolt Networking peers). Is this functionality exposed to macOS driver developers?

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!

We submitted a request a couple years ago to Apple through the feedback system to add 1 custom vid/pid to the com.apple.DriverKit-AppleUSBFTDI driver. They added it to Monterey and it appears in all macOS versions since Monterey. Not long after submitting this request, we sent a follow-up request to add 2 more pids (same vid, and same personality). Apple eventually added these as well. They appear as an array of pids under the same personality. We are 2 weeks from releasing one of those products (added in the second request) and are just now realizing that the second request was only honored on Sequoia (this fact was masked by us using a temporary ftdi vid/pid during development while waiting for Microsoft to resolve an issue related to adding custom vid/pids to FTDI's Windows driver). All other versions that we are supposed to support (Monterey thru Sonoma) only have the first device. None of the devices from the second request are listed, and consequently this device doesn't match and doesn't expose as a serial port as it should. Our application that works with these devices supports Monterey and up, and we desperately need all devices that we have submitted so far to be available on Monterey and up (thru system updates). I tried starting a code-level support ticket, but they don't have a category for this problem. The feedback mechanism is a black box. You submit the request and get no response. You just wait for weeks/months and then it just appears one day. That was fine then, but we're now in an emergency situation. (FTDI's own dext driver, last time we tried it at least, was unable to be installed after being customized, and they admitted to us during email support that there was some issue on the Apple side that was preventing it from being customized. They haven't updated the dext driver since then, so I assume the situation is still the same) What can we do?

How can I get the Testflight invitation code

On iOS17, UIDevice.current.batteryLevel is returning values rounded to 0.05, such as 1, 0.95, 0.9.

"Bu beta şu anda yeni testçileri kabul etmiyor" Lütfen bu hatayı düzeltin