build disappears

Any chance you can take this code, put it in a small test project that reproduces the issue, and then attach that to your bug (FB21240977)? I tried grabbing the code snippet from your bug and putting it in my own test project, but that didn’t reproduce the problem. Given that, I’m not sure whether that’s because I’m not seeing the problem in my environment or whether I made a mistake when building my test project. If you can share a test project that reproduces the problem, that’ll eliminate that second possibility. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

This is tricky. My best guess is that translationTask(_:action:) is missing all the magic concurrency decorations required to make this work nicely. To get this to build right now you can mark the closure as sendable, like so: .translationTask(configuration) { @Sendable session in do { try await session.prepareTranslation() } catch { // Handle any errors. } } This compiles in Xcode 26.1 using the Swift 6 language mode and: Approachable Concurrency enabled Default Actor Isolation set to MainActor Note I’m using prepareTranslation() in my examples because it’s simpler, and that makes it easier to focus on the core issue. The drawback to this is that you can no longer access main-actor-isolated state from the closure. You can work around that using MainActor.run(…): try await session.prepareTranslation() … no isolation … await MainActor.run { … main-actor isolated … } Clearly this is less than ideal and I encourage you to file a bug against… actually, I think it’d be best to file a bug against the Trans

[quote='868260022, Infibrite, /thread/809012?answerId=868260022#868260022, /profile/Infibrite'] our earlier “Network Extension” tag was a mistake. [/quote] And presumably so was the reply you posted about 10 hours before this one |-: Anyway, the behaviour you’ve described doesn’t gel with Network Extension at all, so I’ve re-tagged your thread accordingly. When dealing with keychain sharing, there are two factors in play: Build time Run time I’m gonna focus on the build-time stuff, because a) that’s where you seem to be stuck, and b) I’m not familiar with Matter extensions and there could be run-time restrictions I’m not familiar with. So, regarding your build, you wrote: [quote='868260022, Infibrite, /thread/809012?answerId=868260022#868260022, /profile/Infibrite'] Could you enable Keychain Sharing for these iOS App IDs … ? [/quote] There’s nothing for us to enable here. Every App ID supports keychain sharing [1]. To illustrate this: I using Xcode 26.1 to create a new test project

[quote='809030021, pankaja, /thread/809030, /profile/pankaja'] This makes me believe something related to local network access … is not being applied correctly in the release/TestFlight environment. [/quote] That’s not impossible, but my experience is that it’s not common. Rather, most folks who see problems like this actually have a Release build issue. I recommend that you check this by following the process in Isolating Code Signing Problems from Build Problems. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Thank you, Quinn. Your suggestion about using app group IDs worked. After investigation, I found that adding my Team ID-prefixed app group (XXXXXXXXXX.com.mycompany.myapp) to com.apple.security.application-groups in my entitlements resolves both mach-register and mach-lookup without needing any temporary exceptions. Looking at /System/Library/Sandbox/Profiles/application.sb, I can see why this works: (sandbox-array-entitlement com.apple.security.application-groups (lambda (suite) ... (allow mach-lookup mach-register (global-name-prefix (string-append suite .))) ...)) With XXXXXXXXXX.com.mycompany.myapp as the app group, the sandbox allows any Mach service name starting with XXXXXXXXXX.com.mycompany.myapp., which matches Chromium's naming pattern: XXXXXXXXXX.com.mycompany.myapp.MachPortRendezvousServer.. My Developer ID provisioning profile already included XXXXXXXXXX.* in its application-groups, which authorizes any Team ID-prefixed app group. I just needed to explicitly claim it in my entitlements. For Elect

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