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 issues 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. (USB & PCI) Edit your Entitlement.plist to include the correct "Development Only" configuration: USB Development Only Configuration: <key>com.apple.developer.driverkit.transport.usb</key> <array> <dict> <key>idVendor</key> <string>*</string> </dict> </array> PCI Development Only Configuration: <key>com.apple.developer.driverkit.transport.pci</key> <array> <dict> <key>IOPCIPrimaryMatch</key> <string>0xFFFFFFFF&amp;0x00000000</string> </dict> </array> 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. Debugging Automatic Code-signing In a new project, the flow I describe above should just work; however, if you're converting an existing project, you may get code signing errors, generally complaining about how the provisioning profile configuration doesn't match. In most cases, this happens because Xcode is choosing to reuse a previously downloaded profile with an older configuration instead of generating a new configuration which would then include the configuration changes you made. Currently, you can find these profile files in: ~/Library/Developer/Xcode/UserData/Provisioning Profiles ...which can make it easier to find and delete the specific profile (if you choose). However, one recommendation I'd have here is to not treat the contents of that folder as "precious" or special. What automatic code signing actually does is generate provisioning profiles "on demand", so if you delete an automatic profile... Xcode will just generate it again at the next build. Manually generating profiles is more cumbersome, but the solution there is to preserve them as a separate resource, probably as part of your project data, NOT to just "lose" them in the folder here. If they get deleted from Xcode's store, then you can just copy them back in from your own store (or using Xcode, which can manually download profiles as well). The advantage of this approach is that when profiles "pile up" over time (which they tend to do), you can just delete[1] all of them then let Xcode regenerate the ones you're actually trying to investigate. In terms of looking at their contents, TN3125: Inside Code Signing: Provisioning Profiles has the details of how to see exactly what's there. [1] Moving them somewhere else works too, but could indicate a fear of commitment. __ 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 DEXT attaches to and works through. 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

I am developing a USB MTP device for use with macOS. When the device is connected while Preview is running, I observe the host send OpenSession, then GetDeviceInfo, and then no further MTP commands. I do not see a later CloseSession. Problem is that once this happens, exclusive access to the USB interface is retained, so another application cannot connect to the device. From the device side, there is no obvious way to recover except forcing a USB disconnect/reset or shutting down the USB interface. My questions are: Is this expected behavior for Preview, or for a Preview-related macOS helper? Is it expected on macOS that a client may open an MTP session and then leave it idle without sending CloseSession? I am mainly trying to understand whether this is expected macOS behavior, or whether this should be considered a bug.

I might be trying to achieve the impossible here, but if there's another way to go about it any advice would be appreciated. I've got an older Linux application that reflashes firmware on a connected USB HID device that I'm trying to port to macOS. Essentially the device starts as an HID interface (0x03/0x01/0x01) but to update firmware receives a simple control payload and then restarts and connects as a different (non-HID) device. However I can't open the HID device at all, I'm guessing this is some sort of permission error (SIP?). AppleUSBHostUserClient::openGated: failed to open IOUSBHostDevice... provider is already opened for exclusive access by AppleUSB20Hub hid_open_path: failed to open IOHIDDevice from mach entry: (0xE00002E2) not permitted AppleUSBXHCICommandRing::setAddress: completed with result code 4 AppleUSBHostPort::createDevice: failed to create device (0xe00002bc) AppleUSBIORequest ... transaction error ... 0xe00002ed Is there any way at all to do this on macOS? Interestingly if you run a Windows VM in VMWare or similar and connect the device to that VM it works, so there's obviously some way but I'd like to create a simple standalone tool.

