A Summary of the WWDC25 Group Lab

Hello @Jir_253, Thanks for your questions. I’d recommend that you start by watching Set the scene with SwiftUI in visionOS from this year’s WWDC. Your “CWindow” sounds similar to the Tools window covered in this talk: WindowGroup(Tools, id: tools) { ToolsView() } .restorationBehavior(.disabled) .defaultLaunchBehavior(.suppressed) Similar to iOS where you cannot quit the application yourself, you cannot dismiss the last window of your application. When a user goes to close the main window when the secondary window is open, you cannot close this secondary window if it’s the only window group that is open in your application. Consider adding an affordance to the secondary window to reopen the main window in this case. There's no supported way for you to create parent/child window relationships with the APIs currently available. If you'd like us to consider adding the necessary functionality, please file an enhancement request using Feedback Assistant. Once you file the request, please post the FB number

Is this change in modal presentation documented anywhere? I can't seem to find anything on it in the Apple Dev Documentation or from WWDC25. We don't document the implementation details, but the design change was mentioned in this video. (It is a SwiftUI video, but the design change applies to UIKit.) Best, —— Ziqiao Chen  Worldwide Developer Relations.

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!