I have a question about NSSplitViewItemAccessoryViewController, introduced with the new design since macOS 26, and how it interacts with NSScrollView content insets. My app has a typical three-pane window whose content view controller is an NSSplitViewController subclass. The sidebar contains a tab view with a segmented control, similar to Xcode, for switching between different sidebar panes. Each pane contains an NSScrollView whose content can be scrolled. Before macOS 26, I placed the segmented control directly inside the sidebar view. To adopt the new scroll-edge effect and allow the sidebar content to extend visually into the window title bar, I moved the segmented control into an NSSplitViewItemAccessoryViewController. However, with this layout, the scroll view starts immediately below the segmented control, which feels visually cramped. I'd like to add a few points of top inset before the document view begins. Previously, I achieved this by setting: scrollView.additionalSafeAreaInsets.top However, this now causes the accessory view's scroll-edge effect to extend into the additional safe-area inset, producing an awkward blurred region underneath the segmented control. Ideally, I'd like the scroll view to begin directly below the segmented control while still having a small inset before the document content, with the scroll-edge effect ending exactly at the bottom of the accessory view. In addition to additionalSafeAreaInsets, I tried the following approaches, but neither produced the desired result: Set scrollView.automaticallyAdjustsContentInsets to false and specify scrollView.contentInsets.top. This disables the automatic safe-area adjustment, causing the entire scroll view to move upward underneath the accessory view. Set scrollView.contentView.automaticallyAdjustsContentInsets to false and specify scrollView.contentView..contentInsets.top. This produces the same result as above. Set the accessory view's preferredScrollEdgeEffectStyle to .soft. The segmented control becomes too transparent, making its unselected labels difficult to read. Xcode's sidebar appears to achieve the behavior I'm looking for. What is the recommended way to implement this layout on macOS 26 and 27? Xcode's sidebar (macOS 26) My app's sidebar (macOS 26, work in develop) with additionalSafeAreaInsets

This happens with my own code as well as with the Apple example code here: Supporting Drag and Drop Through File Promises When dragging a file promise, the above example code will fail if the destination is in /tmp. It will print out the following message to the console: An error occurred while attempting to get a unique promise file URL. Error: Did not receive a valid URL. It doesn't seem to fail if you create a directory inside /tmp and drop into that. But dropping in /tmp fails 100% of the time. And it fails for MacOS Versions from Sequoia all the way up to the most recent Golden Gate beta. Using /tmp as a destination should most certainly be allowed, but if for some reason it isn't, is there any way in my own code to detect the drop destination and perhaps warn the user that they need to drop somewhere else? To reproduce this error, use the following steps: Download the Apple example code from the link above Open the project in Xcode, build it, and run it Drag any image into the example app's main window Open a Finder window and navigate to /tmp Drag the image from the example app into the /tmp directory in the Finder window. You will see the above error in the Xcode console and the drop will fail.

It seems like macOS 27 beta 2 has some issues with NSStatusItem buttons added to the menu bar - this creates difficulties for some menu bar extra apps. NSStatusItem buttons does not receive mouse hover/movement events - FB23329983 On macOS 27, views inside an NSStatusItem button no longer receive hover or mouse-movement events. The same code works correctly on macOS 26. What I tried: An NSTrackingArea attached to a subview of NSStatusBarButton An NSTrackingArea attached directly to the status-bar button Replacing NSStatusItem.view with a custom view Embedding an NSHostingView and using SwiftUI onHover/onContinuousHover NSStatusItem button highlight cannot be set programmatically. - FB23330269 The following code no longer has any effect (does not provide the highlight capsule): NSStatusItem.button?.highlight(true) NSStatusItem window occlusionState no longer reflects hidden menu bar visibility - FB23349447 The following no longer works: statusItem.button?.window?.occlusionState.contains(.visible) These changes may be related to some of the touch related changes or maybe it's about how menu items are now seemingly more "managed" in a way that their position, visibility may change in a way that is transparent/undetectable to the app.