Hello, I have crated a DriverKit driver for macOS and iPad M-series if I ever get the mac driver working. I have the correct entittlements, and matching provisioning profile downloaded manually. The driver loads (no errors!), and is visible in ioreg below the usb device (when plugged). The issue is that I never get any log from the driver, have reduced to minimal working code (below). When I debug with lldb, I load the symbols for my driver and break on init and Start - but lldb never triggers == never calls start or init. This is also why no logs. When I unplug the device, the driver process (ps aux) keeps running, causes a hard crash of the Mac with dext remove/or kill driver.dext process. I have asked Claude - but its just running in circles: check Info.plist=ok, check entitlements=ok, check code (minimal)=ok, check iig=ok, check provisioning profile=ok, check build settings=ok, check ioreg=ok, check code signature=ok, start over I don't get any log from my driver, which is consistent with init() not being called. All logs from kernel & friends (AMFI) do show the driver loading - no errors. Any tips appreciated! // USBDriver.iig #ifndef USBDriver_h #define USBDriver_h #include <USBDriverKit/IOUSBHostInterface.iig> class USBDriver: public IOService { public: virtual bool init() override; virtual void free() override; virtual kern_return_t Start(IOService * provider) override; virtual kern_return_t Stop(IOService * provider) override; }; // USBDriver.cpp #include <os/log.h> #include <DriverKit/DriverKit.h> #include "USBDriver.h" bool USBDriver::init() { if (!super::init()) return false; os_log(OS_LOG_DEFAULT, "terminal.driver: init()"); return true; } kern_return_t IMPL(USBDriver, Start) { os_log(OS_LOG_DEFAULT, "terminal.driver: Start()"); kern_return_t ret = super::Start(provider); if (ret != kIOReturnSuccess) { os_log(OS_LOG_DEFAULT, "terminal.driver: super::Start failed: 0x%08x", ret); return ret; } os_log(OS_LOG_DEFAULT, "terminal.driver: Start() success"); return super::Start(provider); } kern_return_t IMPL(USBDriver, Stop) { os_log(OS_LOG_DEFAULT, "terminal.driver: Stop()"); return super::Stop(provider); } void USBDriver::free() { os_log(OS_LOG_DEFAULT, "terminal.driver: free()"); super::free(); }

