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.

I don't know what "bounces the interfaces" means. You seem to be saying "my USB to Ethernet adapter does not come up properly after the I use the networksetup or ifconfig commands to bring it down then back up again" have you tested whether similar commands produce the right response from the same hardware on another platform? This might be a problem with the off-brand hardware, rather than the commands provided by macOS.

There's com.apple.developer.driverkit.allow-third-party-userclients for iPadOS.

You've got a property of your model which is complex to calculate (availableWords) and depends on two other properties (cardPile and languageChoice). That dependency has nothing to do with UI. You can make a custom setter for cardPile and languageChoice which calls updateAvailableProperties. That satisfies the dependency, independent of UI code. In the UI, bind to languageChoice and cardPile. That makes the intent clear. The connection between those two properties and changes to availableWords is only visible in WordsManager, your UI doesn't need to know about it.

did you build on your M3 machine and copy the app manually from it to the Intel machine? You have elected to build both architectures (for development), but if you just hit Build or Debug, you'll get the active architecture only. You need to Archive then select Distribute for Debugging, for example. Or, change the Build Active Architecture Only setting to 'no' and just copy your local build.