A Summary of the WWDC25 Group Lab

Ya using +groupWithItemIdentifier:images:selectionMode:labels:target:action: avoids the crash. So under this API design am I permitted to do this? NSToolbarItemGroup *readStatusToolbarGroup = [NSToolbarItemGroup groupWithItemIdentifier:itemIdentifier images:@[mailOpenEnvelopeImage, mailBadgedEnvelopeImage] selectionMode:NSToolbarItemGroupSelectionModeSelectOne labels:@[@Read,@Unread] target:nil action:nil]; NSUInteger i = 0; for (NSToolbarItem *aItem in readStatusToolbarGroup.subitems) { if (i == 0) { aItem.action = @selector(markRead:); aItem.toolTip = @Tooltip for this one..; } else if (i == 1) { aItem.action = @selector(markUnread:); aItem.toolTip = @Tooltip for this one...; } i++; } This API design is not very good TBH. I'm not really happy about having to rewrite the code to build four toolbar groups (I already did this work). I'd like to move forward instead of running in place all the time. BTW the appearance of the toolbar groups don't look particularly special when created via the group

Hello @DTS Engineer, with following you can reproduce that, but I think I have found the issue in the meantime (see at the bottom): Setting up CoreData with 2 different Contexts. Setting viewContext property viewContext.automaticallyMergesChangesFromParent = true. Setting some Merge Policy for both contexts (as long as error is not used). Setting up some Singleton or something else which registers to the ObjectsDidChange Notification of CoreData. Using there some property of the Managed Objects. Date Property seems to results in Crashes, primitive properties not. Creating Unit Tests which provacate a Merge Conflict. Merge Conflict should be created on the second context. So changing something on viewContext, then on the second context fetching the same object and doing some changes. Save viewContext and then save the second context. For the tearDown I have cleared up the contexts (context.reset(), context.refreshAllObjects()). Then doing some other Unit Tests which rans after and then the Notification appeare

It appears to be correctly signed. Automatically manage signing is checked, my standard team is set. With those settings, as soon as I assign an app group in Xcode 26.1, it changes to an Xcode managed provisioning profile and my valid Apple Development certificate and does not let me change them. I also checked the build with codesign -dv --verbose=4 and in ~/Library/Developer/Xcode/UserData/Provisioning Profiles to verify and that the profiles update, e.g., when I change the Info.plist. I also tried setting up a fresh sample project from the standard multiplatform SwiftUI app template in Xcode and did not change anything in Signing & Capabilities except setting the app group for the app and download extension. Same minimal app just calling AssetPackManager.shared.assetPack(withID:), same result: on iOS it works, on macOS the URL override is not permitted.

Hello @sadaotokuyama, thank you for your question! I think there's some confusion over what is required to show immersive video so hopefully I can clarify in this post. Based on the description of what you want to do, I recommend searching for the term APMP or Apple Projected Media Profile. Check out the video Learn about the Apple Projected Media Profile from WWDC25 for more information. Specifically, there is a graphic shown at about 1 minute and 20 seconds that shows all the different formats side by side. For additional resources check out Explore video experiences for visionOS which goes into all the different ways of presenting media on Vision Pro, and also Support immersive video playback in visionOS apps. Apple Immersive Video is a high-end immersive video format on Vision Pro. To shoot content for this format you'll need a piece of equipment like Blackmagic's URSA Cine Immersive camera. However, APMP video is much more accessible, and can be shot on a wider variety of cameras, because APMP i

Have you asked Gemini or ChatGPT about this case? When it comes to Swift Concurrency, they are quite good at it. Concerning your issue, Gemini reports to me several issues with the following last comment. In summary, the most critical issue is the unreliable view hierarchy traversal using view.superview?.superview. You should refactor the ViewExtractor to reliably pass the host UIView back to the modifier.