I have a chat app with a floating composer pill (NSGlassEffectView) pinned to the bottom of my content area. Messages scroll behind it. The pill looks fine but content behind it is completely clear. Fully legible text showing through, no frosting at all. Mail, Messages, Notes all have this frosted look where content behind a floating bar is blurred enough that you can't read it. That's what I'm going for. My scroll view has wantsLayer = true. I tried hasVerticalScroller = true + scrollerStyle = .overlay based on a tip I saw in another thread. No change. Is NSGlassEffectView supposed to blur what's behind it, or is the frosting in Apple's apps coming from the scroll edge effect? If it's the scroll edge effect, is there any way to trigger it for a custom floating view at the bottom of a scroll view? I can't find any AppKit API for this. I also spent time trying this in SwiftUI using .glassEffect() on macOS. Same result, the material renders nearly clear with no way to control the frosting level via any public API. If I'm missing something obvious I'd love to know. I've been stuck on this one for a while. Thanks for any advice! I've attached photos of my input bar (clearly transparent) and Apple Messages, which has a style that I see all over iOS and Mac OS 26.

The following code only ever causes shouldDrawInsertionPoint to be printed (no drawInsertionPoint), but even if that method returns false, the blinking insertion point is still drawn. On the other hand, with TextKit 1 it works as expected. Is there a way to hide the default insertion point in TextKit 2? My app draws its own. I've filed FB13684251. class TextView: NSTextView { override var shouldDrawInsertionPoint: Bool { print("shouldDrawInsertionPoint") return false } override func drawInsertionPoint(in rect: NSRect, color: NSColor, turnedOn flag: Bool) { print("drawInsertionPoint", flag) } } ``

I probably should know the answer to this but I don't, so I'll ask. When I enable state restoration and have like three windows open, and I quit the app (via Quit menu, not 'Stop In Xcode') the following happens: -NSApplication calls _closeForTermination on all the windows and this causes state restoration to fail to restore these open windows on next app launch. This behavior is not aligned with the behavior of apps like Mail. If I have two "Viewer Windows" open in Mail and I quit the app, when I relaunch the two viewer windows are restored. I can of course track this and write data to restore for these auto closed window myself but shouldn't there be an easy way to opt in to this behavior?

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 am using NSSearchField for a non-incremental search UI. The field is configured as follows: let searchField = NSSearchField() searchField.sendsSearchStringImmediately = false searchField.sendsWholeSearchString = true searchField.target = target searchField.action = #selector(submit(_:)) My expectation is that the action is sent only when the user explicitly commits the search, such as by pressing Return or clicking the search button. I understand that clicking the cancel button inside the NSSearchField clears the text and sends the action with an empty string. That behavior is documented and makes sense. However, I am also seeing the action sent when the user edits the text normally and deletes the last character, causing the search field’s stringValue to become empty. In other words, while the user is just editing the field with the Delete key, the action is sent even though the user did not press Return or explicitly commit the search. Is this expected behavior for NSSearchField, or is it a bug? If it is expected, is there a recommended public API to distinguish these cases? User pressed Return with a non-empty string User clicked the search/cancel button User simply edited the text and the string became empty I would like to keep using NSSearchField’s built-in recent searches behavior, so intercepting Return with control(_:textView:doCommandBy:) is not ideal. If this is not expected behavior, I will file Feedback with a sample project. Environment: macOS 26.5 (25F71) Xcode 26.5 (17F42)

After updating to Sonoma, the following is logged in the Xcode console when an editable text field becomes key. This doesn't occur on any text field, but it seems to happen when the text field is within an NSPopover or an NSSavePanel. ViewBridge to RemoteViewService Terminated: Error Domain=com.apple.ViewBridge Code=18 "(null)" UserInfo={com.apple.ViewBridge.error.hint=this process disconnected remote view controller -- benign unless unexpected, com.apple.ViewBridge.error.description=NSViewBridgeErrorCanceled} What does this mean?

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?

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.

