This is from a test app that has NSComboBox, NSTextField, and NSTextView on a sidebar running on macOS 27 beta 1.

Thank you! I've tried various combinations of this already and if I change it like that, the text view is always brighter than the combos (especially in disabled state).

Clearing the background makes the text view use the sidebar background. This is what I currently have with the NSVisualEffectView from above Now that I look at it, it's not so different at all. But still quite different from the NSComboBox background.

Yes, NSComboBox has the desired background appearance (at least this is the one that's most difficult to change, so I'm taking this as the base). I want to use a NSTextView because of its scrolling capabilities and would love to have a consistent look of the controls on the sidebar. I achieved this with different workarounds with the help of a NSTextField pre-macOS 26. But with Tahoe, lots of the visuals of controls on the sidebar changed and I'm looking for a solution to make it visually more consistent. Edit: Here is the feedback ID related to this from last year: FB18025262

Thanks a lot for the answers! Here is the feedback ID: FB23070183

Thank you for the explanation. I use non-symbol images for menu items when there is no suitable SF Symbol available and I instead have a named template image. To keep image visibility consistent across menu items on macOS 27, I would therefore need to explicitly set those non-symbol images to .hidden. While that works with the current behavior, it also means opting out of future system decisions regarding .automatic. If AppKit changes the policy behind .automatic in a future release, those menu items would no longer follow the system default behavior. It seems that a separate setting, for example .system, that applies the current system policy uniformly to all image types would avoid this ambiguity and allow applications to respect future platform changes without having to distinguish between symbol and non-symbol images.

Hello Dave, I just received an update to my original feedback from Apple, stating that your solution to implement isEqual() is the correct solution and that the "Investigation is complete - Works as currently designed". Thanks for sharing your solution!

No reply from Apple and no similar reports in the Feedback app, as usual. I also gave up on updating my feedback with each beta, it's just too frustrating. Instead, I rewrote everything to use strings instead of a custom token type. It requires more parsing passes, but it doesn't crash. Hope this path is also an option for you!

Many thanks for your help and guidance! I've reported this as FB9843248.

If you sent up a synthetic symbolic link to this directory, do you still have the problem when you navigate to it normally (that is, using /Test rather than /System/Volumes/Data/Test)? Yes, the problem persists also when using a synthetic symbolic link. NSOpenPanel.directoryURL points to /System/Volumes/Data/Test after choosing /Test. Thanks for pointing to synthetic symbolic links. I wasn't aware of the feature and learned something new today!

No. My earlier question wasn’t really intended as a workaround but rather as a diagnostic test. I’ve no idea what’s causing the underlying issue )-: OK, understood. Accessing the data volume directly in this way is somewhat unusual. Absolutely, and it's something I'd usually not do. However, as mentioned earlier: As some background: I've not randomly tried to break things, but got a report from a user of my app describing this issue. Apparently, migration assistant created a new folder /System/Volumes/Data/Data/ when moving to Monterey where all the files reside which he tries to edit using my app. So it's a real-life problem, the user who reported this issue loaded the files via drag and drop. In my tests I've dropped the files from a Finder window I've opened via Terminal.app open /System/Volumes/Data/Test. Dropping a folder to the location on the open panel also changes the folder. Didn't know that command-shift-G also works here :)

Yes, accessing the URL directly works — thanks for the workaround! I'd then need to add some extra machinery to store "per-session" security-scoped URLs that cannot be persisted using security-scoped bookmarks. FYI, NSDocumentController.noteNewRecentDocumentURL() also gives a sandbox error for the URL. Can you provide any details on the underlying reasons for this behavior? Is it also to be expected in other circumstances?

It's either from a URL that stems from an NSOpenPanel or the result of a drag and drop operation. var bookmarkData: Data? let openPanel = NSOpenPanel() openPanel.canChooseFiles = false openPanel.canChooseDirectories = true if openPanel.runModal() == NSApplication.ModalResponse.OK { guard let url = openPanel.urls.first else { return } do { bookmarkData = try url.bookmarkData(options: .withSecurityScope, includingResourceValuesForKeys: nil, relativeTo: nil) } catch { NSApplication.shared.presentError(error) } } Trying to resolve the successfully obtained bookmark via the aforementioned URL initializer fails: var isStale = false let url = try URL(resolvingBookmarkData: bookmarkData, options: .withSecurityScope, relativeTo: nil, bookmarkDataIsStale: &isStale) It's also possible to reproduce this issue with an example project I've created for a previously reported sandbox-related issue: https://github.com/fheidenreich/sandbox-fat32-rename Choose, e.g., /System/Volumes/Data/Test/ via the "Select..." button. Press "Create test file" to see the error occur. As some background: I've not randomly tried to break things, but got a report from a user of my app describing this issue. Apparently, migration assistant created a new folder /System/Volumes/Data/Data/ when moving to Monterey where all the files reside which he tries to edit using my app. It's of course possible to move the data to the User's folder, but I wanted to at least gather some understanding of the underlying issue and possibly prevent this from happening again. Thanks for your reply!

Thanks for your reply! I've tried both methods, unfortunately without success. The canonical path method did not resolve /System/Volumes/Data/Test/ to /Test/ and the string replacement results in error Domain=NSCocoaErrorDomain Code=260 "Scoped bookmarks can only be created for existing files or directories"