Hi, I’m looking for clarification from folks familiar with CoreHID rather than App Review, as the guys there have not responded to my post (https://aninterestingwebsite.com/forums/thread/820676) We have a sandboxed macOS app that creates a virtual HID device (HIDVirtualDevice) as described in Creating virtual devices https://aninterestingwebsite.com/documentation/corehid/creatingvirtualdevices To work at all, the app requires the entitlement: com.apple.developer.hid.virtual.device With this entitlement present, macOS shows the system prompt requesting Accessibility permission App would like to control this computer using accessibility features. Grant access to this application in Security and Privacy preferences located in System Preferences. when HIDVirtualDevice(properties:) is called. There is no mention of Accessibility in the HIDVirtualDevice documentation, but the behavior is reproducible and seems unavoidable. My question is therefore: Is creating a virtual HID device from userspace via HIDVirtualDevice considered inherently incompatible with Mac App Store distribution? In other words: Is the Accessibility prompt an expected side‑effect of this API? And if so, does that mean using HIDVirtualDevice is only practical for direct (non–App Store) distribution unless the app is explicitly an accessibility tool? I’m not asking about review policy details—just whether, from a technical/system point of view, HIDVirtualDevice is actually intended to be usable by App Store apps. For context, there seem to be public, non‑accessibility uses of Apple’s virtual HID infrastructure, like this recent post: https://aninterestingwebsite.com/forums/thread/820708 and corresponding Github repo this project. I don't know if these intend to use the App Store, but they might end up in the same situation. Any insights from people who’ve worked with CoreHID would be greatly appreciated. Thanks, Magnus

I requested "DirverKit UserClient Access" Entitlement, But I Distribute App failed. I don't know the reason. I think when I request "DirverKit UserClient Access" I make a mistake. I fill in two Bundle ids in the "Request a System Extension or DriverKit Entitlement" form's "UserClient Bundle IDs" item. The reason is when I Add "DirverKit UserClient Access" Capability in the project of Xcode. The .entitlements file is like this: <string>com.turing.TuringTouch com.turing.TuringTouch.TouchDriver</string> But in "Signing" of Xcode's "Bundle Identifier" can fill in only on "Identifier" therefore they do not match. So I can't Distribute App. I reapply "DirverKit UserClient Access" Entitlement. But decline. The result is "decline". Please help me. Please tell me, how should can I do now? Thank you very much.

Hello! I have app (macos and iPadOS platforms) with empbedded DEXT. The DEXT executable runs fine on both platforms (ver 26.2). Trying to execute from iPad App code: let sysExtWs = OSSystemExtensionsWorkspace.shared let sysExts = try sysExtWs.systemExtensions(forApplicationWithBundleID: appBudleId) but always getting OSSystemExtensionError.Code.missingEntitlement error. Which entitlement am I missing? Thank You!

iPhone16PM Clean DFU, no restore, no tweaks. Started on iOS 26.4.3 and still happening on iOS 26.4. Triggers: ∙ Editing Home Screen widgets ∙ Heavy media in Safari ∙ ProMotion UI transitions Panic log — 0x8badf00d watchdog timeout: userspace watchdog timeout: no successful checkins from SpringBoard in 180 seconds. service: backboardd Drivers: com.apple.driver.AppleAVD + com.apple.iokit.IOSurface Is there a solution for this? Thank you.

Have a 2019 Ford Edge w/ Sync 3.4, wired carplay. Worked fine w/ iPhone 16 Pro on iOS 18. Upgraded to iPhone 17 Pro, came w/ iOS 26, carplay hasn't worked since. I've kept trying throughout new iOS 26 releases, lately with iOS 26.3 Public Beta 1, still not working. Have a long running issue with updates and system diagnostics as I've tried over the last few months: FB20739050 There is also a Apple support community thread with issues like this (and a ton of others) - my first post there was https://discussions.apple.com/thread/256138283?answerId=261613103022&sortBy=oldest_first#261613103022 I'm hoping here in the developer forums someone can maybe take a look at the feedback item and various system diagnostics to pin-point the issue. I'm a little concerned it's still not fixed this far into the follow-up point releases of iOS 26. Appreciate any help, thanks! --Chuck

I have two Macbook Pros: 14" M4 Pro (company) 16" M4 Max (personal) I work remote full-time and recently purchased 2 of the new Studio Display XDRs. Everything works perfectly however I chose to connect them to the M4 Max. I have a caldigit Element TB5 hub and can daisy chain both monitors through that perfectly. With that said, no matter how I plug them into the M4 Pro I can only ever get one to light up at a time. What I have tried to resolve it: Plug them in individually to the m4 pro Plug them in one at a time, force them to 60hz and then plug them both in. Daisy Chaining the displays Daisy Chaining the displays through the TB5 Hub Nothing works. Only one display comes on and its whichever is plugged in first. I have even tried lowering the refresh to as low as it goes on both manually then plugging them back in. Still nothing. From what I am reading it appears to be that the M4 Pro has 3 display lanes and when I plug the first studio display XDR it is using 2 lanes. If I go down to 60hz which is what the original studio display was, then it should theoretically go down to 1 display lane allowing a second to be plugged in. A bunch of people had the older studio display running 2x 5k ASD monitors on the M4 Pro. Now with the latest Studio Display XDR I am stuck. I was researching possibly editing the EDID of each to mimic the older studio display, but I don't know how to do that easily without BetterDisplay and right now I have no ability to install that. There is a chance I can get approval to run commands / BetterDisplay to get this working if a solution can be found. What I think the ultimate fix is for the firmware / macOS to realize the limitation, force the studio display XDR to 60hz when a second monitor is plugged in and they both would work. A single Studio Display XDR could run 120hz, but immediately upon plugging a second one it swaps to 60hz. I am completely fine with that scenario. I have found a few discussions about this topic with the main one being on apple discussions: https://discussions.apple.com/thread/256262701?sortBy=rank&answerId=261888577022 Someone sort of gave me this idea on Mac because they were trying to use the studio display XDR on windows and it appears to have worked with cloning an older ASD EDID on the new model: https://www.reddit.com/r/mac/comments/1s3ani5/got_studio_display_xdr_working_on_windows_pc_5k/ I don't really know what else to do. I opened a ticket with support. Case # 102853480566, but it went no where. I got disconnected during the first call after describing everything and when they reached back out they didn't even give me 2 seconds to pick up and they hung up and closed the ticket. I really don't want to return the displays because they are beautiful and work beautifully on the m4 max. They should work with 60hz on the m4 pro. Who / How / When can we get this resolved? I would be happy to work with an Apple dev / engineer to help resolve this.

I’m prototyping a personal-use system that lets an iPhone with a physically attached controller act as an input device for a Mac. End goal: Use the iPhone as the transport and sensor host Use the attached physical controller for buttons/sticks Map the iPhone gyroscope to the controller’s right stick to get gyro aim in Mac games / cloud-streamed games such as GeForce NOW that don't support the gyro. What I’m trying to understand is whether Apple supports any path for this on macOS that does NOT require restricted entitlements or paid-program-only capabilities. What I’ve already found: CoreHID virtual HID device creation appears to require com.apple.developer.hid.virtual.device HIDDriverKit / system extensions appear to require Apple-granted entitlements as well GCVirtualController does not seem to solve the problem because I need a controller-visible device that other apps can see, not just controls inside my own app So my concrete question is: Is there any supported, entitlement-free way for a personal macOS app to expose a game-controller-like input device that other apps can consume system-wide? If not, is the official answer that this class of solution necessarily requires one of: CoreHID with restricted entitlement HIDDriverKit/system extension entitlement some other Apple-approved framework or program I’m missing I’m not asking about App Store distribution. This is primarily for local/personal use during development. I’m trying to understand the supported platform boundary before investing further. Any guidance on the recommended architecture for this use case would be appreciated.

I'm in the process of writing a DriverKit USBHostInterface driver, and while I'm finally starting to get there, I've run into a bit of a frustration with logging. Naturally I have a liberal amount of os_log calls that I'm using to troubleshoot my driver. However I've noticed that they don't show up until after the first time my driver has loaded. Meaning, for example, suppose I make a new build of my driver and it's bundled user-mode app, install the bundle to /Applications, run the installer, verify it took with systemextensionsctl list, fire up Console and start streaming log entries, then plug in my device. I can see the log entries that show that my driver is loaded, etc., then a bunch of kernel -> log entries, but none of my Start method log entries. If I unplug my device and plug it in again, my log entries show up as expected. Why is this and, more importantly, how can I fix it? I'd like to see those log entries the first time the driver loads, if I could.

Trying to use IOLog to print out a message from a dext. When I try to use IOLog, I get , though I did not or thought I did not tag it as private. I have tried to update the info.plist file for the dext according to https://aninterestingwebsite.com/forums/thread/705810, but that has not helped, or perhaps I am not defining it correctly since it's a dext. Anyone else had this issue, and how did you fix it?

Hi Everyone, We are currently migrating a mature legacy KEXT to DriverKit for our PCIe SCSI storage controller (connected via Thunderbolt 3). During the DEXT load sequence, we have observed that the system automatically triggers a power state transition from State 0 (Off) to State 2 (On). However, this process results in a Kernel Panic due to a timeout after approximately 21 seconds. We have verified that our implementation of Start_Impl, UserInitializeController_Impl, and SetPowerState_Impl executes extremely fast, with a total execution time of less than one second. Specifically, SetPowerState_Impl returns kIOReturnSuccess immediately upon being called. Furthermore, our current Info.plist does not contain any IOPowerManagement dictionary or related keys. Despite the fast execution and the absence of explicit power management declarations in the plist, the kernel power management state machine (IOServicePM) still generates a 21-second timeout, leading to the following panic: Panic Log: panic(cpu 7 caller 0xfffffe0020be8fec): MySCSIDriver::setPowerState(0xfffffe2fb1a65c00 : 0xfffffe0020bfed88, 0 -> 2) timed out after 21257 ms @IOServicePM.cpp:5609 com.example.driver.dext: ( id: com.example.driver.dext; path: /Library/SystemExtensions/[UUID]/com.example.driver.dext; state: loaded ) Note on Previous Discussion: I would like to express my gratitude to Kevin from Apple DTS for the helpful discussion regarding the implementation of BundleParallelTask on the forums. Since then, we have shifted our development focus toward completing the overall management ecosystem, delivering a comprehensive operational interface for users, and handling specific user environments and behaviors. Our current priority is ensuring system stability—specifically resolving these Thunderbolt-related power management issues (sleep/wake)—to prepare the product for upcoming testing. I remain very grateful for the guidance provided on batch task optimization and intend to resume those optimizations once this critical stability baseline is secured. Technical Guidance Needed for PM Migration In our legacy KEXT, we utilized PMinit(), registerPowerDriver(), and joinPMtree() to precisely control the timing of power management registration. In transitioning to the DriverKit SDK, we have not found clear guidance on several key points: Standardized Migration Path: What is the recommended way to implement equivalent power management initialization (formerly PMinit) within a DriverKit subclass? In DriverKit, how should we replicate the behavior of manually calling registerPowerDriver and joinPMtree to ensure the driver is only monitored once the hardware is ready? Implicit Power Registration: Why does the system enforce a setPowerState(0 -> 2) transition on a subclass of IOUserSCSIParallelInterfaceController even when no IOPowerManagement dictionary is defined in the Info.plist? Is this a default behavior of the SCSI or PCI transport framework? Thunderbolt Specifics: Are there specific power proxying requirements or configurations for PCIe devices over Thunderbolt to avoid conflicts with the default IOPCIFamily power policies? Best Regards, Charles

I have a custom hardware board that I want to communicate serially with from an iPad. Should I use the DriverKit route or the MFi route?

I have a custom hardware board that I want to communicate serially with from an iPad. Should I use the DriverKit route or the MFi route?

While I welcome the arrival of a userspace implementation of drivers, DriverKit as it stands has some notable flaws. My main concern is the ability of open-source projects like HoRNDIS being able to access paid developer accounts and the limited entitlement scope (plus the waiting period) for what is essentially a hobbyist free project. Even if the developer is a professional company, some legacy hardware will go unsupported because of a lack of support from the vendor. Providing a way for users who need access to older hardware would be needed. Three concrete requests: A class-level or wildcard VID/PID entitlement for open source projects with a verifiable public repository A free or reduced-cost entitlement path for non-commercial volunteer-maintained drivers Published approval criteria and timelines so projects can plan accordingly Depreciating kexts without providing an accessible successor for community projects isn't security, it is gatekeeping access to hardware that is critically needed. Is this use case on the roadmap at all? Developers deserve a clear answer.

When printing image/photo files via AirPrint, selected finishing options (e.g., Punch) are not applied unless a preset is chosen. reproduction steps: Select an image on iOS Tap Print → choose printer/server Set Finishing Options → Punch Print Observed: Finishing options not applied IPP trace shows no finisher attributes in the request working scenario: Select any Preset (e.g., Color) before printing Finishing options are then included in IPP and applied Note: Issue does not occur when printing PDFs from iOS; finisher attributes are sent correctly. Is this expected AirPrint behavior for image jobs, or could this be a bug in how iOS constructs the IPP request for photos?

Hi everyone, I observed a behavior with AirPrint from an iPhone and wanted to confirm if this is expected behavior from iOS. Scenario tested: File type: Photo Print-quality selected by the user: Normal Observation (from packet capture): When checking the PCAP for the request sent from the iPhone, the print-quality attribute is always sent as high, even though the user selected Normal in the UI. Question: Is this an expected behavior in iOS/AirPrint where photos are always sent with print-quality=high regardless of the user-selected print quality? Or could this be a bug?