NSTrackingSeparatorToolbarItem adds a white band over the top of the leading split view panes when in full screen mode on macOS 27. That white band appears to have the height of the toolbar. I filed FB23827858 with a sample project and a video demonstrating the issue. I also wrote about it at: https://virtualsanity.com/202607/nstrackingseparatortoolbaritem-causes-problems-when-putting-a-window-in-full-screen-on-golden-gate-macos-27/ I am hoping this is addressed before macOS 27 ships.

Is anyone else getting these assertion crashes on developer beta 3 of Golden Gate? I've gotten more than a dozen crash logs from users running macOS 27 (26A5378j) that all look like this: assertion failed: '<NSRemoteView: 0x79cb366700 com.apple.SafariPlatformSupport.Helper SPCompletionListServiceViewController> notified of <NSStatusBarWindow: 0x79cbef7480> but expected (null)' in -[NSRemoteView containingWindowWillOrderOnScreen:] on line 4221 of file /AppleInternal/Library/BuildRoots/4~CSuOugB1YCxzYMPRWEumvvfCTNtf98eItTmsbJU/Library/Caches/com.apple.xbs/TemporaryDirectory.N8fh9t/Sources/ViewBridge/NSRemoteView.m but with various windows from my app after "notified of". They're getting thrown when one of my windows is made frontmost, either using NSWindow.orderFrontRegardless or NSWindow.makeKeyAndOrderFront, or (in the case above) when my status item is shown. It's intermittent - I've been unable to reproduce it so far - but definitely happening repeatedly based on my Sentry crash logging. Is this a bug in Golden Gate b3, or am I doing something to provoke this? I've submitted it via Feedback Assistant (FB23642313). Thanks Jon P.S. Full stack trace attached for the exception thrown when the assertion fails for NSStatusBarWindow NSInternalInconsistencyException stack trace.txt

Hi, I've been trying to resolve an issue that my users are facing for about one year, but I haven't been able to so far. That's why I'm turning to you all for some ideas. Some of my users have noticed that my app suddenly exits. It runs in the background as a menu bar app, so when they go to use it, they realize it's no longer running. I've checked Crashlytics and asked users to check their Console app for crash reports, but there are none. The conclusion so far is that it's not a crash, but a silent termination. I haven't experienced this on my own machine, which makes it incredibly difficult to debug or identify the cause. Recently, I thought I'd pinned down the problem. My app was declaring: <key>NSSupportsSuddenTermination</key> <true/> Based on the documentation, this is intended to quickly terminate the app during logout or system shutdown, but I read it can also be triggered when the system needs resources. It seemed like the perfect root cause. However, even after turning it off, one of my users is still experiencing the problem. I'm officially running out of ideas. Does anyone have suggestions on what else I should check? My app currently declares: <key>LSUIElement</key> <true/> <key>NSSupportsAutomaticTermination</key> <false/> <key>NSSupportsSuddenTermination</key> <false/>

Hi. macOS 26.5 introduced a bug involving menu item keyboard shortcuts without modifier keys. For example, it affects a menu item with the keyboard shortcut J, but not the keyboard shortcut ⌘J. This bug is also present in the first beta of macOS 27. When a menu item is invoked with a keyboard shortcut that has no modifiers and its validateMenuItem(_:) method returns false, the system beeps and refuses to perform the operation. This is expected. But then even after validateMenuItem(_:) is returning true again, the app will continue refusing to perform that keyboard shortcut until the app is quit and relaunched. It will also do the same with all other keyboard shortcuts that have no modifiers and are attached to menu items. I filed this with a sample project as FB22762541. I also wrote about it in more detail at: https://virtualsanity.com/202605/bug-involving-keyboard-shortcuts-for-menu-items-that-have-no-modifier-keys-on-macos-265/ I would love to see this issue addressed. Thank you for your work.

NSApp(ignoringOtherApps:) is deprecated but there is no other working alternative for menu bar apps. NSApp.activate() does not work when no app windows are active and we want to show a window from a menu bar application. Making it impossible for the app to open a window and make it active. Is it really an intended behavior? Here is a sample project showing the issue: https://github.com/wojciech-kulik/macos-menu-bar-bug Steps to reproduce: Run the app. Focus some other app like Finder or Safari. Click on the app's menu bar icon and select "Open". The app window will appear below the other app's window, instead of being brought to the front. NSApp(ignoringOtherApps: true) works as expected though. I also created a feedback ticket: FB23508310

