iPadOS 17.7.7

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.

Is there an entitlement that can be applied that allows access to the serial port properties of an attached USB device? No there is not. FYI, even if IOKit let you access the necessary properties, the file system sandbox would block you from accessing the device node. On iPadOS, IOKit is really ONLY useful for finding and communicating with DriverKit user clients, as the sandbox basically blocks access to everything else. Or do I need to implement my own USBDriverKit driver for this device, as seems to be implied in these forum threads: Yes, that's what you need to do. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

The adaptable gray colors are only supported on iOS, iPadOS, visionOS and Mac Catalyst. If you'd like us to consider adding the API functionality to tvOS, please file an enhancement request using Feedback Assistant. Once you file the request, please post the FB number here. If you're not familiar with how to file enhancement requests, take a look at Bug Reporting: How and Why?