Have you tried setting shouldAllowToOpenInPlace to true? Unfortunately, the shouldAllowToOpenInPlace flag doesn’t help solving my issue. Setting that flag prevents the file from being copied by dragging it in Finder. Also, FileRepresentation doesn’t seem to be involved when passing a file URL to another app such as Safari. It appears that other representations need to be provided as well. For example, if I add ProxyRepresentation(exporting: \.fileURL.absoluteString) afterward, I can drop the item onto Safari’s Dock icon. However, dropping it onto Safari’s address bar passes the URL of the sandbox container instead, and dropping it onto Safari’s content view does not interact with the page at all. struct FolderFindDraggedFile: Transferable, Identifiable { var fileURL: URL static var transferRepresentation: some TransferRepresentation { FileRepresentation(exportedContentType: .data) { item in SentTransferredFile(item.fileURL, allowAccessingOriginalFile: true) } .suggestedFileName(\.fileURL.lastPathComponent) ProxyRepresentation(exporting: \.fileURL) } }

I found the answer myself and was able to resolve this. It turns out this was actually introduced as a new feature/API in macOS 27, and I had simply overlooked it. The animation can be enabled by assigning one of the new NSSegmentedControl.Role values. Since I’ve already solved the issue, no further replies are necessary.

Thank you for the suggestions. I’ll experiment with a few more approaches based on the ideas you provided. The interaction between NSScrollView and NSTextView is quite complex, and there are still many aspects of their behavior that I don’t fully understand. You and your colleague's advice has been very helpful. Thanks for the question. I love CotEditor! Thank you! I’m glad to hear that. I’m always striving to make it the most macOS-native text editor possible.

Thank you for the reply. I was mainly asking about the source of the document content out of technical curiosity, so it was interesting to learn more about how it works. I appreciate that macOS sometimes quietly introduces thoughtful features like this, but in this case I almost feel Apple should be promoting it more. It’s a genuinely great feature. I also think one of the most compelling aspects of this functionality is that, by using a local model, it can generate summaries based on the contents of a user’s documents without sending that personal information online. That is a significant advantage of a system-provided feature like this, and I think it’s fantastic. Thank you as well for explaining how the feature can be disabled. From my perspective, having a system-level setting is sufficient. If users of my application ask about it, I will point them to the method you described. In general, I think system-level features are best controlled at the system level, as that tends to be the most straightforward approach.

Thank you for the additional information! I suspected that the first suggestion—placing the search field inside the scroll view—would not be a good fit for my particular use case. However, the follow-up note that “a search field which customizes its own drawing behaves a little differently here” is extremely helpful. In fact, I discovered that simply overriding draw(_:) in an NSSearchField subclass, even without changing the drawing behavior at all, is enough to suppress the Liquid Glass appearance. override func draw(_ dirtyRect: NSRect) { super.draw(dirtyRect) } As you mentioned, this is only a workaround, so I still plan to file a formal enhancement request. Nevertheless, tips like this are incredibly useful and much appreciated.

We've made improvements specifically for the performance of DisclosureGroup inside of List in macOS 27.0. Wow! That’s great to hear! Thank you for making those improvements. Lists and tables are still areas where SwiftUI can be challenging to use on macOS, so I always look forward to the performance improvements and API refinements that arrive each year. In that case, my scenario may provide a useful test case. I’ll put together a detailed report and submit it through Feedback Assistant.

Thank you for the reply. I understand that there is currently no way to change this behavior. Even knowing that is helpful. I have also seen this appearance in the App Store on macOS 27. In that context, the Liquid Glass style did not feel out of place to me. I think it would be beneficial if applications could choose the appropriate appearance depending on the use case. My first thought was that adding a new case to bezelStyle (NSTextField.BezelStyle) would be a straightforward solution, although a separate flag or another API might also be appropriate. In any case, I will submit feedback requesting this capability. Thanks!

Thank you for the suggestion. Would it be possible to extend your scroll view to underlap the line numbers, and inset your content views to compensate? I have tried that approach before, however, unfortunately, it did not work well in my case. My text view can be configured to scroll horizontally instead of soft-wrapping lines at the window edge. In addition, the line number view can be made semi-transparent. As a result, when the text content scrolls underneath the line number area, I was unable to achieve correct visual compositing between the line numbers and the text view’s content. For reference, the following screenshot shows the appearance of my application with its background transparency feature enabled.

@z0rk Hmm, I’ve already submitted a new version of my app with the new entitlement to the Mac App Store and it was accepted.

Sent my feedback FB22246971

Thank you again for your quick response! I understand that this may be an issue on the macOS side and that, unfortunately, there is no available workaround at the moment. I hope this behavior can be addressed in a future update. I also appreciate you sharing the background behind this phenomenon. It’s technically interesting to me. If you’re able to reproduce not-returning case, a sysdiagnose log from that might yield a useful insight. OK. I’ll send additional information, including a sysdiagnose, if I’m able to reproduce the not-returning case.

@DTS Engineer Hi Quinn, thank you for additional information. However, I suppose checkResourceIsReachable() returns true if the file exists, regardless of whether it can be accessed. What I want to know this time is whether the app can open that file in a sandbox environment.

@Etresoft You can use the "isReadable" value from URLResourceValues. Thank you. This is exactly the API I was looking for. However, it sounds like you're not approaching this from the right direction. I'm not trying to open random files...; I just want to use it to prompt the user to obtain access permissions if they don't have them for the file they tried to open (the file linked by an alias).

Since there appears to be no existing solution, I filed it as feature request: FB21012567.

Oh, sorry. I realized the feedback number mentioned in my original post refers to a wrong one. I meant FB20432458.