So I noticed this: A sheet window is presented. The sheet window has some UI that makes it expandable say a little arrow expandable button. Click the little expandable button. Now the sheet window controller calls - (void)setFrame:display:animate: on its window to resize. The parent window flies across the screen to the lower left corner. I'm on Tahoe 26.1. Seems to be related to NSSheetMoveHelper. Not sure how long this bug has been around. Workaround is to call -setFrame:display:animate: and pass NO to the animate flag. Then the sheet window resizes (but not animated which doesn't look as good as the old behavior but better than suddenly disappearing). I think Apple may already knows about this bug b/c in an Apple app on Tahoe I see a sheet resizing being done with no animation...

Hi there! We have an application that exists for more than 10 years (Appkit, Obj-C), and since the very beginning we're using CMD+ESC as a keyboard shortcut for a very important function in our app. Until now, this worked great. Recently, when macOS 26.1 released our app started to not responding to CMD+ESC anymore for some of our customers - it seems like CMD+ESC never gets to our app at all. First, we though it's happening because Game Overlay is also using CMD+ESC by default, but when we turned that off, or switched that to something else in macOS's Keyboard preferences, the issue still persisted. The, we realized this has something to do with iCloud - so, if you turn off iCloud, do a log out and log in to your computer, and it's magically starts working again, as it always did. More strangely, this issue doesn't happen for everyone - for many of our customers, the issue seems to doesn't exist for some strange reason. Anyone have any idea what could be happening here?