My app is now crashing when clicking on the tray icon with macOS 27 when it worked just fine with previous releases. I've submitted a feedback issue, FB23457330, but was curious if this should be something I should be looking into. Thread backtrace is Thread 9 Crashed:: Dispatch queue: com.apple.root.utility-qos.cooperative 0 libsystem_kernel.dylib 0x18539a654 __pthread_kill + 8 1 libsystem_pthread.dylib 0x1853d6970 pthread_kill + 296 2 libsystem_c.dylib 0x1852d8b4c abort + 148 3 libc++abi.dylib 0x18538d2ec __abort_message + 132 4 libc++abi.dylib 0x18537a640 demangling_terminate_handler() + 296 5 libobjc.A.dylib 0x184f6e3cc _objc_terminate() + 156 6 libc++abi.dylib 0x18538a288 std::__terminate(void (*)()) + 16 7 libc++abi.dylib 0x18538c79c __cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 88 8 libc++abi.dylib 0x18537918c __cxa_throw + 92 9 libobjc.A.dylib 0x184f648f0 objc_exception_throw + 448 10 Foundation 0x186c6e858 -[NSAssertionHandler handleFailureInMethod:object:file:lineNumber:description:] + 288 11 AppKit 0x1899a6cfc -[NSMenu itemArray] + 32 12 AppKit 0x18a0987fc -[NSMenu _campoItem] + 24 13 AppKit 0x18a09831c -[NSMenu _assistantFieldIsEffectivelyVisible] + 24 14 AppKit 0x18a09d970 -[NSMenu _effectiveTypingBehavior] + 60 15 AppKit 0x189f1a7d0 -[NSContextMenuImpl _targetWidth] + 164 16 AppKit 0x189f1afe4 -[NSContextMenuImpl _commitWindowSizeChangesForWidth:height:animated:] + 96 17 AppKit 0x189f21880 -[NSContextMenuImpl _updateSizeEstimateForItemAtIndex:includingHeight:] + 1556 18 AppKit 0x189f1f8dc -[NSContextMenuImpl _menuItem:atIndex:didChangeTitleFrom:to:] + 260 19 AppKit 0x1899acf38 -[NSMenu _menuItem:didChangeTitleFrom:to:] + 124 20 AppKit 0x1899a9cb4 -[NSMenuItem setTitle:] + 160 21 NCXClient 0x100061438 0x100018000 + 300088 22 NCXClient 0x10006bc95 0x100018000 + 343189 23 NCXClient 0x10003c909 0x100018000 + 149769 24 NCXClient 0x10004d3b9 0x100018000 + 218041 25 NCXClient 0x10003c909 0x100018000 + 149769 26 libswift_Concurrency.dylib 0x2acf59d41 completeTaskWithClosure(swift::AsyncContext*, swift::SwiftError*) + 1

I’m working on a storyboard-based AppKit application that uses an NSWindowController containing an NSSplitViewController with multiple child view controllers. The hierarchy is roughly: NSWindowController └── NSSplitViewController ├── NSViewController ├── NSViewController └── NSViewController I am trying to provide dependencies during storyboard instantiation using either @IBSegueAction or instantiateInitialController(creator:), rather than configuring everything after initialisation. What I attempted I added custom initialisers to my view controllers so I can pass dependencies at creation time: class SplitViewController: NSSplitViewController { let dependency: Dependency init?(coder: NSCoder, dependency: Dependency) { self.dependency = dependency super.init(coder: coder) } required init?(coder: NSCoder) { print("init(coder:) was called") fatalError("init(coder:) is not supported") } } I then attempted to intercept storyboard instantiation using @IBSegueAction, trying it in both the window controller and the split view controller: @IBSegueAction func makeSplitViewController(_ coder: NSCoder) -> NSSplitViewController? { SplitViewController(coder: coder, dependency: dependency) } I also tried attaching the segue action at different points in the storyboard, but the behaviour did not change. Observed behaviour Regardless of where I place the segue action, AppKit still appears to call: required init?(coder: NSCoder) This means my custom initialiser is never used for the split view controller or its children. Background reference I found this older known issue in the Xcode 11 release notes: “A Segue Action on a relationship segue between a NSWindowController and a View Controller is currently not supported and ignored. (48252727)” This suggests that, at least historically, AppKit relationship segues ignored segue actions entirely. Has this limitation since been fixed in modern Xcode/macOS SDK releases, or are relationship segues involving NSWindowController still incompatible with @IBSegueAction? More generally, what is the intended way to provide dependencies to an NSSplitViewController and its child view controllers in a storyboard-based AppKit application? I am also unclear whether instantiateInitialController(creator:) participates in the creation of container hierarchies like split view controllers, or only top-level controllers.

