I have an NSTableView used as a source list and, alongside it, two editors. When the user selects anything in the table view, its content is opened in the editor that has the focus. When the user Opt-clicks an item in the table, though, the content is opened in the other editor, making it easy for the user to load something in the other editor without having to change the focus first. This has worked for many years using NSTableView.selectiondDidChange / the NSTableViewDelegate as follows: func tableViewSelectionDidChange(_ notification: Notification) { if let event = tableView.window?.currentEvent, event.type == .leftMouseUp || event.type == .leftMouseDown, // (Real app does some other checks here too.) event.modifierFlags.contains(.option) { openInOtherEditor() return } openInCurrentEditor() } However, on macOS 27, it seems that things need to be done differently because of the transition to gesture recognisers for event handling. According to the WWDC video "Modernise Your AppKit App", and to Tech Note TN3212, currentEvent can no longer be relied upon to provide the event that actually triggered an action in NSControl subclasses: The transition to gesture recognizers on NSControl objects changes the timing of when AppKit delivers control action messages with respect to event processing. As a result, currentEvent no longer returns the event that triggered an action. It's unclear whether this new limitation refers only to NSControl.action or to all mouse-driven actions, but from the context and what the rest of the Tech Note has to say, I assume it's the latter. (Especially since you are no longer supposed to override mouseDown(with:), and the Console warns about gestures being disabled if you do override mouseDown(with:) in an NSTableView subclass on macOS 27.) currentEvent still seems to work fine in this situation in the first macOS 27 beta, but it sounds as though we cannot rely on this continuing to be the case. If we should no longer be using currentEvent, then, what should we use instead to determine whether a selection change was triggered by a mouse click? The Tech Note and WWDC video have nothing to say about this. They simply say that instead of overriding mouseDown(with:), you should use the selection-did-change delegate methods, which is of no help here. (By contrast, checking the modifier flags is still straightforward; the Tech Note says to use NSEvent.modifierFlags instead of currentEvent.modifierFlags.) Two solutions sprung to mind, but neither worked: Check tableView.clickedRow != -1 in the selectionDidChange delegate method/notification response. This doesn't work, however, because clickedRow has been reset to -1 by the time NSTableView.selectionDidChange is sent. Add an action to the table view and check clickedRow there. This doesn't work either, though, because although clickedRow is available in the action method, I would now have to load content in response to both an action and a selection change, and since the selection changes before the action is called, there is no way of telling my selection-did-change method not to load in the main editor if Option is held down in the action. The only solution I have found is to override selectRowIndexes(_:byExtendingSelection:), check for clickedRow != -1 there, set a didChangeSelectionWithMouse flag to true if so, and check that in the selection-did-change delegate method. That works, but it's not the most elegant of solutions. So: Am I misunderstanding the Tech Note? Can currentEvent still in fact be used safely in tableViewSelectionDidChange(_:) in macOS 27 and beyond? If not, what is the recommended way of checking that the table selection has been changed by a mouse click? Many thanks!

It seems this method is not updated for the new "Show on all Spaces" option in system wallpaper preferences. I encounter this problem because one customer reported that every time my app sets a new wallpaper, this option is turned off. NSDictionary* options = [SHARED_WORKSPACE desktopImageOptionsForScreen:screen]; [SHARED_WORKSPACE setDesktopImageURL:imageFileURL forScreen:screen options:options error:&error]; This can be easily verified by dumping the returned dictionary - which only contains 3 keys. Is this a known bug?

We're using IKPictureTaker to let users pick a room avatar image. The flow worked correctly on macOS 13–15, but breaks on macOS 26 (Tahoe). Symptoms popUpRecentsMenu(for:withDelegate:didEnd:contextInfo:) — no UI appears at all, and the didEnd selector is never called runModal() — a window appears but its content is completely blank (empty gray rectangle). The app freezes until the user force-quits Minimal reproduction import Quartz let pictureTaker = IKPictureTaker.pictureTaker() pictureTaker?.setCommonValuesForKeys(allowsVideoCapture: true) // Attempt 1 — silent fail, no UI, no callback pictureTaker?.popUpRecentsMenu(for: someButton, withDelegate: self, didEnd: #selector(pictureTakerDidEnd), contextInfo: nil) // Attempt 2 — window appears but content is blank let result = pictureTaker?.runModal() // result is never returned while window is visible; app is frozen Environment macOS 26.0 (Tahoe) — reproducible by QA on multiple machines Xcode 16, Swift 5, deployment target macOS 10.14 Camera permission granted (AVAuthorizationStatus.authorized) App is sandboxed What I've ruled out Camera permission is authorized before the call The view passed to popUpRecentsMenu has a valid, visible, key window Same code works on macOS 13, 14, 15 Question Is this a known regression in macOS 26? Is IKPictureTaker expected to stop working, or is there a required entitlement / initialization step that changed? If the API is effectively unsupported, is NSOpenPanel with allowedContentTypes: [.image] the recommended migration path?

I'm trying to use NSTokenField for the first time. So my custom 'representedObject' for a token has additional model data tied to it (not just the editing/display string). I noticed when I edit an existing token, type text, and hit the enter key I get the following delegate callback: - (nullable id)tokenField:(NSTokenField *)tokenField representedObjectForEditingString:(NSString *)editingString; This same delegate method is called when I type a brand new token. Is there a way to distinguish if I'm editing a token vs. creating a new one? My expectation is to be able to do something like this (made up enhancement): - (nullable id)tokenField:(NSTokenField *)tokenField representedObjectForEditingString:(NSString *)editingString atIndex:(NSUInteger)existingTokenIndex { if (existingTokenIndex == NSNotFound) { // Token is new, create a new instance MyTokenObject *newToken = //create and configure. return newToken; } else { // This would update the editing string but wouldn't discard existing data held by the token. MyTokenObject *tokenObj = [self existingTokenAtIndex:existingTokenIndex]; tokenObj.editingString = editingString; return tokenObj; } }

I have a NSViewRepresentable that wraps an NSTextField subclass which is displayed as larger than your typical text field. SwiftUI doesn't seem to allow me to set the size of the view when the underlying is an NSTextField. It forces it as a single line field. I've tried both setting the frame on creation as well as using SwiftUI .frame(width:height:) on the represented view. I always end up with a single line field. struct BigTextField: NSViewRepresentable { @Binding var text: String class Coordinator: NSObject, NSTextFieldDelegate { var parent: BigTextField init(_ parent: BigTextField) { self.parent = parent } func controlTextDidChange(_ obj: Notification) { if let textField = obj.object as? NSTextField { parent.text = textField.stringValue } } } func makeCoordinator() -> Coordinator { Coordinator(self) } func makeNSView(context: Context) -> NSTextField { //let frame = NSRect(x: 0, y: 0, width: 350, height: 140) //let textField = NSTextField(frame: frame) let textField = NSTextField() textField.isEditable = true textField.isBordered = true textField.isBezeled = true textField.delegate = context.coordinator // Assign the coordinator return textField } func updateNSView(_ nsView: NSTextField, context: Context) { if nsView.stringValue != text { nsView.stringValue = text } } } I've also included the SwiftUI declaration which demonstrates the problem. struct ContentView: View { @State var text : String = "Test string" var body: some View { VStack { BigTextField(text: $text) .frame(width: 350, height: 140) } .padding() } } NSTextField can be any arbitrary frame size. I already do this from AppKit but am trying to adapt this custom field to work within SwiftUI. SwiftUI seems to override the sizing of this NSViewRepresentable that I give it. Am I missing something here? Is there some way to override SwiftUI's sizing behavior? Thank you.

I tried Glass in NSApp.dockTile.contentView. Any Glass there isn't shown like it normally is in windows. Does this limitation exist intentionally?

I’m embedding an NSTextView (TextKit 2) inside a SwiftUI app using NSViewRepresentable. I’m trying to highlight dynamic subranges (changing as the user types) by providing per-range rendering attributes via NSTextLayoutManager’s rendering-attributes mechanism. The issue: the highlight is unreliable. Often, the highlight doesn’t appear at all even though the delegate/data source is returning attributes for the expected range. Sometimes it appears once, but then it stops updating even when the underlying “highlight range” changes. This feels related to SwiftUI - AppKit layout issue when using NSViewRepresentable (as said in https://developer.apple.com/documentation/swiftui/nsviewrepresentable). What I’ve tried Updating the state that drives the highlight range and invalidating layout fragments / asking for relayout Ensuring all updates happen on the main thread. Calling setNeedsDisplay(_:) on the NSViewRepresentable’s underlying view. Toggling the SwiftUI view identity (e.g. .id(...)) to force reconstruction (works, but too expensive / loses state). Question In a SwiftUI + NSViewRepresentable setup with TextKit 2, what is the correct way to make NSTextLayoutManager re-query and redraw rendering attributes when my highlight ranges change? Is there a recommended invalidation call for TextKit 2 to trigger re-rendering of rendering attributes? Or is this a known limitation when hosting NSTextView inside SwiftUI, where rendering attributes aren’t reliably invalidated? If this approach is fragile, is there a better pattern for dynamic highlights that avoids mutating the attributed string (to prevent layout/scroll jitter)?

When working on a multi-window AppKit app, how do you identify which window instance is associated with the current breakpoint? The same question applies when using LLDB. If execution stops inside an object that can exist in more than one window, such as a shared NSViewController subclass, how do you know which window’s object you are currently inspecting? Does Xcode provide a mechanism for showing the NSWindow associated with the current view, view controller or responder while debugging? My current approach is to print object identities and compare them manually. For example, if several identical windows are open, I might print the current object and its window: print(self, #function) Then I interact with one window, make a note of the printed memory addresses in the console, switch to another window and compare the output. This works, but it feels manual. I am not dealing with different window subclasses. The windows may be instances of the same class and may contain instances of the same view controller classes. I simply want an easier way to distinguish which window instance I am debugging. Is there a recommended Xcode, LLDB or AppKit workflow for this?

I'd like to create a Quick Look extension for a file type for which a location or region on a Map should be shown as preview. However the MapView would only show a grid without any map. From within the MapKit delegate I can see from the "Error" parameter (a server with this domain can not be found) that this seems to be a network issue. The Quick Look extension seems to have no access to the internet and therefore the MapView can not load any map data. I've then also done some other tests via URLSession, which also only fails with connection errors. I haven't seen any limitations or restrictions mentioned in the API documentation. Is this the expected behavior? Is this a bug? Or am I missing something?

I’m building a macOS video editor that uses AVComposition and AVVideoComposition. Initially, my renderer creates a composition with some default video/audio tracks: @Published var composition: AVComposition? @Published var videoComposition: AVVideoComposition? @Published var playerItem: AVPlayerItem? Then I call a buildComposition() function that inserts all the default video segments. Later in the editing workflow, the user may choose to add their own custom video clip. For this I have a function like: private func handlePickedVideo(_ url: URL) { guard url.startAccessingSecurityScopedResource() else { print("Failed to access security-scoped resource") return } let asset = AVURLAsset(url: url) let videoTracks = asset.tracks(withMediaType: .video) guard let firstVideoTrack = videoTracks.first else { print("No video track found") url.stopAccessingSecurityScopedResource() return } renderer.insertUserVideoTrack(from: asset, track: firstVideoTrack) url.stopAccessingSecurityScopedResource() } What I want to achieve is the same behavior professional video editors provide, after the composition has already been initialized and built, the user should be able to add a new video track and the composition should update live, meaning the preview player should immediately reflect the changes without rebuilding everything from scratch manually. How can I structure my AVComposition / AVMutableComposition and my rendering pipeline so that adding a new clip later updates the existing composition in real time (similar to Final Cut/Adobe Premiere), instead of needing to rebuild everything from zero? You can find a playable version of this entire setup at :- https://github.com/zaidbren/SimpleEditor

We have a status item which works fine on macOS 26 and earlier, which has the following properties: Supports left-click to open main UI (a popover) Supports left-click (while open) to toggle (close) the main UI Supports right-click to show "app" menu (e.g. About, Quit) Supports a drop destination to accept files and folders, which then triggers the main UI for more interaction In macOS 27: left-click seems ok if we use expanded interface session, but otherwise broken left-click while open no longer toggles (event is missing?) right click is no longer operational, to the point that it seems the Menu Bar doesn't forward the event at all. Other (Apple-provided) items work fine, and expose new context menus Dragging now triggers Mission Control, which seems wrong given the destination was in the Menu Bar (FB23018381). Are these interactions now forbidden, and are there lists or documentation of the new rules? As an additional bug, it looks like popovers don't pick up appearance changes. The child scroll view claims to be in light appearance in the View Debugger, but is clearly showing the wrong background color, this is a new (as-yet unreported) issue. One last bug: expanded interface session seems to suppress the popover's animation when shown.

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!

I have an NSTextView subclass and implements drag and drop for custom draggable data, so I override -writablePasteboardTypes and add my own type as described in the header file: // Returns an array of pasteboard types that can be provided from the current selection. Overriders should copy the result from super and add their own new types. @property (readonly, copy) NSArray<NSPasteboardType> *writablePasteboardTypes; Now my textview also accepts the drop. Drag and drop can be used to move the custom data to a different location in the text view's character range. Like grabbing a block of text and moving it. So I accept the drop in -readSelectionFromPasteboard:type: I have a variable I cache at the start of dragging like: _myDraggingItem = // Set at the start of dragging. Then when I accept the drop I just use _myDraggingItem to move it to the drop location in the text view. I don't need to actually serialize the entire object and write it on the pasteboard I can just use _myDraggingItem to move from the source location to destination location. This is local only drag and drop. it works, except when the mouse leaves the text view briefly during the dragging session. This is because I override NSTextView's - (void)cleanUpAfterDragOperation // If you set up persistent state that should go away when the drag operation finishes, you can clean it up here. Such state is usually set up in -dragOperationForDraggingInfo:type:. You should probably never need to call this except to message super in an override. - (void)cleanUpAfterDragOperation; So documentation indicates -cleanUpAfterDragOperation is for clean up after drag operation finishes so I nil out _myDraggingItem here. But -cleanUpAfterDragOperation is getting called from [NSDragDestination _draggingExited]. -draggingExited: means the drag location moved outside the view it does not mean that the dragging session is over. The drag can move back inside the view after briefly exiting, so this isn't a usable place to clean up state tied to the dragging session as the header file indicates. I must override -draggingEnded: instead. If that sounds like a bug let me know.

I’m working on a storyboard-based AppKit application that uses an NSWindowController containing an NSSplitViewController with multiple child view controllers. The hierarchy is roughly: NSWindowController └── NSSplitViewController ├── NSViewController ├── NSViewController └── NSViewController I am trying to provide dependencies during storyboard instantiation using either @IBSegueAction or instantiateInitialController(creator:), rather than configuring everything after initialisation. What I attempted I added custom initialisers to my view controllers so I can pass dependencies at creation time: class SplitViewController: NSSplitViewController { let dependency: Dependency init?(coder: NSCoder, dependency: Dependency) { self.dependency = dependency super.init(coder: coder) } required init?(coder: NSCoder) { print("init(coder:) was called") fatalError("init(coder:) is not supported") } } I then attempted to intercept storyboard instantiation using @IBSegueAction, trying it in both the window controller and the split view controller: @IBSegueAction func makeSplitViewController(_ coder: NSCoder) -> NSSplitViewController? { SplitViewController(coder: coder, dependency: dependency) } I also tried attaching the segue action at different points in the storyboard, but the behaviour did not change. Observed behaviour Regardless of where I place the segue action, AppKit still appears to call: required init?(coder: NSCoder) This means my custom initialiser is never used for the split view controller or its children. Background reference I found this older known issue in the Xcode 11 release notes: “A Segue Action on a relationship segue between a NSWindowController and a View Controller is currently not supported and ignored. (48252727)” This suggests that, at least historically, AppKit relationship segues ignored segue actions entirely. Has this limitation since been fixed in modern Xcode/macOS SDK releases, or are relationship segues involving NSWindowController still incompatible with @IBSegueAction? More generally, what is the intended way to provide dependencies to an NSSplitViewController and its child view controllers in a storyboard-based AppKit application? I am also unclear whether instantiateInitialController(creator:) participates in the creation of container hierarchies like split view controllers, or only top-level controllers.

I’m seeing a macOS 26 AppKit issue with a sidebar + full-size content window + titlebar accessory setup. The main problem is that an NSTitlebarAccessoryViewController can visually cover the first item in the sidebar when System Settings > Accessibility > Display > Reduce Transparency is enabled. In my app this made the first sidebar/menu item look blacked out/covered by the titlebar/accessory area. While investigating possible workarounds, I also compared NSTitlebarAccessoryViewController with NSSplitViewItemAccessoryViewController and found two related issues that make the split-view accessory hard to use as a replacement. I could not attach the full sample project directly, so I included the two relevant Swift files below. The screenshots were taken from the same minimal AppKit repro with Reduce Transparency enabled. Repro setup The sample project shows: a fixed-width sidebar one content pane using NSTitlebarAccessoryViewController one content pane using NSSplitViewItemAccessoryViewController both accessories use the same custom view both custom views request the same intrinsic height each accessory displays its requested and actual height main.swift AppDelegate.swift Issue 1: titlebar accessory can cover sidebar content With Reduce Transparency enabled, the titlebar/accessory area can visually cover content at the top of the sidebar. This is the original issue I’m trying to solve. Expected: the sidebar content should not be covered by the titlebar accessory/material. Actual: the top sidebar item can appear blacked out/covered. In the first attached screenshot, "First sidebar row" is hidden/covered while "Second row" and the following rows are still visible. Issue 2: split-view accessory does not get the same hard separator As a possible workaround, I tried using NSSplitViewItemAccessoryViewController instead of NSTitlebarAccessoryViewController. Both controllers are configured with: if #available(macOS 26.1, *) { accessory.preferredScrollEdgeEffectStyle = .hard } The titlebar accessory shows the expected hard boundary/separator behavior, but the split-view item accessory does not appear to get the same hard edge treatment. The second attached screenshot shows the workaround comparison between the titlebar accessory and the split-view accessory. Expected: preferredScrollEdgeEffectStyle = .hard should produce a comparable hard separator for the split-view accessory. Actual: the split-view accessory still looks visually different and does not show the same hard boundary. Issue 3: split-view accessory is inset differently The NSSplitViewItemAccessoryViewController also appears to be laid out with spacing/insets around it. In the repro, the accessory custom view has a faint red background. Both accessory views request and receive the same height: requested 36 pt, actual 36.0 pt So the mismatch does not seem to be caused by the accessory view’s own intrinsic height. Instead, the split-view accessory appears to be hosted inside an inset container, with spacing around it, while the titlebar accessory is flush with the titlebar/content edge. Expected: if both accessories host the same view with the same intrinsic height, their effective placement should be comparable, or there should be a documented way to remove/control the split accessory insets. Actual: the split-view accessory is visually inset on multiple sides, making it unsuitable as a drop-in workaround for the titlebar accessory issue. The second attached screenshot also shows this: the split-view accessory has the same requested and actual height as the titlebar accessory, but it is still visually inset and does not align the same way. Question Is this expected behavior on macOS 26, especially with Reduce Transparency enabled? If so, what is the recommended AppKit approach for placing a filter/search accessory below the toolbar/titlebar without covering sidebar content, while still getting a hard separator and predictable layout?

I'm trying to use SwiftUI views inside an NSToolbarItem, and I feel like I'm fighting the system. The goal is to create custom toolbar controls. I don't want AppKit or SwiftUI to recognize that there's a SwiftUI view in the toolbar and then try to style it automatically, which is what I think is happening. Consider this hierarchy: - NSToolbar - NSToolbarItem - view -> MyCustomNSView - addSubview(NSHostingView<CustomView>) So CustomView is inside an NSHostingView, which is inside an NSView, which is assigned to the .view property of an NSToolbarItem. For a while, I struggled to get this working at all because SwiftUI's layout metrics appeared to be affected by safe area insets. SwiftUI's ignoresSafeArea() only seemed to move the problem around. For now, I've disabled full-size content view, which I don't really need anyway. However, a SwiftUI Button or Menu still doesn't behave or style the way I would expect when placed inside an NSToolbarItem. They don't seem to honor many of the styling attributes or view modifiers that work elsewhere. Is there a way to tell AppKit to "ignore" the children of my NSToolbarItem and not apply toolbar-specific styling to them? Am I even correct in thinking that AppKit is recognizing a Button or Menu in the toolbar and forcibly applying styling to it? Previously, I tried implementing my "custom toolbar" entirely outside of NSToolbar, but then SwiftUI struggled with placing views under the transparent, non-existent toolbar. I'd appreciate any direction or hints here. It would be really nice to use SwiftUI for the controls I have in mind, but at the moment I can't get close to the result I'm aiming for.

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.