Hi, I've been trying to resolve an issue that my users are facing for about one year, but I haven't been able to so far. That's why I'm turning to you all for some ideas. Some of my users have noticed that my app suddenly exits. It runs in the background as a menu bar app, so when they go to use it, they realize it's no longer running. I've checked Crashlytics and asked users to check their Console app for crash reports, but there are none. The conclusion so far is that it's not a crash, but a silent termination. I haven't experienced this on my own machine, which makes it incredibly difficult to debug or identify the cause. Recently, I thought I'd pinned down the problem. My app was declaring: <key>NSSupportsSuddenTermination</key> <true/> Based on the documentation, this is intended to quickly terminate the app during logout or system shutdown, but I read it can also be triggered when the system needs resources. It seemed like the perfect root cause. However, even after turning it off, one of my users is still experiencing the problem. I'm officially running out of ideas. Does anyone have suggestions on what else I should check? My app currently declares: <key>LSUIElement</key> <true/> <key>NSSupportsAutomaticTermination</key> <false/> <key>NSSupportsSuddenTermination</key> <false/>

Hi, I’m pretty new to AppKit and I’m trying to make an NSTextField inside an NSTableView both: Editable Multi-line / wrapping Right now, wrapping works fine until I set: tf.isEditable = true Then the text becomes a single line. How do I make it editable while still wrapping correctly? import AppKit final class ViewController: NSViewController, NSTableViewDataSource, NSTableViewDelegate { let tableView = NSTableView() let text = String(repeating: "A", count: 500) override func viewDidLoad() { super.viewDidLoad() view = tableView tableView.addTableColumn(NSTableColumn()) tableView.usesAutomaticRowHeights = true tableView.dataSource = self tableView.delegate = self } func numberOfRows(in tableView: NSTableView) -> Int { 1 } func tableView(_ tableView: NSTableView, viewFor tableColumn: NSTableColumn?, row: Int) -> NSView? { let cell = NSTableCellView() let tf = NSTextField(wrappingLabelWithString: text) tf.lineBreakMode = .byCharWrapping if let tableColumn { tf.preferredMaxLayoutWidth = tableColumn.width } tf.isEditable = true // comment this out and wrapping works cell.addSubview(tf) tf.translatesAutoresizingMaskIntoConstraints = false NSLayoutConstraint.activate([ tf.leadingAnchor.constraint(equalTo: cell.leadingAnchor), tf.trailingAnchor.constraint(equalTo: cell.trailingAnchor), tf.topAnchor.constraint(equalTo: cell.topAnchor), tf.bottomAnchor.constraint(equalTo: cell.bottomAnchor), ]) return cell } }

So in NSCollectionView I left click the background and start dragging to make the 'selection box' (is that what we call it?) I have a mouse with separate left and right click buttons (i.e., not an Apple Magic Mouse). Now if I accidentally hit the right click while I'm still dragging the selection box..... the right click context menu shows up in the middle of mouse dragging and the selection box freezes on screen. Besides the visual disruption this sometimes results in weird behavior. Sometimes mouse clicks stop responding for awhile in the window and I gotta click around a bunch of times until I guess the run loop "unclogs." I'm able to reproduce in Finder Icon view so it isn't just me. Steps to Reproduce: A mouse with separate buttons for left and right click. Open Finder window in icon view. Left click the background and start dragging to make the gray selection box. While dragging the mouse as you are selecting click right-click in the middle of the drag. The selection box freezes on screen. Expected Behavior: -Right click event and left mouse drag event normally shouldn't overlap. If left mouse is being dragged the right click event should be blocked. Let me know if this is Feedback worthy.

Is it possible to remove the ugly sidebar and inspector chrome with AppKit? I don't care if it's a hack or a swizzle or something, but I need to get rid of this. I want to convert this: Into this (photoshopped): Thanks for your help!

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

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.

We are currently testing our application under macOS 26 in Liquid Glass mode and noticed an issue with NSSegmentedCell. Our app makes extensive use of NSCell-based drawing. Since macOS 26, when running in Liquid Glass mode, NSSegmentedCell does not render at the expected location. The control itself appears visually correct, but it is clearly drawn offset from the rect it is supposed to occupy. In compatibility mode, everything renders exactly as expected (same code, same layout). To illustrate the issue, here are two screenshots of the same view: Liquid Glass mode 👉 (screenshot 1 – segmented control visibly shifted) Compatibility mode 👉 (screenshot 2 – correct rendering) The regression is obvious when switching between the two modes. This behavior has been present since the first macOS 26 release and is still reproducible with Xcode 26.2 (17C52). I have already filed a report via Feedback Assistant (FB reference available if useful), but I’m posting here to see whether others are experiencing the same issue or have found a workaround. Thanks.

When I add a simple menu to the dock via the NSApplicationDelegate method -applicationDockMenu: and run the app from Xcode it doesn't work. -(NSMenu*)applicationDockMenu:(NSApplication*)sender { NSMenu *dockMenu = [self buildDockMenu]; if (dockMenu != nil) { NSLog(@"Returning dock menu."); return dockMenu; } else { NSLog(@"Not ready to build dock menu"); return nil; } } When I run the app, my main app window shows up but nothing logs out in -applicationDockMenu: until I click outside my app's window (so if I click the desktop background, or a Finder window, or whatever). Then after I click outside my app's main window this logs out: Returning dock menu. The "Not ready to build dock menu" message does not log out. But...when I right click on the dock icon, the menu doesn't show up. But if I stop the app from Xcode and just run it not attached to the debugger, the dock menu does show up. But this makes the debugging/testing situation not ideal.

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.

I have (had) a view controller that does a bit of manual layout in a -viewDidLayout override. This was pretty easy to manage - however since introducing NSGlassEffectView into the view hierarchy I sometimes am getting hit with "Unable to simultaneously satisfy constraints" and Appkit would break a constraint to 'recover.' It appears translatesAutoresizingMaskIntoConstraints is creating some really weird fixed width and height constraints. Here I wasn't doing any autolayout - just add the glass view and set its frame in -viewDidLayout. At runtime since I do manual layout in -viewDidLayout the frames are fixed and there is no real "error" in my app in practice though I wanted to get rid of the constraint breaking warning being logged because I know Autolayout can be aggressive about 'correctness' who knows if they decide to throw and not catch in the future. In my perfect world I would probably just prefer a view.doesManualLayout = YES here - the subviews are big containers no labels so localization is not an issue for me. Rather than playing with autoresizing masks to get better translated constraints I decided to set translatesAutoresizingMaskIntoConstraints to NO and make the constraints myself. Now I get hit with the following exception: "The window has been marked as needing another Layout Window pass, but it has already had more Layout Window passes than there are views in the window" So this happens because the view which now has constraints -- I adjusted the frame of it one point in -viewDidLayout. My question is - is not legal to make changes in -viewDidLayout - which seems like the AppKit version of -viewDidLayoutSubviews. In UIKit I always thought it was fine to make changes in -viewDidLayoutSubviews to frames - even if constraints were used - this is a place where you could override things in complex layouts that cannot be easily described in constraints. But in AppKit if you touch certain frames in -viewDidLayout it can now cause this exception (also related: https://developer.apple.com/forums/thread/806471) I will change the constant of one of the constraints to account for the 1 point adjustment but my question still stands - is it not legal to touch frames in -viewDidLayout when autolayout constraints are used on that subview? It is (or at least was if I remember correctly) permitted to change the layout in -viewDidLayoutSubviews in UIKit but AppKit seems to be more aggressive in its checking for layout correctness). What about calling -sizeToFit on a control in viewDidLayout or some method that has side effect of invalidating layout in a non obvious way, is doing things like this now 'dangerous?' Shouldn't AppKit just block the layout from being invalidated from within -viewDidLayout - and leave whatever the layout is as is when viewDidLayout returns (thus making -viewDidLayout a useful place to override layout in the rare cases where you need a sledgehammer?)

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.

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?