If I use a SwiftUI Scrollview and scroll horizontally, for example, the scroll content goes underneath the inspector or sidebar views on macOS 26 (probably on older versions as well) But by default, the AppKit scrollviews don't exhibit this behaviour. How do I adapt this to match SwiftUI behavior?

Hello, we are currently integrating Writing Tools into our macOS application using NSWritingToolsCoordinator with a custom NSView. Overall, the integration is going well and we are generally satisfied with the API. However, text replacement is sometimes not using NSWritingToolsCoordinator callback function. When selecting “Replace” from a preview in a Writing Tools UI popup, the text replacement is performed via the NSTextInputClient callback function (insertText:), which does not seem correct. This is especially problematic in multi-context scenarios, because NSTextInputClient insertText: does not provide the required information about the Writing tools context being used. As a result, it is not possible to determine which context is being modified when managing more than a single context. In our view, Writing Tools should consistently use the callback function of NSWritingToolsCoordinator for text replacement, whatever is the action performed. This is essential for properly handling multi-context use cases. This issue is reproducible with the sample app project provided here https://developer.apple.com/documentation/appkit/enhancing-your-custom-text-engine-with-writing-tools. If you define a breakpoint in function writingToolsCoordinator:replaceRange:inContext:proposedText:reason:animationParameters:completion: of the Writing tools coordinator, the function is not triggered if text replacement is performed from a preview like for "Summary" with "replace" button. NSWritingToolsCoordinator callback function seems to be called only when text replacement is performed directly inline (in the text view) without external preview so. i have opened a issue with feedback assistant: FB22401950. Best regards.

Hello, we are currently integrating Writing Tools into our macOS application using NSWritingToolsCoordinator with a custom NSView. Overall, the integration is going well and we are generally satisfied with the API. However, text replacement is sometimes not using NSWritingToolsCoordinator callback function. When selecting “Replace” from a preview in a Writing Tools UI popup, the text replacement is performed via the NSTextInputClient callback function (insertText:), which does not seem correct. This is especially problematic in multi-context scenarios, because NSTextInputClient insertText: does not provide the required information about the Writing tools context being used. As a result, it is not possible to determine which context is being modified when managing more than a single context. In our view, Writing Tools should consistently use the callback function of NSWritingToolsCoordinator for text replacement, whatever is the action performed. This is essential for properly handling multi-context use cases. This issue is reproducible with the sample app project provided here https://developer.apple.com/documentation/appkit/enhancing-your-custom-text-engine-with-writing-tools. If you define a breakpoint in function writingToolsCoordinator:replaceRange:inContext:proposedText:reason:animationParameters:completion: of the Writing tools coordinator, the function is not triggered if text replacement is performed from a preview like for "Summary" with "replace" button. NSWritingToolsCoordinator callback function seems to be called only when text replacement is performed directly inline (in the text view) without external preview so. i have opened a issue with feedback assistant: FB22401950. Best regards.

I have a Document based app. It supports different document types. One document type my app supports conforms to another document type that my app also supports. In my app these two UTIs are designated to open different NSDocument subclasses / window controllers. So say we have these two UTIs: com.DocumentType.SuperType com.DocumentType.SubType. Now I just noticed on Tahoe 26.4, the system is launching my app using NSDocument/window controller that is designated for com.DocumentType.SuperType, when I double click a file with the com.DocumentType.SubType UTI. I haven't changed the NSDocument configuration in many years but it looks like something changed recently.

Composer icons can be loaded with NSImage's imageNamed: but I haven't figured out how to make it load any variation other than the light style. Is this even possible? Thank you!

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!