I have an NSTableView used as a source list and, alongside it, two editors. When the user selects anything in the table view, its content is opened in the editor that has the focus. When the user Opt-clicks an item in the table, though, the content is opened in the other editor, making it easy for the user to load something in the other editor without having to change the focus first. This has worked for many years using NSTableView.selectiondDidChange / the NSTableViewDelegate as follows: func tableViewSelectionDidChange(_ notification: Notification) { if let event = tableView.window?.currentEvent, event.type == .leftMouseUp || event.type == .leftMouseDown, // (Real app does some other checks here too.) event.modifierFlags.contains(.option) { openInOtherEditor() return } openInCurrentEditor() } However, on macOS 27, it seems that things need to be done differently because of the transition to gesture recognisers for event handling. According to the WWDC video "Modernise Your AppKit App", and to Tech Note TN3212, currentEvent can no longer be relied upon to provide the event that actually triggered an action in NSControl subclasses: The transition to gesture recognizers on NSControl objects changes the timing of when AppKit delivers control action messages with respect to event processing. As a result, currentEvent no longer returns the event that triggered an action. It's unclear whether this new limitation refers only to NSControl.action or to all mouse-driven actions, but from the context and what the rest of the Tech Note has to say, I assume it's the latter. (Especially since you are no longer supposed to override mouseDown(with:), and the Console warns about gestures being disabled if you do override mouseDown(with:) in an NSTableView subclass on macOS 27.) currentEvent still seems to work fine in this situation in the first macOS 27 beta, but it sounds as though we cannot rely on this continuing to be the case. If we should no longer be using currentEvent, then, what should we use instead to determine whether a selection change was triggered by a mouse click? The Tech Note and WWDC video have nothing to say about this. They simply say that instead of overriding mouseDown(with:), you should use the selection-did-change delegate methods, which is of no help here. (By contrast, checking the modifier flags is still straightforward; the Tech Note says to use NSEvent.modifierFlags instead of currentEvent.modifierFlags.) Two solutions sprung to mind, but neither worked: Check tableView.clickedRow != -1 in the selectionDidChange delegate method/notification response. This doesn't work, however, because clickedRow has been reset to -1 by the time NSTableView.selectionDidChange is sent. Add an action to the table view and check clickedRow there. This doesn't work either, though, because although clickedRow is available in the action method, I would now have to load content in response to both an action and a selection change, and since the selection changes before the action is called, there is no way of telling my selection-did-change method not to load in the main editor if Option is held down in the action. The only solution I have found is to override selectRowIndexes(_:byExtendingSelection:), check for clickedRow != -1 there, set a didChangeSelectionWithMouse flag to true if so, and check that in the selection-did-change delegate method. That works, but it's not the most elegant of solutions. So: Am I misunderstanding the Tech Note? Can currentEvent still in fact be used safely in tableViewSelectionDidChange(_:) in macOS 27 and beyond? If not, what is the recommended way of checking that the table selection has been changed by a mouse click? Many thanks!

We're using IKPictureTaker to let users pick a room avatar image. The flow worked correctly on macOS 13–15, but breaks on macOS 26 (Tahoe). Symptoms popUpRecentsMenu(for:withDelegate:didEnd:contextInfo:) — no UI appears at all, and the didEnd selector is never called runModal() — a window appears but its content is completely blank (empty gray rectangle). The app freezes until the user force-quits Minimal reproduction import Quartz let pictureTaker = IKPictureTaker.pictureTaker() pictureTaker?.setCommonValuesForKeys(allowsVideoCapture: true) // Attempt 1 — silent fail, no UI, no callback pictureTaker?.popUpRecentsMenu(for: someButton, withDelegate: self, didEnd: #selector(pictureTakerDidEnd), contextInfo: nil) // Attempt 2 — window appears but content is blank let result = pictureTaker?.runModal() // result is never returned while window is visible; app is frozen Environment macOS 26.0 (Tahoe) — reproducible by QA on multiple machines Xcode 16, Swift 5, deployment target macOS 10.14 Camera permission granted (AVAuthorizationStatus.authorized) App is sandboxed What I've ruled out Camera permission is authorized before the call The view passed to popUpRecentsMenu has a valid, visible, key window Same code works on macOS 13, 14, 15 Question Is this a known regression in macOS 26? Is IKPictureTaker expected to stop working, or is there a required entitlement / initialization step that changed? If the API is effectively unsupported, is NSOpenPanel with allowedContentTypes: [.image] the recommended migration path?

I have an NSTextView subclass that overrides mouseDown: to allow for image resizing. If a user clicks and drags on the edges of an image, I implement custom behaviour that resizes the image (and shows resizing cursors). If the user clicks anywhere else, super's implementation is called. This all works great. As of macOS 27, however, the transition to gesture recognisers instead of overriding mouseDown: means that I should probably be moving away from the above approach. NSTextView now uses the new NSTextSelectionManager to implement selection and dragging via gesture recognisers, although, according to the release notes: Existing NSTextView subclasses that override mouseDown: continue to work through a binary-compatible fallback path. (163365571) It's unclear whether this means that we therefore should still override mouseDown: for custom behaviour in NSTextView, but to me, this, along with the content of Tech Note TN3212, strongly implies that, although it will continue to work thanks to "a binary-compatible fallback", we should entirely move away from overriding mouseDown: in the future. If that is indeed the case, how do we implement custom dragging behaviour--such as for resizing images as in my example--in NSTextView? There still seems to be no way of doing it other than overriding mouseDown:. I had thought that I might be able to add an NSPanGestureRecognizer to the text view and have it fail via its delegate methods if the clicks were outside of an image's edges, but a pan gesture recogniser added to an NSTextView is entirely ignored, presumably because of the private gestures already added. Fortunately everything continues to work for now, but I would like to update my code as much as possible.

I have an NSTextView subclass that replaces the standard context menu with a custom one by building its own menu in an menuForEvent: override. The context menu that is shown depends on what is selected in the text view, so it checks the current selectedRange to determine which commands should be included. (I could do much the same via the NSTextViewDelegate method textView(_:menu:for:at:), but since my text view subclass is used in several areas, each with their own delegate, it's better to do it in menuForEvent(_:).) This has all worked fine for years, but with NSTextView's transition to gesture recognisers and NSTextSelectionManager for handling text selections in macOS 27, the timings have changed. Previously, if you Ctrl-clicked on a word so that the word is selected and the context menu appears, setSelectedRanges:affinity:stillSelecting: would be called first and then menuForEvent: would be called. On macOS 27, however, the order of events is reversed: menuForEvent: is called first, before setSelectedRanges:affinity:stillSelecting:. (If you implement NSMenuDelegate.menuNeedsUpdate:, that is also called before setSelectedRanges:....) This means that you can no longer rely on selectedRanges in menuForEvent:, because on macOS 27, selectedRanges in menuForEvent: represents the previous selection, not the selection you will actually see on screen when the menu appears. This makes building a custom context menu somewhat tricky. I suspect this is a bug and have reported it as such (FB23251873, with apologies to the engineers for the pleading tone in that report; it was at the end of a long week of getting my head around the gesture recogniser changes. :) ). But it occurs to me that there is nothing in the documentation that guarantees that selectedRanges will be accurate in menuForEvent:; it's just always worked this way. So am I missing something here? Is there a better or more reliable way of getting the range that will be affected by the contextual menu in NSTextView? (The delegate method only provides a single character index, which isn't enough information for spelling corrections and such which require a range.) My current workaround is to rebuild the context menu in setSelectedRanges:affinity:stillSelecting: if it is called between menuForEvent: and didCloseMenu:withEvent:.

