Mac Catalyst Crash on App Launch on macOS 26.1: Assertion failure in -[NSToolbarItemGroupView _layoutWrapperViewsWithAttributes:], NSToolbarItemGroupView.m:599

Returning to a Mac Catalyst app that I put to the side for awhile..when running it on Xcode 26.1 it crashes at launch with:

Assertion failure in -[NSToolbarItemGroupView _layoutWrapperViewsWithAttributes:], NSToolbarItemGroupView.m:599

No attributes were found for item

Call stack has a bunch of Autolayout code in AppKit like:

[NSWindow(NSConstraintBasedLayoutInternal) _layoutViewTree] + 120 50 AppKit 0x00000001911e8a10 -[NSWindow(NSConstraintBasedLayoutInternal) layoutIfNeeded] + 240 51 UIKitMacHelper 0x00000001a98f293c -[UINSWindow layoutIfNeeded] + 56

A few unnamed symbols mixed in maybe that's that Swiftness beneath the surface. App is just murdered on launch. I assume this is related to using NSToolbarItemGroup when building an NSToolbar...

I do see this log out:

NSToolbarItemGroup does not support selectionMode. Create the group with one of the class constructors to support selection.

Which is an interesting log so I commented out all calls to setSelectionMode: but still the same crash.

I do set the groups subitems property directly (I do not use the class constructors as the logging statement above indicates). I have no idea if using the class constructors will workaround this issue or not but I'm not particularly excited about that idea because I have items in the same toolbar group with different actions.

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 class constructor so I dk what's with all the system appearance talk. It isn't clear to me why the underlying implementation can't build the toolbar properly in the same way from -setSubItems:

These toolbar items just get images and titles I'm not even using a custom view for the toolbar item.

Also I lose the ability to set the itemIdentifier property on subitems when creating the NSToolbarItemGroup with the class constructor.

Presumably the subitem is still the sender when NSToolbarItem invokes its action? Being able to define itemIdentifier on subitem can sometimes be useful.

I guess I can use tag instead but feels like a lot of busy work here. Err

This API is broken in AppKit land as well. Also experienced another exception when rerunning the app... the system throws up an alert like:

"App crashed while reopening windows - Do you want to reopen windows again" error. If you choose to reopen windows in the alert we get another exception:

** Assertion failure in -[UINSAppKitTerminationController launchingDidComplete], UINSAppKitTerminationController.m:71

Accepted Answer

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.

Mac Catalyst Crash on App Launch on macOS 26.1: Assertion failure in -[NSToolbarItemGroupView _layoutWrapperViewsWithAttributes:], NSToolbarItemGroupView.m:599
 
 
Q