When I end editing pressing the escape key, the system sometimes plays NSBeep(). I noticed this with NSBrowser. Every time I press escape to end editing the system beeps. At first I thought it was somewhere in my app but I set a symbolic breakpoint and discovered it was not coming from my code. I filed FB22127038. Since then I discovered that NSBeep playing at inappropriate times is not exclusive to NSBrowser. It appears if there is a NSTableView in the window and you just press the escape key (even if you aren't editing anything) AppKit beeps. It can be traced to: #0 0x0000000199e3184c in NSBeep () #1 0x000000019aa03fac in -[NSWindow doCommandBySelector:] () #2 0x000000019ac1d01c in -[NSTableView(NSTableViewViewBased) cancelOperation:] ()

Hello Apple Developer Support, I am reaching out for technical guidance regarding screen capture protection behavior on macOS. We are building a desktop application using Flutter running on macOS, and we have implemented native Swift code inside the macOS Runner in order to protect sensitive content from screen recording and screen sharing. Our current implementation relies on native window-level protection and display state handling from Swift, while the main UI remains rendered by Flutter. The main challenge we are facing is the following: we need to keep a strong native anti-recording protection on macOS the application is heavily used with AirPlay and screen mirroring currently, AirPlay / mirroring is often interpreted by the system similarly to screen capture or screen recording this causes our protected content to be replaced by a gray or blank area even during legitimate AirPlay usage In practice, we would like to allow: AirPlay legitimate external display / mirroring usage while still preventing: screen recording screen sharing unauthorized screen capture We would like to know whether Apple recommends an official supported approach for this use case, preferably using public APIs. More specifically: Is there an officially supported way on macOS to distinguish AirPlay mirroring from screen recording / screen sharing? Is "NSWindow.sharingType" the recommended public API for this scenario? Is there a recommended approach when the UI surface is rendered through Flutter / Metal? Are there any best practices with ScreenCaptureKit for protecting content without affecting AirPlay? We understand that some lower-level APIs may not be officially supported, so we would greatly appreciate guidance toward a public and future-proof implementation path. Thank you very much for your time and support. Best regards, Tony

So if I have a selection in NSBrowser. I hit Option+Command+A to invoke "Deselect" the selection in the parent for the last column drops its selections, as expected. But the column doesn't drop off the browser. The delegate method (void)browser:(NSBrowser *)browser didChangeLastColumn:(NSInteger)oldLastColumn toColumn:(NSInteger)column NS_SWIFT_UI_ACTOR; Never fires (since the column isn't dropped off). But we have. dangling last column with no selection in the previous column. Now if there's enough room for me to deselect by clicking the background, the last column drops off, as expected. This seems to be fairly new? Anyone else experiencing this? These 26point updates seem to keep punching me in the face. And yes. deselect all seems somewhat broken in Column view in the Finder as well, but in a seemingly different way. In Finder it just seems to change the selection color like it deactivated the window but doesn't drop the selection. For me, the selection IS dropped but the column remains visible. Maybe they are using Cocoa bindings or something that resyncs the selection after the mess up. I dk.

I use QLThumbnailGenerator to generate icons. After updating to macOS Tahoe 26.4 the folder color preference of the user is no longer respected. It just makes the icon default 'light blue.'

So I just installed the 26.4 update and unfortunately I have to debug this newly introduced issue (that may work its way into a separate thread). In my debugging steps I'm testing something related to files and I used -activateFileViewerSelectingURLs: to show the file in Finder. Now I am off the main thread. I added this line for testing purposes and I get a crash: NSWindow should only be instantiated on the main thread!' terminating due to uncaught exception of type NSException. So apparently - NSWorkspace is calling through to NSServices APIs and for some reason the system wants to present an NSError, which is a subtopic and other bug on its own because the 'Show in Finder" functionality actually WORKS but it crashed my app! #22in +[NSAlert alertWithError:] () #23in -[NSApplication(NSErrorPresentation) presentError:] () #24 +[NSServicesMenuHandler _performServiceFromEntry:withPasteboard:withRequestor:withInvocationSourceType:withCarbonFocus:withSendTypes:withReturnTypes:canReleasePasteboardImmediately:] () #25 +[NSServicesMenuHandler _performServiceWithoutAlternatesFromEntry:withPasteboard:withRequestor:withInvocationSourceType:] () #26 +[NSServicesMenuHandler _performServiceFromEntry:withPasteboard:withRequestor:withInvocationSourceType:] () #27 [NSWorkspace activateFileViewerSelectingURLs:] What error it is trying to present.. I have no idea. I'm not sure if I actually have a code path that calls this method off the main thread but I guess I'll have to check. This clearly goes against the documentation. NSWorkspace documentation clearly states: -activateFileViewerSelectingURLs: Discussion You can safely call this method from any thread of your app. Is this new in 26.4? I'm not sure but I just noticed. I definitely use other NSWorkspace methods off the main thread in areas of my app. Like -activateFileViewerSelectingURLs: the documentation for those other methods claims you can safely call them off the main thread. So now I'm concerned.