I'd like to create a Quick Look extension for a file type for which a location or region on a Map should be shown as preview. However the MapView would only show a grid without any map. From within the MapKit delegate I can see from the "Error" parameter (a server with this domain can not be found) that this seems to be a network issue. The Quick Look extension seems to have no access to the internet and therefore the MapView can not load any map data. I've then also done some other tests via URLSession, which also only fails with connection errors. I haven't seen any limitations or restrictions mentioned in the API documentation. Is this the expected behavior? Is this a bug? Or am I missing something?

We have a Mac app the allows customers to create a user account in our system. However, we have found that on the 'create account' screen, the system's password autofill is popping up for the "New Password" field. We don't want this, because they need to enter a new password, not pull one from the Passwords app. I built a test project with a basic UI and explicitly set the content type to None in the XIB. However, I can see when I put focus on the "New Password" NSSecureTextField, the system shows the passwords autofill popup. How can I explicitly suppress this on a per text field basis? (We are developing on macOS 26.3 right now with Xcode 26.3)

We have a status item which works fine on macOS 26 and earlier, which has the following properties: Supports left-click to open main UI (a popover) Supports left-click (while open) to toggle (close) the main UI Supports right-click to show "app" menu (e.g. About, Quit) Supports a drop destination to accept files and folders, which then triggers the main UI for more interaction In macOS 27: left-click seems ok if we use expanded interface session, but otherwise broken left-click while open no longer toggles (event is missing?) right click is no longer operational, to the point that it seems the Menu Bar doesn't forward the event at all. Other (Apple-provided) items work fine, and expose new context menus Dragging now triggers Mission Control, which seems wrong given the destination was in the Menu Bar (FB23018381). Are these interactions now forbidden, and are there lists or documentation of the new rules? As an additional bug, it looks like popovers don't pick up appearance changes. The child scroll view claims to be in light appearance in the View Debugger, but is clearly showing the wrong background color, this is a new (as-yet unreported) issue. One last bug: expanded interface session seems to suppress the popover's animation when shown.