Dear Forum, after decades, I'm back to MacOS dev just for the need of it. Besides Mac, I'm also toying around with vintage IBM mainframe systems and therefore I'm in need for a good terminal emulation. So far, I use x3270 on my Apple Silicon M1 MacBook Air - nice. However, I can't compile it on my collection of vintage Macs (iMac G3, Cube G4) so I pondered to create it on my own using Cocoa (starting with MacOS X 10.4 Tiger up to the current level (on Sequoia) so that rules out Carbon. tn3270 X from Brown University works nice on those vintage Macs but misses some features. Having browsed some info about the Cocoa Text system, I wonder if that would be the right place to start. At the end of the day, I need to be able to intercept all keystrokes, have more or less a fixed font 80x25 (136x25 etc..) col/row layout of protected and unprotected areas where text can be entered. Cusor should be visible and movable by using cursor control keys. I'd be happy for any suggestion on where to start here. Kind regards Michael

Hi all, when I launch my macOS app from Xcode 16 on ARM64, appKit logs me this error on the debug console: It's not legal to call -layoutSubtreeIfNeeded on a view which is already being laid out. If you are implementing the view's -layout method, you can call -[super layout] instead. Break on _NSDetectedLayoutRecursion(void) to debug. This will be logged only once. This may break in the future. _NSDetectedLayoutRecursion doesn't help a lot, giving me these assembly codes from a call to a subclassed window method that looks like this: -(void) setFrame:(NSRect)frameRect display:(BOOL)flag { if (!_frameLocked) [super setFrame:frameRect display:flag]; } I have no direct call to -layoutSubtreeIfNeeded from a -layout implementation in my codes. I have a few calls to this method from update methods, however even if I comment all of them, the error is still logged... Finally, apart from that log, I cannot observe any layout error when running the program. So I wonder if this error can be safely ignored? Thanks!

Is anyone else getting new warning about menu items with submenus when running on Tahoe? I'm getting big performance problems using my menu as well as seeing these messages and I'm wondering if there's a connection. My app is faceless with a NSStatusItem with an NSMenu. Specifically it's my own subclass of NSMenu where I have a lot of code to manage the menu's dynamic behavior. This code is directly in the menu subclass instead of in a controller because the app I forked had it this way, a little wacky but I don't see it being a problem. A nib defines the contents of the menu, and it's instantiated manually with code like: var nibObjects: NSArray? = [] guard let nib = NSNib(nibNamed: "AppMenu", bundle: nil) else { ... } guard nib.instantiate(withOwner: owner, topLevelObjects: &nibObjects) else { ... } guard let menu = nibObjects?.compactMap({ $0 as? Self }).first else { ... } Within that nib.instantiate call I see a warning logged that seems new to Tahoe, before the menu's awakeFromNib is called, that says (edited): Internal inconsistency in menus - menu <NSMenu: 0x6000034e5340> believes it has <My_StatusItem_App.AppMenu: 0x7f9570c1a440> as a supermenu, but the supermenu does not seem to have any item with that submenu My_StatusItem_App.AppMenu: 0x7f9570c1a440 is my menu belonging to the NSStatusItem, NSMenu: 0x6000034e5340 is the submenu of one of its menu items. At a breakpoint in the NSMenu subclass's awakeFromNib I print self and see clear evidence of the warning's incorrectness. Below is a snippet of the console including the full warning, only edited for clarity and brevity. It shows on line 32 menu item with placeholder title "prototype batch item" that indeed has that submenu. Internal inconsistency in menus - menu <NSMenu: 0x6000034e5340> Title: Supermenu: 0x7f9570c1a440 (My StatusItem App), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( "<NSMenuItem: 0x6000010e4fa0 Do The Thing Again, ke mask='<none>'>", "<NSMenuItem: 0x6000010e5040 Customize\U2026, ke mask='<none>'>", "<NSMenuItem: 0x6000010e50e0, ke mask='<none>'>" ) believes it has <My_StatusItem_App.AppMenu: 0x7f9570c1a440> Title: My StatusItem App Supermenu: 0x0 (None), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( ) as a supermenu, but the supermenu does not seem to have any item with that submenu (lldb) po self <My_StatusItem_App.AppMenu: 0x7f9570c1a440> Title: My StatusItem App Supermenu: 0x0 (None), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( "<NSMenuItem: 0x6000010fd7c0 About My StatusItem App\U2026, ke mask='<none>', action: showAbout:, action image: info.circle>", "<NSMenuItem: 0x6000010fd860 Show Onboarding Window\U2026, ke mask='Shift', action: showIntro:>", "<NSMenuItem: 0x6000010fd900 Update Available\U2026, ke mask='<none>', action: installUpdate:, standard image: icloud.and.arrow.down, hidden>", "<NSMenuItem: 0x6000010e46e0, ke mask='<none>'>", "<NSMenuItem: 0x6000010e4780 Start The Thing, ke mask='<none>', action: startTheThing:>", "<NSMenuItem: 0x6000010e4dc0 \U2318-\U232b key detector item, ke mask='<none>', view: <My_StatusItem_App.KeyDetectorView: 0x7f9570c1a010>>", "<NSMenuItem: 0x6000010e4e60, ke mask='<none>'>", "<NSMenuItem: 0x6000010e4f00 saved batches heading item, ke mask='<none>', view: <NSView: 0x7f9570b4be10>, hidden>", "<My_StatusItem_App.BatchMenuItem: 0x6000016e02c0 prototype batch item, ke mask='<none>', action: replaySavedBatch:, submenu: 0x6000034e5340 ()>", "<NSMenuItem: 0x6000010f7d40, ke mask='<none>'>", "<My_StatusItem_App.ClipMenuItem: 0x7f956ef14fd0 prototype copy clip item, ke mask='<none>', action: copyClip:>", "<NSMenuItem: 0x6000010fa620 Settings\U2026, ke='Command-,', action: showSettings:>", "<NSMenuItem: 0x6000010fa6c0, ke mask='<none>'>", "<NSMenuItem: 0x6000010fa760 Quit My StatusItem App, ke='Command-Q', action: quit:>" ) Is this seemingly incorrect inconsistency message harmless? Am I only grasping at straws to think it has some connection to the performance issues with this menu?

Appkit starting logging these warnings in macOS 26.1 about my app's MainMenu. **Internal inconsistency in menus - menu <NSMenu: 0xb91b2ff80> Title: AppName Supermenu: 0xb91a50b40 (Main Menu), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: () believes it has [<NSMenuSubclassHereThisIsTheMenuBarMenuForMyApp:] 0xb91a50b40> Title: Main Menu Supermenu: 0x0 (None), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( ) as a supermenu, but the supermenu does not seem to have any item with that submenu ** I don't what that means. The supermenu is the menu that represents the menu used for my app's menu bar (as described by NSMenuSubclassHereThisIsTheMenuBarMenuForMyApp Everything seems to work fine but log looks scary. Please don't throw!

In macOS 13.2, the NSTrackingEnabledDuringMouseDrag flag for NSTrackingArea is broken, i.e., mouse-entered and mouse-exited events are not sent during a drag. This problem did not exist in macOS 12. I've filed a bug report, FB11973492, just wondering if anyone knows a workaround.

Hello. In my app, I use RegisterEventHotkey to implement global keyboard shortcuts to trigger actions. Up until macOS Sequoia, I was able to use a keyboard shortcut with option and shift as the modifiers, like option shift 2 (⌥ ⇧ 2). Now, on macOS Sequoia, using RegisterEventHotkey to register a hotkey with those exact modifiers (option and shift), regardless of the key, fails with the error -9868 (eventInternalErr). Is this a documented and wanted change, or is this a bug? Other modifier keys (just command, command option, command shift, command control, control shift, etc), all work. Any insight into this would be appreciated. (Feedback filed: FB15163561) Thank you, Matthias

On Tahoe NSTextField (and NSTextFieldCell) appears to ignore backgroundColor, drawsBackground, isBezeled, bezelStyle and isBordered properties. Those worked on prior macOS, but not Tahoe. Is there a way to make those properties effective while targeting Tahoe? Note: a slight erratum: backgroundColor has an effect while the text field has first responder status, but the background area is an inset rectangle and I suspect that is a remnant feature and not by design.

Previously I was able to "snapshot" view that were not part of any window hierarchy using the following: NSImage *buttonImage = [NSImage imageWithSystemSymbolName:@"49.circle.fill" accessibilityDescription:nil]; NSButton *aButton = [NSButton buttonWithImage:buttonImage target:nil action:nil]; [aButton sizeToFit]; NSBitmapImageRep *rep = [aButton bitmapImageRepForCachingDisplayInRect:aButton.bounds]; if (rep == nil) { NSLog(@"Failed to get bitmap image rep."); return; } [aButton cacheDisplayInRect:aButton.bounds toBitmapImageRep:rep]; NSData *tiffData = rep.TIFFRepresentation; NSImage *snapShotOfImage = [[NSImage alloc]initWithData:tiffData]; Now on macOS Tahoe I get a non nil image, but the image is blank. However if I add aButton NSWindow's view hiearchy just before the call to -cacheDisplayInRect:toBitmapImageRep: I do get a proper image. Is this behavior intended or is this considered a bug? Is it documented anywhere that a view must be in a NSWindow for -cacheDisplayInRect:toBitmapImageRep: to work? Thanks

My app (FindAnyFile) provides a Finder-like interface in which it also offers a QuickLook preview command, which invokes [[QLPreviewPanel sharedPreviewPanel] makeKeyAndOrderFront:nil]; Now, if it shows .abcdp files, it often, but not always, crashes. This has been happening for many macOS versions, at least since 10.15, up to 26.1. Also, it does not seem to matter which SDK/Xcode I build with, as I used several and all versions lead to the crash. The issue rather appears to be inside the QLplugin for the AB file (ABCardCollectionView etc.). I am able to trace this crash in Xcode. There are a LOT of errors and warnings coming up, and eventually the qlplugin throws an ObjC exception which in turn brings down my entire app (and here I thought that the XPC system was designed to expressly avoid such crashes). Possibly significant errors are: CNAccountCollectionUpdateWatcher 0x6000025cf800: Update event received, but store registration failed. This event will be handled, but the behavior is undefined. Error using remote object proxy when fetchAnonymousXPCEndpoint: Error Domain=NSCocoaErrorDomain Code=4097 "connection to service named com.apple.telephonyutilities.callservicesdaemon.callstatecontroller" UserInfo={NSDebugDescription=connection to service named com.apple.telephonyutilities.callservicesdaemon.callstatecontroller} connection to service named com.apple.coreduetd.people … CNPropertyNotFetchedException: A property was not requested when contact was fetched. I've attached the (mostly) complete console output from such a debug run. I have also an open bug report regarding this kind of crash (back then I was not able to reproduce it myself): FB15553847 Also, when I "Quick Look" the same file in Finder, I get a "Preview not permitted" for the same items that crash in my app. If I copy the same items to the Desktop, then Finder can QL them and my app doesn't crash when viewing the item on the Desktop. So, the crash only happens with the items inside ~/Library/Application Support/AddressBook/Sources/…/Metadata/. Now, here is the weirdest part: You might think: So, if the Finder shows "Preview not permitted", then my app trying to view those items is the result of that condition (even if that's not supposed to crash). However: I have a clean 26.1 install (in an Apple ARM VM) where Finder also says "Preview not permitted" for these items in the user's Library/AB/Metadata folder, but my app can QL those items without crashing! Also, I have one user who uses 26.1 and gets the crash with files in the same location. So, the "Preview not permitted" is probably not the cause of this crash, though it's suspicious that a user gets this at all - why can't a user QL the abcdp files in the Metadata folder but when copied to the Desktop, QL works? You'd think that Finder has the necessary entitlements to access the AB, or doesn't it? Of course, my app has permission enabled under Privacy & Security / Contacts (if it's disabled, then the app can't show anything but will also not crash). And it has the "Address Book" entitlement. Would be nice if this could be looked into and eventually be fixed. Alternatively, I'd welcome any suggestions on how to prevent my app from crashing if the qlplugin throws. But if you look at the stack trace you'll see that there's no method of my own app involved where I could insert an exception catcher. I added code to my previewItemURL delegate method to make sure the NSURL item is readable, and it is, even Of course, apart from the issue with .abcdp files, the QL operation in my app works flawlessly, i.e. I have never received any other crash reports relating to any other QL plugins. QuickLook for AddressBook crash messages

I want to check whether a sandboxed application already has access permission to a specific URL. Based on my investigation, the following FileManager method seems to be able to determine it: FileManager.default.isReadableFile(atPath: fileURL.path) However, the method name and description don't explicitly mention this use case, so I'm not confident there aren't any oversights. Also, since this method takes a String path rather than a URL, I'd like to know if there's a more modern API available. I want to use this information to decide whether to prompt the user about the Sandbox restriction in my AppKit-based app.

I'm reading a bit outdated book about Cocoa/Objective-C applications development and I'm trying to code some examples. And so I ended up with an almost empty NSDocument-based app with runtime errors like that: Internal inconsistency in menus - menu <NSMenu: 0xbc726d040> Title: Window Supermenu: 0xbc726d080 (Main Menu), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( "<NSMenuItem: 0xbc6fcd9a0 Minimize, ke='Command-M'>", "<NSMenuItem: 0xbc6fcda40 Zoom, ke mask=''>", "<NSMenuItem: 0xbc6fcdae0, separator, ke mask=''>", "<NSMenuItem: 0xbc6fcd900 Bring All to Front, ke mask=''>" ) believes it has <NSMenu: 0xbc726d080> Title: Main Menu Supermenu: 0x0 (None), autoenable: YES Previous menu: 0x0 (None) Next menu: 0x0 (None) Items: ( ) as a supermenu, but the supermenu does not seem to have any item with that submenu It looks like as if the menu tries to include itself as a submenu. Am I right? I have no ideas what led to this. If I'm not mistaken this has started since macOS Tahoe. The code that is not a boilerplate one I have: // Document.m #import "Document.h" @implementation Document @synthesize text; - (NSString *)windowNibName { return @"SampleDocument"; } - (void)windowControllerDidLoadNib:(NSWindowController *)aController { [super windowControllerDidLoadNib:aController]; if (self.text == nil) { self.text = @""; } self.textField.stringValue = self.text; } - (NSData *)dataOfType:(NSString *)typeName error:(NSError **)outError { self.text = self.textField.stringValue; return [self.text dataUsingEncoding:NSUTF8StringEncoding]; } - (BOOL)readFromData:(NSData *)data ofType:(NSString *)typeName error:(NSError **)outError { if ([data length] > 0) { NSString * string = [[NSString alloc] initWithData:data encoding:NSUTF8StringEncoding]; self.text = string; } else { self.text = @""; } return YES; } + (BOOL)autosavesInPlace { return YES; } @end There are two xib's: MainMenu.xib and Document.xib but I won't include them here. Please advise how to fix this menu issue.

My app has the following UI layout: NSSplitViewController as the windows contentViewController NSPageController in the content (right) split item NSTabViewController as the root items of the NSPageController NSViewController with a collection view in the first tab of that NSTabViewController The collection view is using a NSCollectionViewCompositionalLayout in which the sections are set up to have a header using NSCollectionLayoutBoundarySupplementaryItem with pinToVisibleBounds=true and alignment=top With macOS 26, the pinned supplementary item automatically gets a blurred/semi-transparent background that seamlessly integrates with the toolbar. When the window's title bar has a NSTitlebarAccessoryViewController added, the said semi-transparent background gets a bottom hard edge and a hairline to provide more visual separation from the main content. During runtime, my NSPageController transitions from the NSTabViewController to another view controller. When transitioning back, the semi-transparent blur bleeds into the entire section. This happens no matter if there's a NSTitlebarAccessoryViewController added or not. It doesn't happen 100% of the cases, it seems to depend on section size, header visibility and/or scroll position. But it happens more often than not. Most of the time, a second or so after the back transition - shortly after pageControllerDidEndLiveTransition: of the NSPageControllerDelegate is called - the view updates and the supplementary views are back to normal. Sometimes, the issue also appears not when transitioning using NSPageController, but simply by scrolling through the collection view. Anyone has an idea what is happening here? Below are two screenshots of both the "ok" and "not ok" state I'm on macOS 26.0.1 and I'm using XCode 26.0.1

I have Mac apps that embed “Helper Apps” inside their main bundle. The helper apps do work on behalf of the main application. The helper app doesn’t show a dock icon, it does show minimal UI like an open panel in certain situations (part of NSService implementation). And it does make use of the NSApplication lifecycle and auto quits after it completes all work. Currently the helper app is inside the main app bundle at: /Contents/Applications/HelperApp.app Prior to Tahoe these were never displayed to user in LaunchPad but now the Spotlight based AppLauncher displays them. What’s the recommended way to get these out of the Spotlight App list on macOS Tahoe? Thanks in advance.

When scrolling a basic NSScrollView there seems to be a sudden jump after each flick. Scrolling does not appear smooth and is disorientating. A scroll jump seems to happen directly after letting go of a scroll flick using a trackpad/mouse. Right at that moment the scroll turns into a momentum scroll, slowly decreasing the speed. But the first frame after the gesture the content jumps forward, more than what is expected. Observations: Counterintuitively, scrolling appears to be smoother when disabling NSScrollView.isCompatibleWithResponsiveScrolling. If disabled using a custom NSScrollView subclass there is no large jump anymore. Scrolling also appears to be smoother using a SwiftUI ScrollView. I assume that has the same behaviour as a disabled isCompatibleWithResponsiveScrolling Ironically a WKWebView scrolls much smoother. No sudden jump is observable. It also seems to scroll with faster acceleration, but the individual frames do appear smoother. Why is this better than a native NSScrollView? Elastic scrolling at the bounds of the scroll view also appears much smoother for WKWebViews. When pulling to refresh there is a jump for NSScrollView/SwiftUI, but not for WKWebView. When using an NSScrollView with isCompatibleWithResponsiveScrolling disabled, scrolling appears just as smooth as WKWebView on macOS 13 Ventura and below. On macOS 14 Sonoma scrolling behaviour is suddenly different. Please see a sample project with 4 different scroll views side by side: https://github.com/floorish/ScrollTest Screen recordings show the sudden jumps when scrolling and when elastic scrolling. Tested on Intel & Arm Macs, macOS 11 Big Sur through 15 Sequoia, built with Xcode 16. Should isCompatibleWithResponsiveScrolling be disabled on Sonoma+? Are there any drawbacks? There is also no overdraw anymore since Monterey, as described in https://developer.apple.com/library/archive/releasenotes/AppKit/RN-AppKitOlderNotes/#10_9Scrolling Even with responsive scrolling disabled, why is WKWebView scrolling much smoother than NSScrollView?

When I compiled my legacy project with Tahoe's macOS 26 SDK, NSRulerViews are showing a very different design: Under prior macOS versions the horizontal and verrical ruler's background were blurring the content view, which was extending under the rulers, showing through their transparency. With Tahoe the horizontal ruler is always reflecting the scrollview's background color, showing the blurred content view beneath. And the vertical ruler is always completely transparent (without any blurring), showing the content together with the ruler's markers and ticks. It's difficult to describe, I'll try to replicate this behavior with a minimal test project, and probably file a bug report / enhancement request. But before I take next steps, can anyone confirm this observation? Maybe it is an intentional design decision by Apple?

I have a fairly robust MacOS application that has an NSScrollView that contains a canvas with various subviews (including web views and text views that contain scroll views), and a couple of peer views that track items in the scroll view (eg: screen space controls). Some of these views interrupt two finger scrolling. Every scroll view, and one of the peer views (essentially a stack view with buttons in it). I have written an additional bare bones application which does roughly the same thing, and my bare bones application works perfectly: Start two-finger dragging, scroll any of these other things under the cursor, I can continue to drag (and start dragging in any of those, and they drag without interfering with the parent scroll view). I have tried everything to recreate the interruption, including drag gestures attached to these various ancillary views, and I cannot figure out why dragging some of these views under the cursor interrupts two finger drag in our application, but not in my testbed. Does anyone have suggestions for how to debug this? I can see that there is a gesture recognizer in the NSScrollView hierarchy, but I don't see it in any of my gesture recognizer handling. I have breakpoints on every variation of hit testing and mouse motion, and none of them are getting hit in unexpected ways. I'm at my wit's end. Thanks.

the app crashes about 10 seconds after it goes into the background libsystem_kernel.dylib semaphore_wait_trap 100% 45 dyld start + 7116 [0x1825fa000] 100% 44 xxxx main + 76 (main.m:38) [0x104c14000] 100% 43 UIKitCore UIApplicationMain + 336 [0x18ae57000] 100% 42 UIKitCore -[UIApplication _run] + 792 [0x18ae57000] 100% 41 GraphicsServices GSEventRunModal + 120 [0x224975000] 100% 40 CoreFoundation _CFRunLoopRunSpecificWithOptions + 532 [0x185569000] 100% 39 CoreFoundation __CFRunLoopRun + 820 [0x185569000] 100% 38 CoreFoundation __CFRunLoopDoSources0 + 232 [0x185569000] 100% 37 CoreFoundation __CFRunLoopDoSource0 + 172 [0x185569000] 100% 36 CoreFoundation __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 [0x185569000] 100% 35 BoardServices BSServiceMainRunLoopSourceHandler + 224 [0x19c8b0000] 100% 34 BoardServices __BSSERVICEMAINRUNLOOPQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 52 [0x19c8b0000] 100% 33 libdispatch.dylib _dispatch_block_invoke_direct + 284 [0x1bcf40000] 100% 32 libdispatch.dylib _dispatch_client_callout + 16 [0x1bcf40000] 100% 31 FrontBoardServices -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 168 [0x1a4d45000] 100% 30 FrontBoardServices __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2 + 96 [0x1a4d45000] 100% 29 FrontBoardServices __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2.cold.1 + 352 [0x1a4d45000] 100% 28 FrontBoardServices -[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:] + 708 [0x1a4d45000] 100% 27 FrontBoardServices -[FBSScene _callOutQueue_maybeCoalesceClientSettingsUpdates:] + 128 [0x1a4d45000] 100% 26 FrontBoardServices __76-[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:]_block_invoke.129 + 380 [0x1a4d45000] 100% 25 UIKitCore -[UIApplicationSceneClientAgent scene:handleEvent:withCompletion:] + 336 [0x18ae57000] 100% 24 UIKitCore -[UIScene scene:didUpdateWithDiff:transitionContext:completion:] + 244 [0x18ae57000] 100% 23 UIKitCore -[UIScene _emitSceneSettingsUpdateResponseForCompletion:afterSceneUpdateWork:] + 208 [0x18ae57000] 100% 22 UIKitCore __64-[UIScene scene:didUpdateWithDiff:transitionContext:completion:]_block_invoke.218 + 616 [0x18ae57000] 100% 21 UIKitCore -[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:] + 316 [0x18ae57000] 100% 20 UIKitCore _UISceneSettingsDiffActionPerformChangesWithTransitionContextAndCompletion + 224 [0x18ae57000] 100% 19 UIKitCore +[BSAnimationSettings(UIKit) tryAnimatingWithSettings:fromCurrentState:actions:completion:] + 736 [0x18ae57000] 100% 18 UIKitCore __186-[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:]_block_invoke + 148 [0x18ae57000] 100% 17 UIKitCore -[_UISceneLifecycleMultiplexer uiScene:transitionedFromState:withTransitionContext:] + 244 [0x18ae57000] 100% 16 UIKitCore -[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:] + 608 [0x18ae57000] 100% 15 UIKitCore -[_UISceneLifecycleMultiplexer _performBlock:withApplicationOfDeactivationReasons:fromReasons:] + 212 [0x18ae57000] 100% 14 UIKitCore __101-[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:]_block_invoke + 252 [0x18ae57000] 100% 13 UIKitCore _UIScenePerformActionsWithLifecycleActionMask + 112 [0x18ae57000] 100% 12 UIKitCore __101-[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:]_block_invoke_2 + 512 [0x18ae57000] 100% 11 UIKitCore -[UIApplication _applicationDidEnterBackground] + 136 [0x18ae57000] 100% 10 UIKitCore +[UIViewController _performWithoutDeferringTransitionsAllowingAnimation:actions:] + 140 [0x18ae57000] 100% 9 UIKitCore __47-[UIApplication _applicationDidEnterBackground]_block_invoke + 256 [0x18ae57000] 100% 8 Foundation -[NSNotificationCenter postNotificationName:object:userInfo:] + 92 [0x182c3d000] 100% 7 CoreFoundation _CFXNotificationPost + 736 [0x185569000] 100% 6 CoreFoundation _CFXRegistrationPost + 436 [0x185569000] 100% 5 CoreFoundation ___CFXRegistrationPost_block_invoke + 92 [0x185569000] 100% 4 CoreFoundation __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 [0x185569000] 100% 3 CoreBluetooth -[CBXpcConnection _sendBarrier] + 188 [0x1c2254000] 100% 2 libdispatch.dylib _dispatch_semaphore_wait_slow + 132 [0x1bcf40000] 100% 1 libdispatch.dylib _dispatch_sema4_wait + 28 [0x1bcf40000] 100% 0 libsystem_kernel.dylib semaphore_wait_trap + 8 [0x22d5b6000]

In my AppKit app I have a an outline view where each cell has a title (NSTextField), image view (NSImageView), and 4 NSButtons that are essentially static badges (their .bezelStyle is set to .badge). I’ve seeing very low performance when doing quick reloads in successions, for example when filtering data. My app is built on macOS Tahoe. Profiling the app in instruments I can see that each initialization takes more than 70ms. Does this make sense? Thanks!