A Summary of the WWDC25 Group Lab

Hello, I'm back revisiting this and have some findings to report. When I tried to create a group as seen below let descriptor = NWMultiplexGroup(to: endpoint) guard let identity = networkingService.importIdentityFromPKCS12() else { print([browseResultsChangedHandler] could not import identity) continue } do { let parameters = try NWParameters(identity: identity) let group = NWConnectionGroup(with: descriptor, using: parameters) group.stateUpdateHandler = { _ in } group.newConnectionHandler = { _ in } group.start(queue: .global()) networkingService.addGroup(deviceID, group) } catch { } Note that endpoint comes from browser's browseResultsChangedHandler Identity comes from me importing a SecIdentity from the user's p12 Parameters has the identity in it so that QUIC works. My app crashes when it tries to create the group and I see the following error nw_group_descriptor_allows_endpoint Endpoint 1B1654DF-62B5-4B29-9495-C4965E8E99FF._captadoh._udp.local. is of invalid type for m

[quote='852386022, VBFSDEV, /thread/795578?answerId=852386022#852386022, /profile/VBFSDEV'] they will have access to all certificates, as you cannot grant selective certificate access. [/quote] I think you’re confused by the terminology here (an industry-wide problem, alas). It’s fine to give anyone access to a certificate. It only contains a public key. To sign code you need a digital identity, aka a code-signing identity, which is a certificate and the private key that matches the public key in that certificate. So, there’s no issue with your freelancer being able to access your Developer ID certificate [1]. What you have to protect is the matching private key. I discuss this terminological confusion in more detail in TN3161 Inside Code Signing: Certificates [quote='852386022, VBFSDEV, /thread/795578?answerId=852386022#852386022, /profile/VBFSDEV'] there is no solution to perform our signing process without granting the freelancer access to our app store connect account, correct? [/quote] It’s not that ther

Hi Quinn, Thank you so much for your guidance! I have followed your instructions and posted my question in the appropriate group here: Thread 796043 I appreciate your assistance and look forward to any further insights from the community. Best regards, Kedde

Here's a recap of the issue Summary of Current Setup So Far (for your documentation): Step Command Output / Result A gem install cocoapods -v 1.14.3 ✅ Installed successfully B which pod user/bob/.rbenv/shims/pod C pod --version 1.14.3 D gem install xcodeproj --pre ✅ Installed xcodeproj-1.27.0 CONCLUSION: This confirms: Xcode 16.3 writes .xcodeproj files with object version 90 The latest xcodeproj gem (1.27.0) only supports up to object version 77 Therefore, CocoaPods will crash every time with modern Xcode, no matter which version of cocoapods you use ✅ Clear Answer ❌ You cannot use CocoaPods right now unless: Xcodeproj is updated to support object version 90 → You’d have to wait for CocoaPods to release a compatible version Or you downgrade Xcode to something that supports .xcodeproj object version 77 → But this means downgrading to Xcode 15.x or lower, which won’t run on macOS 15.5 Sequoia → So you’re stuck.

Update The real problem was unrelated to the screenshot. The real issue was that the subscription group was missing localization. While the independent subscriptions indicated Missing Metadata, they were never missing metadata, and it was only the group.

You’re right to be careful about giving this freelancer full access to your Developer ID credentials. Those are precious, as I discuss in The Care and Feeding of Developer ID. IMO the easiest path forward is: Add your freelancer to your team as you would for iOS. They’ll be able do day-to-day development for your team, using an Apple Developer signing identity, just like they would on iOS. When they’re done, have them do a Product > Archive and send you the resulting .xcarchive. You can import that into your Xcode organiser. And do Developer ID distribution from there. This is a manual process but you can take various steps to automate it. Specifically: xcodebuild can do the equivalent of the Product > Archive in step 3. And it can also export from an archive, so you can automate the first part of step 5. Finally, notarytool lets you automate the second part of step 5. See Customizing the notarization workflow. The beginning of Creating distribution-signed code for macOS has a quick summary of

Thank you @illidan80. We found the underlying cause. The framework currently only supports adapters whose identifiers match the regex /fmadapter-w+-w+/. Here, your adapter name foundation-lab contains a hyphen, which tripped our name validation logic. If you update the adapter name in the toolkit to foundation_lab, that should resolve the issue. To test this quickly without re-exporting the adapter, you can manually edit the adapterIdentifier entry in the metadata.json file to fmadapter-foundation_lab-9799725. Thank you for reporting the issue and the follow-up debugging steps. We will use your feedback FB19237327 to track an improvement to the adapter training toolkit to perform this validation at adapter export time. Please don't hesitate to reach out again if you need more help with custom adapters!

App groups have been evolving a lot recently, primarily to bring the macOS and iOS stories into alignment. See App Groups: macOS vs iOS: Working Towards Harmony for all the backstory. Your app group ID, $(TeamIdentifierPrefix)group.com.example.testapp.mobile, is weird. It seems be a macOS-style ID, with the Team ID prefix, but then it also kinda uses the iOS-style format. I recommend that you use one or the other. Actually, I’ll take that one step further: I recommend that you you use an iOS-style app group ID unless you have a really good reason to stick with a macOS-style one [1]. As to what’s going on here, it’s hard to say. I tried looking up the state of com.example.testapp.mobile but AFAICT that’s not your real bundle ID, but rather a placeholder you used for this post. What version of Xcode are you using? If you’re using anything older than Xcode 16.4, I recommend that you upgrade to that. Xcode 16.4 is aware of this app group harmonisation effort. And once