Construct and manage a graphical, event-driven user interface for your macOS app using AppKit.

Posts under AppKit tag

187 Posts

Post

Replies

Boosts

Views

Activity

How do I make an editable NSTextField wrap inside an NSTableView cell?
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 } }
4
0
154
12h
SwiftUI + AppKit context menu wedges window-level mouse events when the menu's anchor view is deleted by the menu's own action
I'm on macOS 26.4 (SwiftUI + SwiftData + AppKit bridging). I have a SwiftUI canvas where each child view (a card) carries a per-card AppKit context menu via an NSViewRepresentable overlay (a small NSView subclass that overrides menu(for:) and returns an NSMenu whose items invoke a Swift closure). The closure for the "Delete" item removes the underlying model object. SwiftData mutates → SwiftUI re-emits the canvas → the card containing the menu's anchor NSView unmounts → that anchor NSView is removed from the AppKit view hierarchy. After this happens, the entire window's SwiftUI gestures stop receiving mouse events: pan, zoom, taps on a separate background Color view all go silent. The window's first responder ends up at the NSWindow itself. The wedge persists across switching to a sibling SwiftUI view in the same window (different SwiftData root), so the bad state is at the window/event-routing level, not in any one SwiftUI subtree. The wedge is reliably cleared by another right-click that successfully shows + dismisses any menu — strongly suggesting AppKit's menu/event-tracking cleanup is left in a half-finished state because the anchor view went away during the cleanup window. I've already verified: Switching from explicit NSMenu.popUpContextMenu(_:with:for:) to overriding menu(for:) does not change the behavior. Deferring the model deletion via DispatchQueue.main.async, asyncAfter (30 ms), or RunLoop.main.perform(inModes: [.default]) either doesn't help or only avoids the wedge if the delay is long enough to be perceptible (seconds), implying the cleanup window is event-driven, not time-driven. Triggering the same deletion from a SwiftUI Button (no AppKit menu involved) never wedges. My current understanding is that the standard AppKit pattern (e.g., NSTableView, NSOutlineView) attaches the context menu to a stable parent view, never to the per-row view itself, precisely so the menu's anchor outlives any single row's deletion. Restructuring my code so a single canvas-level AppKitContextMenuRegion returns the appropriate menu via hit-testing in menu(for:) should avoid the issue, but I'd like to confirm: Is the assumption that an NSMenu's anchor view must outlive the menu's tracking-end cleanup documented anywhere, or is it implicit? Is there a supported way to safely use a per-row anchor view that gets deleted by the menu's own action, or is the canvas-level / parent-level menu attachment the only correct pattern? 3. Are there any post-tracking notifications or APIs that guarantee AppKit's cleanup is complete before the anchor view is allowed to be torn down (so a per-row anchor could be made safe with the right ordering)? Thanks!
0
0
271
3d
NSCollectionView's 'selection box' freezes if you right-click during dragging
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.
5
0
62
6d
How can I reliably get the final restored window size on macOS when onAppear / viewDidAppear fires too early?
I’m running into a macOS window restoration behavior issue where viewDidAppear (AppKit) or onAppear (SwiftUI) fires before the window’s final restored size is applied. AppKit example class MyViewController: NSViewController { override func viewDidLayout() { print("viewDidLayout: \(view.bounds.size)") } override func viewDidAppear() { print("viewDidAppear: \(view.bounds.size)") } } Logs on launch: viewDidAppear: (480.0, 270.0) viewDidLayout: (480.0, 270.0) viewDidLayout: (556.0, 476.0) viewDidLayout: (556.0, 476.0) The correct restored size is (556.0, 476.0), but viewDidAppear initially reports the old default size (480.0, 270.0). SwiftUI equivalent struct MyView: View { var body: some View { GeometryReader { geo in VStack {} .onAppear { print("onAppear: \(geo.size)") } .onChange(of: geo.size) { print("onChange: \(geo.size)") } } } } Logs on launch: onAppear: (900.0, 450.0) onChange: (680.0, 658.0) Problem I need to run some setup code: Only once After the view/window has its correct restored size Without rerunning on every layout or geometry change Question What is the proper macOS-native way to perform one-time startup logic only after the final restored window size is available? Is there a recommended lifecycle hook or pattern for this? Also, is it expected behavior that onAppear / viewDidAppear reports the pre-restoration size, or is it a bug?
3
0
192
1w
ScrollView/ClipView weirdness.
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.
Topic: UI Frameworks SubTopic: AppKit Tags:
1
0
248
1w
After binding to NSBrowser indexPaths the browser assumes I'm using NSBrowserCell and calls unimplemented methods on my NSCell subclass
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.
0
0
94
1w
NSTextView.shouldDrawInsertionPoint doesn't work with TextKit 2
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) } } ``
Topic: UI Frameworks SubTopic: AppKit Tags:
10
0
316
2w
macOS main.swift and Main actor-isolated conformance cannot be used in nonisolated context
For a simple, resourceless cocoa apps I used to manually setup the application lifecycle (mimicking what's documented here: https://developer.apple.com/documentation/appkit/nsapplication), so my main.swift would look like: import Cocoa let delegate = SomeDelegate() _ = NSApplication.shared NSApp.delegate = delegate NSApp.run() This triggers a warning in Xcode 26.2: "Main actor-isolated conformance of SomeDelegate cannot be used in nonisolated context; this is an error in Swift 6 language mode". so what is the recommended way to refactor above so that it is Swift 6 compliant?
1
0
833
3w
-applicationDockMenu: method on NSApplicationDelegate doesn't work when attached to debugger
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.
4
0
286
3w
NSOutlineView / NSTableView's Setting lineScroll to a somewhat absurd value of 304 in -tile
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.
1
0
261
3w
AppKit - Legal to Change a View's Frame in -viewDidLayout?
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?)
4
0
575
3w
macOS 26: NSTokenField crashes due to NSGenericException caused by too many Update Constraints
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.
5
1
495
3w
NSWritingToolsCoordinator issue with text replacement
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.
1
0
317
Apr ’26
NSWritingToolsCoordinator issue with text replacement
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.
1
0
308
Apr ’26
Document Based App - NSDocumentController Opening the Wrong NSDocument/Window Controller on Tahoe 26.4
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.
1
0
81
Apr ’26
Layout recursion error message
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!
10
0
727
Apr ’26
macOS Tahoe 26.3 - System Is Playing NSBeep At Inappropriate Times When Text Editing Ends Via -cancelOperation: (field editor)
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:] ()
4
0
165
Apr ’26
How do I make an editable NSTextField wrap inside an NSTableView cell?
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 } }
Replies
4
Boosts
0
Views
154
Activity
12h
SwiftUI + AppKit context menu wedges window-level mouse events when the menu's anchor view is deleted by the menu's own action
I'm on macOS 26.4 (SwiftUI + SwiftData + AppKit bridging). I have a SwiftUI canvas where each child view (a card) carries a per-card AppKit context menu via an NSViewRepresentable overlay (a small NSView subclass that overrides menu(for:) and returns an NSMenu whose items invoke a Swift closure). The closure for the "Delete" item removes the underlying model object. SwiftData mutates → SwiftUI re-emits the canvas → the card containing the menu's anchor NSView unmounts → that anchor NSView is removed from the AppKit view hierarchy. After this happens, the entire window's SwiftUI gestures stop receiving mouse events: pan, zoom, taps on a separate background Color view all go silent. The window's first responder ends up at the NSWindow itself. The wedge persists across switching to a sibling SwiftUI view in the same window (different SwiftData root), so the bad state is at the window/event-routing level, not in any one SwiftUI subtree. The wedge is reliably cleared by another right-click that successfully shows + dismisses any menu — strongly suggesting AppKit's menu/event-tracking cleanup is left in a half-finished state because the anchor view went away during the cleanup window. I've already verified: Switching from explicit NSMenu.popUpContextMenu(_:with:for:) to overriding menu(for:) does not change the behavior. Deferring the model deletion via DispatchQueue.main.async, asyncAfter (30 ms), or RunLoop.main.perform(inModes: [.default]) either doesn't help or only avoids the wedge if the delay is long enough to be perceptible (seconds), implying the cleanup window is event-driven, not time-driven. Triggering the same deletion from a SwiftUI Button (no AppKit menu involved) never wedges. My current understanding is that the standard AppKit pattern (e.g., NSTableView, NSOutlineView) attaches the context menu to a stable parent view, never to the per-row view itself, precisely so the menu's anchor outlives any single row's deletion. Restructuring my code so a single canvas-level AppKitContextMenuRegion returns the appropriate menu via hit-testing in menu(for:) should avoid the issue, but I'd like to confirm: Is the assumption that an NSMenu's anchor view must outlive the menu's tracking-end cleanup documented anywhere, or is it implicit? Is there a supported way to safely use a per-row anchor view that gets deleted by the menu's own action, or is the canvas-level / parent-level menu attachment the only correct pattern? 3. Are there any post-tracking notifications or APIs that guarantee AppKit's cleanup is complete before the anchor view is allowed to be torn down (so a per-row anchor could be made safe with the right ordering)? Thanks!
Replies
0
Boosts
0
Views
271
Activity
3d
NSCollectionView's 'selection box' freezes if you right-click during dragging
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.
Replies
5
Boosts
0
Views
62
Activity
6d
.icon files and "imageNamed:"
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!
Replies
1
Boosts
0
Views
133
Activity
6d
Remove MacOS Tahoe Sidebar + Inspector Chrome
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!
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
0
Boosts
0
Views
86
Activity
1w
How can I reliably get the final restored window size on macOS when onAppear / viewDidAppear fires too early?
I’m running into a macOS window restoration behavior issue where viewDidAppear (AppKit) or onAppear (SwiftUI) fires before the window’s final restored size is applied. AppKit example class MyViewController: NSViewController { override func viewDidLayout() { print("viewDidLayout: \(view.bounds.size)") } override func viewDidAppear() { print("viewDidAppear: \(view.bounds.size)") } } Logs on launch: viewDidAppear: (480.0, 270.0) viewDidLayout: (480.0, 270.0) viewDidLayout: (556.0, 476.0) viewDidLayout: (556.0, 476.0) The correct restored size is (556.0, 476.0), but viewDidAppear initially reports the old default size (480.0, 270.0). SwiftUI equivalent struct MyView: View { var body: some View { GeometryReader { geo in VStack {} .onAppear { print("onAppear: \(geo.size)") } .onChange(of: geo.size) { print("onChange: \(geo.size)") } } } } Logs on launch: onAppear: (900.0, 450.0) onChange: (680.0, 658.0) Problem I need to run some setup code: Only once After the view/window has its correct restored size Without rerunning on every layout or geometry change Question What is the proper macOS-native way to perform one-time startup logic only after the final restored window size is available? Is there a recommended lifecycle hook or pattern for this? Also, is it expected behavior that onAppear / viewDidAppear reports the pre-restoration size, or is it a bug?
Replies
3
Boosts
0
Views
192
Activity
1w
ScrollView/ClipView weirdness.
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.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
1
Boosts
0
Views
248
Activity
1w
After binding to NSBrowser indexPaths the browser assumes I'm using NSBrowserCell and calls unimplemented methods on my NSCell subclass
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.
Replies
0
Boosts
0
Views
94
Activity
1w
NSTextView.shouldDrawInsertionPoint doesn't work with TextKit 2
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) } } ``
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
10
Boosts
0
Views
316
Activity
2w
macOS main.swift and Main actor-isolated conformance cannot be used in nonisolated context
For a simple, resourceless cocoa apps I used to manually setup the application lifecycle (mimicking what's documented here: https://developer.apple.com/documentation/appkit/nsapplication), so my main.swift would look like: import Cocoa let delegate = SomeDelegate() _ = NSApplication.shared NSApp.delegate = delegate NSApp.run() This triggers a warning in Xcode 26.2: "Main actor-isolated conformance of SomeDelegate cannot be used in nonisolated context; this is an error in Swift 6 language mode". so what is the recommended way to refactor above so that it is Swift 6 compliant?
Replies
1
Boosts
0
Views
833
Activity
3w
-applicationDockMenu: method on NSApplicationDelegate doesn't work when attached to debugger
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.
Replies
4
Boosts
0
Views
286
Activity
3w
NSOutlineView / NSTableView's Setting lineScroll to a somewhat absurd value of 304 in -tile
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.
Replies
1
Boosts
0
Views
261
Activity
3w
AppKit - Legal to Change a View's Frame in -viewDidLayout?
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?)
Replies
4
Boosts
0
Views
575
Activity
3w
macOS 26: NSTokenField crashes due to NSGenericException caused by too many Update Constraints
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.
Replies
5
Boosts
1
Views
495
Activity
3w
How to let Appkit Scrollview get under sidebar or inspctor?
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?
Replies
1
Boosts
0
Views
75
Activity
Apr ’26
NSWritingToolsCoordinator issue with text replacement
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.
Replies
1
Boosts
0
Views
317
Activity
Apr ’26
NSWritingToolsCoordinator issue with text replacement
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.
Replies
1
Boosts
0
Views
308
Activity
Apr ’26
Document Based App - NSDocumentController Opening the Wrong NSDocument/Window Controller on Tahoe 26.4
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.
Replies
1
Boosts
0
Views
81
Activity
Apr ’26
Layout recursion error message
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!
Replies
10
Boosts
0
Views
727
Activity
Apr ’26
macOS Tahoe 26.3 - System Is Playing NSBeep At Inappropriate Times When Text Editing Ends Via -cancelOperation: (field editor)
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:] ()
Replies
4
Boosts
0
Views
165
Activity
Apr ’26