Sort of a continuation of - https://developer.apple.com/forums/thread/813641 I've made a great effort to get NSURL -getResourceValue:forKey: calls etc off the main thread. Great progress. So now I'm working with a file on a really slow network volume I discovered a little hang and luckily enough I'm attached to the debugger so I paused that thing. I see where I'm at. It is: NSPathControl's setURL:. It goes a little something like this: in realpath$DARWIN_EXTSN () +fileSystemRealPath () +[FSNode(SandboxChecks) canAccessURL:withAuditToken:operation:] () +FSNode(SandboxChecks) canReadFromSandboxWithAuditToken:] () LaunchServices::URLPropertyProvider::prepareLocalizedNameValue () LaunchServices::URLPropertyProvider::prepareValues () prepareValuesForBitmap () FSURLCopyResourcePropertiesForKeysInternal () CFURLCopyResourcePropertiesForKeys () -[NSURL resourceValuesForKeys:error:] () in function signature specialization <Arg[1] = Dead> of Foundation._NSFileManagerBridge.displayName(atPath: Swift.String) -> Swift.String () in displayName () -[NSPathCell _autoUpdateCellContents] () -[NSPathCell setURL:] () Could maybe, NSPathControl get the display name etc. asynchronously? and maybe just stick raw path components in as a placeholder while it is reading async? Or something like that? If I can preload the resource keys it needs I would but once the NSURL asks on the main main thread I think it will just dump the cache out, per the run loop rules.

Since macOS 26 Beta 1, I notice that the window reopening behavior had changed. Say there are two desktops (spaces), one might: open an app window in desktop 1 close that window switch to desktop 2 reopen the app window (by click on dock tile, spotlight search...) Prior to macOS 26, that window will always reopen in current desktop. This is IMO the right behavior because these windows are most likely transient (message app, chat app, utilities app or note app). In macOS 26, however, will switch to desktop 1 (where the window is closed) and reopen the window in desktop 1. This is weird to me because: Window is "closed", hence it should not be attached to desktop 1 anymore, unlike minimize. Switching desktop interrupts user's current workflow. It's annoying to switch back specially when there're many desktops. This behavior is inconsistent. Some reopen in current desktop, some reopen in previous desktop. Apps like Music, Notes and Calendar reopened in previous desktop, while Mail, Messages, and Freeform reopened in current desktop. I did a little bit of experiment, and find out that apps that reopened in current desktop are most likely because they take an extra step to release the window when it's closed. I believe this is a bug, so I fire a feedback (FB18016497) back in beta 1. But I did not get any response or similar report from others, to a point that I kinda wonder if this is intended. I can easily force my app to reopen in current desktop by nullifying my window controller in windowWillClose, but this behavior essentially change how one can use the Spaces feature that I think I should bring this up to the community and see what other developers or engineers thinks about it.

I have regular NSImage from iPhone and the drawing get's extremely choppy during window resize (especially at small window sizes below 100px). When the window size is large there is no problem with drawing and CPU utilization is low. I have tried kCGImageSourceDecodeToSDR + or another NSImage from CGImage but the CPU utilization is extreme at small sizes. Non-HDR images don't have problems with drawing at small sizes. Video example: https://youtu.be/x8iAYGCyACs import AppKit import AVFoundation class ImageBackgroundView: NSView { @Invalidating(.display) var image: NSImage? = nil override var clipsToBounds: Bool { set { } get { true } } override func draw(_ dirtyRect: NSRect) { super.draw(dirtyRect) NSColor.red.setFill() dirtyRect.fill() guard let image = image else { return } // Calculate aspect-fit rect using AVFoundation let imageSize = image.size let targetRect = bounds let drawRect = AVMakeRect(aspectRatio: imageSize, insideRect: targetRect) image.draw(in: drawRect) } } Copy import Cocoa import UniformTypeIdentifiers class ViewController: NSViewController { @IBOutlet weak var imageView: ImageBackgroundView! @IBAction func buttonAction(_ sender: Any) { let panel = NSOpenPanel() panel.allowedContentTypes = NSImage.imageTypes.compactMap { UTType($0) } panel.begin { response in let nonHDROptions = [ kCGImageSourceDecodeRequest : kCGImageSourceDecodeToSDR, kCGImageSourceDecodeRequestOptions: [kCGComputeHDRStats: false] ] as CFDictionary guard response == .OK, let url = panel.url, let source = CGImageSourceCreateWithURL(url as CFURL, nil), let cgImage = CGImageSourceCreateImageAtIndex(source, 0, nonHDROptions) else { return } self.imageView.image = NSImage(cgImage: cgImage, size: NSMakeSize(CGFloat(cgImage.width), CGFloat(cgImage.height))) } } } Time profiler with HDR NSImage: Time profiler with NSImage + kCGImageSourceDecodeToSDR:

I have a textfield in accessory view of NSSavePanel. For user convenience there are default actions supported natively by macOS (such as pressing Enter, keyEquivalent). However this doesn't work for enter under Sonoma. Escape key works. Is enter keypress dangerous for malicious actors so it's not supported? I have workaround below but I am not confident if I am not violating sandbox (future proof). Original code demonstrating the issue: class ViewController: NSViewController, NSTextFieldDelegate, NSControlTextEditingDelegate { let savePanel = NSSavePanel() override func viewDidLoad() { super.viewDidLoad() let customView = NSView() let textField = NSTextField(string: "11111111") textField.delegate = self // to get focus using tab keypress savePanel.accessoryView = textField } override func viewWillAppear() { savePanel.runModal() } } Workaround: // variable set to true in delegate method controlTextDidEndEditing var didUseTextFieldWithEnterPressed = false override func performKeyEquivalent(with event: NSEvent) -> Bool { if #unavailable(macOS 14) { return super.performKeyEquivalent(with: event) } guard let panel, didUseTextFieldWithEnterPressed == true, event.type == .keyDown && (event.keyCode == UInt16(kVK_Return) || event.keyCode == UInt16(kVK_ANSI_KeypadEnter)) else { return super.performKeyEquivalent(with: event) } return panel.performKeyEquivalent(with: event) }

This is a generic, non-developer related macOS issue, but reporting here as well so it has more visibility since. It is an embarrassing bug that has not been fixed since the earliest versions of macOS Tahoe. Issue description: When Dock Magnification is enabled, the Dock Folder abruptly jumps approx. 10-15pixels down as the user moves the cursor after a brief pause). Video about the issue (see the last second of the small video and observe the entire grid popup jump abruptly): https://forums.macrumors.com/threads/macos-tahoe-26-4-release-candidate-now-available.2479503/post-34494643 Related FB: FB20761846 (opened in October, 2025) The issue is easily reproducible and confirmed by many. The lack of this issue being fixed for so long is indicative in the eyes of many of the lack of attention to details in macOS Tahoe's Glass interface.

If I see it correctly, it is currently not possible to validate a drop operation on a DynamicViewContent when using dropDestination? Just a simple example: Let's say I build a folder view on macOS where I can arrange folders freely. In this case I need to use DynamicViewContent.dropDestination to get an insertion index on drop. However, it seems that methods like dropConfiguration do not have any effect. Als dropDestionation(…, isTargeted:) seems not to be available. Here is my sample code: struct FolderRow: View { let folder: Folder var body: some View { DisclosureGroup(isExpanded: .constant(true)) { ForEach(folder.children) { child in FolderRow(folder: child) } .dropDestination(for: Folder.self) { item, idx in print("Dropped at \(idx)") } } label: { Label(folder.name, systemImage: "folder") .draggable(folder) .dropDestination(for: Folder.self) { items, _ in print("Dropped on Item") } } .dropConfiguration { session in DropConfiguration(operation: .move) } } } struct ContentView: View { @State private var folder: Folder = Folder.sampleData @State private var selection: Set<UUID> = [] var body: some View { NavigationSplitView { List(selection: $selection) { FolderRow(folder: folder) } } detail: { EmptyView() } } } The dropConfiguration is applied on the Label (in this case the "Move" cursor is used instead of the "Copy" cursor). Is there any way to do that or is it just an omission in Swift UI?

So I'm in the middle of an asynchronous file operation. I publish an NSProgress and it displays wonderfully in Finder. But it is a folder and while the operation is in progress the user should not be allowed to enter it, modify it, etc, while the work is being done. I want to do this to protect the user from doing something silly. But Finder does not prevent the selection with the published progress. And while it would be kind of dumb to do - the user can just go about adding/removing contents to the folder while it has progress. If I remember correctly publishing an NSProgress did use to prevent the file from being selectable in Finder until either the progress finished or my app is quit (or maybe not)? But now the user is free to select, edit, modify during progress which could cause problems if the user does something unexpectedly silly. Is there a way to mark the file 'unselectable' with the published progress? Thanks in advance.

A user of my app sent me a crash report. I have never seen one like this before. All of my app's symbols are replaced with three question marks (???) Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 ??? 0x10844eb40 ??? 1 CoreFoundation 0x7ff80f155518 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 137 and the binary image as 0x0 - 0xffffffffffffffff ??? (*) <00000000-0000-0000-0000-000000000000> ??? so I cannot find out where exactly the crash happened. What can cause this kind of crash report and can I do anything with it? crash.ips

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.