I have been playing around with AppKit programming and I have a sample document based app with a scroll view and rulers. When The scrollbars are not overlay style (which is usually true for me because I have "show scroll bars always" set in preferences) and the rulers are on The clip view seems to extend throughout the scroll view and the document can be seen through the scroll bars. However if I turn the rulers off, then the clip view seems to not include the scroll bars, and so the document is not visible through the scroll bars, having been clipped to the rectangle that lies inside the scroll bars. Additionally in this case, the small area in the lower right hand corner of the screen between the two scroll bars is white, even though all of my views have a light gray background. If the scroll bar style is overlay, then everything seems to work as expected: the clip view always includes the scroll bars. Is this a bug related to legacy style scrollbars or (more likely) have I just screwed something up? I should add that the window and the entire view hierarchy have been built programmatically. It is not in the xib.

My application overrides AppDelegate.menuWillOpen(). During startup of the application (in AppDelegate.applicationDidFinishLaunching) I attempt to install a privileged helper tool using SMAppService. On detecting that the tool needs to be allowed/installed I open the Login Items & Extensions settings and then display a modal dialog, advising the user to authorise the privileged helper. Then the application crashes with a message in the crash file Application Specific Information: BUG IN CLIENT OF LIBDISPATCH: trying to lock recursively Maybe I could avoid this by removing the menuWillOpen() override so am looking for a workaround. i.e. is it possible to install the override function programmatically later during initialisation, rather then declaring it in an extension. I have attached the crash log. ChronyControl-2026-04-29-111332.crash

So after binding to NSBrowser selectionIndexPaths: https://developer.apple.com/library/archive/documentation/Cocoa/Reference/CocoaBindingsRef/BindingsText/NSBrowser.html this causes NSBrowser to do some weird stuff that seems completely unrelated to this particular binding. It starts calling NSBrowserCell methods on my cells but my cell is not a NSBrowserCell. My cell is actually a subclass of NSTextFieldCell. But NSBrowser starts sending setIsLeaf: (which I don't implement). In any case if I implement the -setLeaf: that solves that unrecognized selector, but now my cells don't draw titles. Not sure why binding to selectionIndexPaths causes this behavior? The cell stuff seems unrelated to this particular binding. I am of course using the newer but still pretty old item based APIs... do these bindings only support using NSMatrix? I do set the binding after calling -setCellClass: but makes no difference. I also just tried overriding -setSelectionIndexPaths: but NSBrowser does not use the setter.

I using SwiftUI to wrap a NSTextView to support rich text editing. I created a subclass ImageAttachment and provided my own viewProvider and attachmentView. The insertion of the image works fine, but when I typing in the same paragraph of the image, the image will flicker during typing and pause. after typing it sometimes just display nothing, but after refresh or click other places, the image shows. The interesting part is if I typing in other paragraph, the image attachment displays well. I don't think the flicker should happen while typing in the same paragraph of the attachment, but not sure if there is a way to enforce the layout stable for the paragraph?

So I'm working on adding another component to my app that uses NSOutlineView, as we do in AppKit. There will probably always be less than 25 rows here. One row is much larger than the others. Not sure if any of this matters. What I know is I noticed scrolling it is very jank. It's going way too fast. So I took a peek and see lineScroll is getting is 304 in Interface Builder. Not sure how that happened. I changed it to like 24. Then Interface Builder automatically changes it back to 304. So in -viewDidLoad I just set it: NSScrollView *scrollView = self.outlineView.enclosingScrollView; scrollView.verticalLineScroll = 24.0; scrollView.lineScroll = 24.0; But scrolling still is busted. So I subclass NSScrollView and override the setters. For some reason, NSTableView's -tile method is deciding to change the lineScroll to 304, all on its own. So every time tile is called. line scrolls get reset to 304.

import Cocoa class RedRotatedView: NSView { override func viewDidMoveToSuperview() { super.viewDidMoveToSuperview() DispatchQueue.main.async { self.applyRotation() } } private func applyRotation() { wantsLayer = true layer?.backgroundColor = NSColor.red.cgColor let radians = CGFloat(30 * Double.pi / 180.0) self.layer?.transform = CATransform3DMakeRotation(radians, 0, 0, 1) } override func layout() { super.layout() } } class MainView: NSView { let redView: RedRotatedView override init(frame frameRect: NSRect) { self.redView = RedRotatedView() super.init(frame: frameRect) setupRedView() } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } private func setupRedView() { redView.wantsLayer = true redView.layer?.backgroundColor = NSColor.red.cgColor addSubview(redView) redView.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ redView.centerXAnchor.constraint(equalTo: centerXAnchor), redView.centerYAnchor.constraint(equalTo: centerYAnchor), redView.widthAnchor.constraint(equalToConstant: 200), redView.heightAnchor.constraint(equalToConstant: 200) ]) // redView.frame = NSRect(x:100,y:100,width: 200,height: 200) } } @main struct AppKitRotationTestApp { static func main() { let app = NSApplication.shared let delegate = AppDelegate() app.delegate = delegate app.run() } } class AppDelegate: NSObject, NSApplicationDelegate { var window: NSWindow! func applicationDidFinishLaunching(_ aNotification: Notification) { let mainView = MainView(frame: NSRect(x: 0, y: 0, width: 800, height: 600)) window = NSWindow( contentRect: NSRect(x: 0, y: 0, width: 800, height: 600), styleMask: [.titled, .closable, .resizable, .miniaturizable], backing: .buffered, defer: false ) window.center() window.title = "AppKit Rotation Test" window.contentView = mainView window.makeKeyAndOrderFront(nil) } func applicationWillTerminate(_ aNotification: Notification) { } func applicationSupportsSecureRestorableState(_ app: NSApplication) -> Bool { return true } } If NSLayoutConstraint is not used directly and the NSView's frame is set directly, this situation does not occur. How can I avoid the transform being reset when using NSLayoutConstraint for layout?

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?

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.

