iPadOS 17.7.7

This issue still reproduced on iPadOS 26.0.1 - anyone encountered the same issue?

Is it possible for a macOS (or iOS/iPadOS) app to communicate with a CCID-compliant reader using the CCID interface (i.e., directly sending the PC_TO_RDR_* messages) instead of using the CryptoTokenKit API? It depends on exactly what you're trying/willing to do: If you specifically want a CCID level interface, then no, we don't really have an API for that. If you're willing to send USB commands, then the IOUSBHost Framework can be used to interact directly with the device (this is the API our driver actually uses)*. Note that this might require using a codeless DEXT to prevent our implementation from claiming the device. *The framework documentation says the framework is used to Create host-mode user space drivers for USB devices, however, that's just a complicated way of saying “let apps directly send USB commands to devices. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Thanks a lot! ...adding external-accessory is not changing ANYTHING about how your app wakes/sleep in the background. You will not be allowed to use it, but that's because it's not relevant to your app. In my tests 2 weeks ago I (might be by my mistake) saw a correspondence between external-accessoryand the facts of callbacks from IOServiceAddMatchingNotification. Or at least correlation with the moments of such callbacks at the time of application moves from background to foreground. Having your unambiguous statement I tediously rechecked my environment now and I found 2 possible weak-points: A) I conducted the tests above having 2 identical DExts (for 2 different but very similar UserClient-Apps) formally enabled in Settings|Applications|Drivers. Though, of course, only one UserClient was active. I shall repeat the test (on near weeks) with single DExt physically installed. Another Q&A in TestFlight was being conducted in distant country. I shall reconfirm about the environment there. B)To distinguish t

There's an interesting update in the documentation for ASKit AccessorySetupKit is available for iOS and iPadOS. In watchOS 26 and later, if someone sets up an accessory with your iOS app by using AccessorySetupKit, a companion watchOS app can also use CoreBluetooth to communicate with the new accessory and any other accessories. I was playing so far, in watchOS 26, with: retrieveConnectedPeripherals(withServices: retrievePeripherals(withIdentifiers: But with no luck atm to make it work. I can confirm instead that now that if I run your app @SuperTurboRyan I can use ASKit in iOS and scan in watchOS without hitting anymore the permission error.

So, first off, there are two critical details I need to clarify: Note in MAC OS everything (same DExt and UserClient-code) works fine in the background and in the foreground. macOS doesn't implement any of the app suspension semantics iPadOS does, which means you can't really compare the behavior of the two systems. That leads to here: 1 variation A) UserClientApp has attribute [Background modes][Enable external communications]. The external-accessory background mode is totally unrelated to DriverKit and isn't actually doing anything in your app. It allows apps using the ExternalAccessory framework to communicate with their accessory in the background, but that framework (iOS 3.0) and the background mode (iOS 4.0) are MUCH older than DriverKit. Making this as explicit as possible: B) A way to pursue Apple-store to accept (without MFI) an UserClientApp with [Enable external communication]. ...adding external-accessory is not changing ANYTHING about how your app wakes/sleep in the background. You will

Following up with this to clear up some odds and ends: Provisioning profile ... doesn't match the entitlements file's value for the ... userclient-access entitlement. One thing to be aware of here is that Xcode has a bias in the way it presents codesign errors where it assumes the Entitlement.plist is correct and the profile is wrong. However, in practice that's basically never the case with DriverKit entitlements and tends to lead to a lot of flailing trying to somehow fix the provisioning profile. This error ALWAYS means that the entitlement.plist doesn't match the profile. You fix that by: Changing the Entitlement.plist to match the profile. Changing the actual profile. That means either: Submitting a new request to correct any mistake (this case). IF you have been granted multiple instances of the same entitlement, then you switch to manual profile generation and manual codesigning. See this forum post for more details on that flow. However, the key here is to understand that this: ...our hypothesis is th

are you developing for macOS or iPadOS, or both? com.apple.developer.driverkit.communicates-with-drivers is for iPadOS. It won't do any harm to set this to true in a macOS app, but you don't need it. When you say your driver fails at runtime, there are various ways this can occur: it fails to load (perhaps due to an entitlement issue), your code fails to find the driver your code finds the driver, but fails to open a user client for it It sounds like you're failing at stage 2. Look in the system log for messages related to your driver's bundle ID. I like to plug in the device, then run log collect --last 1m and peruse the resulting log file in the Console app. Use IORegistryExplorer (part of the additional tools for Xcode) to look for your driver in the IORegistry. If it isn't there, IOServiceGetMatchingService won't find it. IOServiceGetMatchingService takes a matching dictionary as a parameter, but you said you are calling IOServiceGetMatchingService(DriverKitAcxxx) Did you mean IOServiceN

@pcfist Thanks for the confirmation. I'll give it a try when I get a chance. Unfortunately I am spending most of my time finding and reporting macOS/iPadOS/iOS 26 bugs that are impacting my app. Then I waste time trying to find work arounds since Apple isn't fixing any of the issues.