that's interesting. I have version 666.4.0 of USB Prober, and it works for viewing USB descriptors on Apple Silicon (for me). It does a fine job of displaying parsed descriptors, better than the utilities I have found on Windows. I don't use it for anything else. I probably installed it long ago on an Intel machine, and the binary runs on my M1 Mac. The code is ancient - the logging function appears to rely on a kernel extension which simply isn't there any more. Related source code is at https://opensource.apple.com/source/IOUSBFamily/IOUSBFamily-540.4.1/USBProberV2/, in case anyone wants to stake a stab at modernizing it.

I tried again with a different iPad and the same configuration - it worked as expected. When I returned to the original iPad, wiped it, re-enrolled it, and re-installed the profile, that iPad worked as expected too.

man readdir ?

Please see here https://developer.apple.com/support/compare-memberships For your own use on your own machine, you can "sign to run locally", and make up a bundle identifier for your app. If you need restricted entitlements, you need a paid account to request them. I don't know what you mean by "signingkey" and "signingkeyId". Are these Apple things or AWS things?

reply to the review team and tell them it is an Xcode bug, you're welcome to refer to the bug I filed FB13688443 "Xcode strips App Sandbox entitlement from dext". It would be good if you filed your own bug. Here are my steps to reproduce: create a new macOS project. observe that the newly-created app target in the project has a .entitlements file. By default, that .entitlements file contains an App Sandbox = YES entry. add a new DriverKit project to the target observe that the dext target does not have a .entitlements file. Note that this page https://developer.apple.com/documentation/driverkit/requesting_entitlements_for_driverkit_development says “Xcode provides a default entitlements file for every new DriverKit driver you create. “ no, it doesn’t. Archive the application, then export the archive to a local copy. Use codesign -dvvv —entitlements - to dump the entitlements of the dext. Return to the Xcode project, add a DriverKit capability to the dext target using the + button on the Signing and Capabilities page. This causes a .entitlements file to be added to the dext target, but it doesn’t have an App Sandbox entitlement in it. This page: https://developer.apple.com/documentation/driverkit/requesting_entitlements_for_driverkit_development says “The default driver entitlements file contains only the DriverKit and App Sandbox entitlements.” But it doesn’t contain any entitlements by default. In the newly-created .entitlements file for the dext, add two entitlements, one called “Fake-entitlement”, and the App Sandbox entitlement. Archive the app again, export it to a local copy, and examine the entitlements of the dext now. App Sandbox is absent, but Fake-entitlement is present.

are you building for development or for distribution? The auto-generated profile for a development build will include the "*" wildcard for idVendor. Your entitlement for your driver (which you specify should contain the specific vendor ID values, just like your IOKit personality dictionary. When you build for distribution, you have to do some steps manually. There was a fairly recent post about this by Kevin Elliot, but of course I can't find it now.

I think you need to re-phrase your question. The question in your title is fairly easy to answer. By default, a variable declared in any one .swift file in your program is available to any other .swift file in your program. (search for "Access Levels" in the Swift Programming Language reference from Apple). I don't understand what you mean by "files, settings and home" here.

in the past, I've received emails from dts with case ID numbers, usually the same day I submitted the request. An actual reply from a person takes a bit longer, depending on weekends, holidays, the complexity of the request.

Hi @KivancG I "solved" the problem by contacting the app review team and referencing the bug, FB13688443.

If I understand you correctly, you are re-declaring struct A, exposed via a pointer in the SDK, from a 1000 byte struct to a 1400 byte struct. If it is allocated in the SDK (1000 bytes), and you memset it from main (1400 bytes), memset will run off the end of the struct and overwrite 400 bytes of memory, somewhere, with unpredictable effects. Did you expect this to reliably crash at any time, on any OS? Did you expect it to be benign? memset will do what it is asked to do.

A timeout value of 0 means "never" (https://developer.apple.com/documentation/usbdriverkit/iousbhostpipe/3182647-asyncio). Your request is either never being delivered to the bus, or is being ignored by your device. In circumstances like these, I like to hang a USB analyzer on the bus to see what the device is actually doing. Also check all the return values from your calls.

You say the container has JIT related feature, so you add a com.apple.security.cs.allow-jit entitlement, or something similar. But you say that the error message is about Hardened Runtime relaxation entitlements disallowed on System Extensions. Did you apply the entitlement to the container, or the extension?

Thank you Kevin! The collision was with IOUSBLib. I would have expected kIOReturnExclusiveAccess but I understand how boolean return values aren't very informative. For future readers of this issue, if you run IORegistryExplorer (from the Additional Tools for Xcode download), and look for the device you have problems with, you can see an object with a IOUserClientCreator property of the form "pid=1234, The Nasty App". In a large tree, you can search for the problematic object by name using the search field at the top of the window, select it, then clear the search field, scroll the window to bring the object back into view, and its attached descendants.

@AndyTouchgram yes, that's the implication, but it isn't new. If you only use the Xcode IDE, you never need to use Xcode-select. Within Xcode, you are using the SDKs embedded within that copy of Xcode. As the built-in help for xcode-select says, it only affects command-line tools and other tools that depend on those: "Print or change the path to the active developer directory. This directory controls which tools are used for the Xcode command line tools (for example, xcodebuild) as well as the BSD development commands (such as cc and make)."

You can use a single project for the enclosing app. Use the "Supported Platforms" build setting to build for both macOS and iPadOS. The dext is built for the DriverKit platform. At the project level, you can create different configurations, e.g. Debug (iPad) and Debug (macOS), use .xcconfig files to change the few things that may need to change between macOS and iPadOS, for example the bundle ID of the driver. The driver would be the same for macOS and iPadOS, using the same entitlements file - macOS-only entitlements have no effect on iPadOS, and vice-versa. You can use Automatic signing for development on both the app and the driver, on both platforms.