It seems this method is not updated for the new "Show on all Spaces" option in system wallpaper preferences. I encounter this problem because one customer reported that every time my app sets a new wallpaper, this option is turned off. NSDictionary* options = [SHARED_WORKSPACE desktopImageOptionsForScreen:screen]; [SHARED_WORKSPACE setDesktopImageURL:imageFileURL forScreen:screen options:options error:&error]; This can be easily verified by dumping the returned dictionary - which only contains 3 keys. Is this a known bug?

I'm trying to use NSTokenField for the first time. So my custom 'representedObject' for a token has additional model data tied to it (not just the editing/display string). I noticed when I edit an existing token, type text, and hit the enter key I get the following delegate callback: - (nullable id)tokenField:(NSTokenField *)tokenField representedObjectForEditingString:(NSString *)editingString; This same delegate method is called when I type a brand new token. Is there a way to distinguish if I'm editing a token vs. creating a new one? My expectation is to be able to do something like this (made up enhancement): - (nullable id)tokenField:(NSTokenField *)tokenField representedObjectForEditingString:(NSString *)editingString atIndex:(NSUInteger)existingTokenIndex { if (existingTokenIndex == NSNotFound) { // Token is new, create a new instance MyTokenObject *newToken = //create and configure. return newToken; } else { // This would update the editing string but wouldn't discard existing data held by the token. MyTokenObject *tokenObj = [self existingTokenAtIndex:existingTokenIndex]; tokenObj.editingString = editingString; return tokenObj; } }

Putting: let statusItem = NSStatusBar.system.statusItem(withLength: NSStatusItem.variableLength) at the top of AppDelegate.swift and no other code at all generates the warning below in the console when the app runs. Looks benign but it sure would be great to not have that happen. Anyone figure out how to stop this other than muting the warning? I tried all kinds of exotic deferring but that just makes the code brittle and unreadable. Here's the warning: 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 void _NSDetectedLayoutRecursion(void) to debug. This will be logged only once. This may break in the future. Xcode 26.5, 26.4 - macOS 26.5.1