build disappears

Any suggestions would be great. Most of the Apple documentation on USB ports is like 20 years old, and the new stuff pushes you towards DriverKit. Making this explicit, trying to do this with DriverKit is a great way to make a lot of extra work for yourself without any real benefit. You MIGHT need a codeless DEXT, but that's very different than actually using DriverKit. The USB Host framework is exactly what you want to use. I have been able to open an inservice to the device at the top level, but I get an error when I use it. What's the device? The typical issue here is that one of the class drivers has claimed the device, which blocks your access. Assuming that's the case... I started using DeviceKit, but I received signing errors. I shouldn't have to go down that path just to dump data from a USB port? ...then a codeless DEXT will let you push our driver out of the way. The article Overriding the default USB video class extension has an overview of what's involved. On the codesigning side: I started using

I'm not sure why Xcode Signing Certificate status is Failed with the above configuration. It doesn't seem to me that DriverKit and the provisioning file expect & as the expected value. Based on the above, isn't it Xcode that expects &? I'm suspicious of Xcode's behavior. I was able to get a look at your account configuration this morning, and I think I can explain what's going on. For reference, I looked at the bundle with this structure: com.0.DextPCIe **Short answer: ** Change your Entitlement.plist configuration to Development Only entitlement configuration: com.apple.developer.driverkit.transport.pci IOPCIPrimaryMatch 0xFFFFFFFF&0x00000000 ...and I think you'll find that your build will suddenly work fine. Note that it's perfectly fine to use the configuration above for normal testing and development. The entitlement above does match all devices, but your IOKitPersonalities dictionary controls what you ACTUALLY match against, so having an broad entitlement doesn't mean you'll matc

Does Finder's I/O behavior trigger specific SCSI command sequences or timing issues that CLI tools do not? Sort of. The difference here isn't caused by any fundamental difference between the Finder and “CLI tools“ - at the level you're interacting with, they're both just processes doing reads and writes. Indeed, ironically, I believe we moved copying out of process a few releases ago, so as far as most of the system can tell, the actual copying is occurring from very similar components. What is different is that they’re almost certain to have different I/O patterns. On the CLI side, I'd cp is using copyfile() and as are many of our higher-level APIs (notably, I believe NSFileManager has converted to it). On the other hand, the Finder uses its own copy engine both because it's older and because the details of its behavior are different than most APIs (for example, it preflights copies and uses VNOP_COPYFILE for smb copies). The big thing I'd keep in mind here is that the reason you tend to see common I/O patte

Update: Refining the Architecture with LLMs (Gloss-to-Text) I've been refining the concept to make development faster and less data-dependent. Instead of trying to solve Continuous Sign Language Recognition purely through computer vision (which is extremely hard), we can split the workload. The Hybrid Pipeline Proposal: Vision Layer (ARKit): Focus strictly on Isolated Sign Recognition. The CoreML model only needs to identify individual signs (Glosses) based on the skeleton data. It treats gestures as Tokens. Input: Skeleton movement. Output: Raw tokens like [I], [WANT], [WATER], [PLEASE]. Logic Layer (LLM): We feed these raw tokens into an On-Device LLM (or API). Since LLMs excel at context and syntax, the model reconstructs the sentence based on the tokens. Input: [I] [WANT] [WATER] [PLEASE] Output: I would like some water, please. Why this is faster to build: We don't need a dataset of millions of complex sentences to train the Vision Model. We only need a dictionary of isolated signs. The grammar

I’m glad to hear you got this sorted out. Lemme tackle this last bit: [quote='867924022, fbartolom, /thread/808952?answerId=867924022#867924022, /profile/fbartolom'] I'm still in the blue about what embedding or not embedding does mean. [/quote] In the context of an iOS app [1]: Select Do Not Embed if you want to simply record a reference to the framework. This is primarily for system frameworks, like StoreKit, where the framework exists on the OS you’re targeting, and thus your app doesn’t need to carry along its own copy [2]. Select Embed & Sign if you want to embed the framework in your app and re-sign it as your code. This is most commonly used for frameworks that are part of a third-party SDK, where the code doesn’t exist on the target OS and thus your app needs to have its own copy. Select Embed if you want to embed the framework in your app. Folks typically use this with their own frameworks. For example, you might create a framework to hold some some code that’s common to your app and its app exte