Do you have any ideas on how to make the background color of a NSTextView the same as the background of a NSComboBox when both are on a sidebar? The closest I could get is using a NSVisualEffectView, but it's still not optimal (the text view is slightly darker) override init(frame: NSRect) { self.scrollView = NSTextView.scrollableTextView() if #available(macOS 26.0, *) { scrollView.borderType = .lineBorder let backgroundView = NSVisualEffectView() backgroundView.material = .contentBackground backgroundView.blendingMode = .withinWindow backgroundView.state = .followsWindowActiveState backgroundView.translatesAutoresizingMaskIntoConstraints = false self.materialBackgroundView = backgroundView } else { self.materialBackgroundView = nil } ...

I added images to all NSMenuItems in my app on macOS 26. Now, with macOS 27 beta 1, most of them are no longer displayed, which seems to be the behavior of NSMenuItem.ImageVisibility.automatic. However, this only happens for images initialized with NSImage(systemSymbolName:accessibilityDescription:). Images initialized with NSImage(named:) are still shown, despite the visibility setting being .automatic. What would be an approach that is consistent for all app-contributed NSMenuItems while still respecting the system default? Even more, how would one set image visibility to also address possible future system settings that decide on menu-item image visibility? As a side note, the documentation for NSMenuItem.ImageVisibility has no description for .automatic, and the documentation for .hidden and .visible seems wrong or misleading (or I'm misunderstanding): .hidden: The item image should always be visible. Note that in some cases, AppKit may still hide the image, overriding this preference. .visible: AppKit should choose whether the item’s image is visible, considering the system configuration.

This example application crashes when entering any text to the token field with FAULT: NSGenericException: The window has been marked as needing another Update Constraints in Window pass, but it has already had more Update Constraints in Window passes than there are views in the window. The app uses controlTextDidChange to update a live preview where it accesses the objectValue of the token field. If one character is entered, it also looks like the NSTokenFieldDelegate methods tokenField(_:styleForRepresentedObject:) tokenField(_:editingStringForRepresentedObject:) tokenField(_:representedObjectForEditing:) are called more than 10000 times until the example app crashes on macOS Tahoe 26 beta 6. I've reported this issue with beta 1 as FB18088608, but haven't heard back so far. I have multiple occurrences of this issue in my app, which is working fine on previous versions of macOS. I haven't found a workaround yet, and I’m getting anxious of this issue persisting into the official release.

I'm getting a sandbox_extension_issue_file error [1: Operation not permitted] from ScopedBookmarkAgent while trying to resolve a successfully created security-scoped bookmark via URL(resolvingBookmarkData:options:relativeTo:bookmarkDataIsStale:) which then produces the error Error Domain=NSCocoaErrorDomain Code=256 "Couldn't issue sandbox extension for the resolved URL" The error only occurs for files under a dedicated folder /System/Volumes/Data/Test and not for files and folders under, e.g., /Users/... From what I understand, everything at /System/Volumes/Data/ and below should be accessible for the user. I've made sure that the Test folder has read and write permissions for the current user and changed ownership of the folder to username:staff, where username denotes my local user name. This happens both under macOS Big Sur 11.6.2 and macOS Monterey 12.1. Any help is much appreciated!