build disappears

Hi, Thanks for following up. Platform: iOS (tested on iOS 17.x and iOS 18 betas). Extension type: Apple MatterSupport “Matter Add Device Extension” (Accessory Setup extension). We’re not building a Network Extension provider—our earlier “Network Extension” tag was a mistake. Our setup is a standard iOS app (com.infibrite…) plus the Matter setup extension (com.infibrite…MatterSetupExtension). Both targets need to share Matter fabric credentials via a single keychain access group (com.infibrite.matter.shared) so the extension can commission devices while the main app reuses the stored fabric. App Groups and other capabilities enable correctly, but the “Keychain Sharing” toggle never appears for either App ID in the portal. Because the provisioning profiles can’t include that entitlement, the OS returns errSecMissingEntitlement whenever we reference kSecAttrAccessGroup, so the extension can’t read the credentials. Could you enable Keychain Sharing for these iOS App IDs (main app + Matter setup extension

Totally understand, it was likely more emotional than a functional. Though I was looking for insight and suggestions - to be clear I'm on a dev build 26.2 beta 3 but the bugs on this build makes it impossible to work with. I can't manage the space to make the device work -constantly wiping and restoring doesn't work - outcome remains the same. I wanted to flag it because if this build goes live - its going to be a problem. As there is something corrupt in the process.

@DTS Engineer - Here is how I build an outbound connection: private func handleOutboundConnection(to endpoint: NWEndpoint, deviceID: DeviceID) { do { guard let identity = Utils.importIdentityFromPKCS12() else { logger.error([networkBrowser] could not import identity) return } guard let certificateData = Utils.getCertificateData(from: identity) else { logger.error([networkBrowser] could not read certificate data) return } let builder = try makeQUICParametersBuilder(identity: identity, certificateData: certificateData) let connection = NetworkConnection(to: endpoint, using: builder) let connectionID = ConnectionID(connection) // connectionIDToConnection[connectionID] = connection // associateConnection(connectionID, with: deviceID) print(handleOutboundConnection: connection added) setupConnectionStateTask(for: connection, connectionID: connectionID, origin: .browser, deviceID: deviceID) setupConnectionReceiveTask(for: connection, connectionID: connectionID) } catch { print(could not create NetworkConne

[quote='868011022, chrismuench, /thread/769472?answerId=868011022#868011022, /profile/chrismuench'] it is clearly still a bug in Xcode 26 [/quote] Absolutely. There’s no argument about that. [quote='868011022, chrismuench, /thread/769472?answerId=868011022#868011022, /profile/chrismuench'] which leads to deployment failure from my Visual Studio on my PC. [/quote] With Xcode, you don’t need to explicitly install the profile because the system picks it up from the embedded.mobileprovision file embedded within the built app. I don’t know enough about how Visual Studio builds and installs apps to offer any insight into why that’s not working for it. My advice is that you escalate this via the support channel for that tooling. ps It’s better to reply as a reply, rather than in the comments; see Quinn’s Top Ten DevForums Tips for this and other titbits. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

What platform are you on? And what type of app extensions are you building? This matters because: You tagged your thread with Network Extension, which suggests you’re building an NE provider. On macOS, the keychain is weird. See TN3137 On Mac keychain APIs and implementations. And NE providers can be packaged as either an appex or a sysex. See TN3134 Network Extension provider deployment. And that affects how you should interact with the keychain. See Network Extension Provider Packaging. So, if you’re on iOS or one of its child platforms, we can focus on the appex side of this. OTOH, if you’re on macOS, things get more complex |-: Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

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