A Summary of the WWDC25 Group Lab

Hi, thanks for your answer! Technically it works this way, but with a few drawbacks (button group displayed outside the sidebar and no animation when toggling the sidebar visibility). I'm doing the toggling like this: Button { self.columnVisibility = self.columnVisibility == NavigationSplitViewVisibility.detailOnly ? NavigationSplitViewVisibility.automatic : NavigationSplitViewVisibility.detailOnly } label: { Image(systemName: sidebar.left) } Is there any way to also enable the sliding animation it does when using the built-in toggle switch? Any other ideas how apple does it in their apps? Thanks! Jan

Hi, For native apps, Sign in with Apple uses the bundle ID as its client identifier (ID); for websites or apps on other platforms, the Services ID associated with the primary app ID is used instead. For an individual app, migrating to a Team ID App ID prefix will not cause any issues with your Sign in with Apple implementation. However, if you plan to use app groups for Sign in with Apple, you'll want to ensure that all child apps have the same App ID prefix as the primary app. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

So using the class constructor is pretty much the only reasonable way around this. I'm marking this reply as the correct answer. You can also avoid the crash by setting UIDesignRequiresCompatibility to YES in your Info.plist and use the pre Liquid Glass UI. maybe I'd file a bug but I don't think Apple responded to like 95% of my Catalyst bugs I reported in the past. I must have reported more than a dozen so I'm not going to be filing this one. FYI if you migrate to the group class constructor... if you have to do any per item tweaks you can apparently just dig in the subitems array right after you create the GroupItem (to set different actions on particular subitems etc.) HOPEFULLY they don't release an update that breaks that.

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