I have been using this block of Swift code for weeks with no problems. Then, today, every time I invoke it it fails: let openPanel = NSOpenPanel() openPanel.canChooseFiles = true openPanel.allowsMultipleSelection = false openPanel.canChooseDirectories = true openPanel.canCreateDirectories = false openPanel.title = NSLocalizedString("Open a CSV file", comment: "Open a CSV File") var result = NSApplication.ModalResponse.OK do { try result = openPanel.runModal() } catch { print("Open Panel failed: \(error)") return } if result == .OK { CSVFile = openPanel.url!.path } else { openPanel.close() print("No CSV file selected.") return } I get this message pointing to the .openModal expression: "Thread 1: Fatal error: Unexpectedly found nil while unwrapping an Optional value" It's a real head-scratcher!

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.

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)

These days I've observed a strange behavior in my document-based app on macOS: Its NSDocument class implementation is overwriting "saveToURL:ofType:forSaveOperation:completionHandler:", performing some additional checks and calling super by passing the original parameters. As my app is supporting various file formats for writing (and exporting those UTIs) the user can open a file in one format and save it to another. NSDocument is calling the mentioned methods implicitly after completing the "Save as..." dialog. If this happens, the passed-on fileType is still the one of format #1, although the file is saved with the file name extension of format #2. This hick-up is not directly obvious to the user. But if the file is re-saved (e.g. after modifications), Cocoa is trying to extend the sandbox for the URL of type #1, and fails with the following error message at the Xcode console: -[STBDocument saveToURL:ofType:forSaveOperation:completionHandler:] [Line 521] typeName: com.janome.jef -[STBDocument saveToURL:ofType:forSaveOperation:completionHandler:] [Line 523] targetTypeUTI: com.tajima.dst NSFileSandboxingRequestRelatedItemExtension: Failed to issue extension for /Users/matthias/Desktop/Ohne Titel.jef because: Error Domain=NSPOSIXErrorDomain Code=3 "No such process" -[NSFileCoordinator itemAtURL:willMoveToURL:] could not get a sandbox extension. oldURL: file:///Users/matthias/Desktop/Ohne%20Titel.dst, newURL: file:///Users/matthias/Desktop/Ohne%20Titel.jef I'm currently fixing this issue by determining the UTType for the new file name extension and passing it to super. Unfortunately I have no idea how long this issue was already present, and cannot replicate it with a sample app based on Apple's Xcode 26 template (too many differences to my >15 years old app) - so I won't file a bug report. Take this post just for information in case someone else is facing a similar situation...

I published the latest update of my AppKit app in September with macOS 26.0. I just wanted to create a new update, but compiling on macOS 26.4 now fails because of the symbol NSTextAttachment.character which is referenced in my code. The error is Type 'NSTextAttachment' has no member 'character' I've never experienced before that a symbol suddenly is not available anymore without even a deprecation notice from one OS release to the next, let alone a minor release. Is this a bug in macOS or Xcode, or should I start worrying about symbols becoming unavailable anytime?

I'm building a document viewer on macOS Tahoe with a 3-column NSSplitViewController (sidebar | detail | inspector), trying to replicate how Preview displays PDFs with the page centered in the visible gap between the panels, with content bleeding under them when panning or zooming. I'm using the approach from Build an AppKit app with the new design (WWDC25): detailItem.automaticallyAdjustsSafeAreaInsets = true safeAreaInsets reports the correct values (e.g. left: 208, right: 240), and the frame does extend under both panels. But PDFView with autoScales = true anchors the page to the left edge of the window instead of centering it in the visible gap between the sidebar and inspector. I can get the page to center correctly by constraining PDFView to view.safeAreaLayoutGuide, but then content no longer extends under the panels when panning or zooming, which defeats the whole purpose. What's the correct way to center PDFView content within the visible gap while keeping the frame full-width so content bleeds under the panels? I've attached pictures of how Preview does it.

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.

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:

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.