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.

Well, that was unexpected, but good to know.

HI capsmaldon2. Sorry for the delay replying, the forum design change seems to have caused all my watched threads to be ignored, or comments don't cause a notification. Comments are not very useful, in my opinion, so here's another reply. It sounds like you're making a camera extension and a support framework, for use by multiple third parties. As you say, on iOS there's a requirement that the bundle ID of the dext begin with the bundle ID of the enclosing app. You asked [quote='751800021, Capsmaldon2, /thread/751800, /profile/Capsmaldon2'] Am I missing something? Or is it expected that we should have to build a new driverkit extension with a different bundle ID for every app that every third party wants to develop? [/quote] I think the answer is "yes" - at least a new dext with a different bundle ID for every different app which installs that dext. Multiple apps can use the dext. I I suggest that you configure your targets so that the differences are described in xcconfig files. This way, you only have one dext target and one framework target. Making individual per-customer targets is possible, but doesn't scale well. When you're developing for in-house testing, use your default configuration, when you're building for distribution to your customers, use the other configuration. You can select another configuration with xcodebuild --configuration. You make new configurations at the Project level, which is where you indicate on a per-target basis what config file is used for each configuration. Does your dext match against different hardware for each customer? I foresee some possible conflicts if end users install multiple copies of your dext from different vendors.

Thank you, Quinn for your in-depth steps. I tried steps 1 through 6 locally and they worked, so I had another look at the libraries I'd been given. The problem was, they had their quarantine flag set (because they emanated from a .zip file from my vendor). If I use Finder or cp to copy these files, the quarantine flag is preserved, but it seems to be removed if Xcode copies the files in a Copy Bundle Resources phase, which is why the tool linked and ran when it was inside a folder in an app bundle - nothing to do with the app bundle, rather a side effect of using Xcode to copy the files. Does the forum allow one to accept two answers to a problem?

Thank you for pointing out mergeable libraries, I didn't know about those. I already enabled the hardened runtime on the command line tool, and didn't check any of the boxes which relax it. I'm stumbling over the double negative in "make sure not to disable library validation" though. You said "this disables the Gatekeeper check...", but does "this" mean library validation or disabling library validation? I couldn't get the dylib to be used at all at runtime without packaging the tool and its dylib inside an app bundle - that's the part I find most inconvenient. The tool is used as a test harness for the library, which includes code that I would like to be able to debug.