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

Posts under AppKit tag

200 Posts

Post

Replies

Boosts

Views

Activity

window:willUseFullScreenPresentationOptions: with NSApplicationPresentationHideDock causes other windows to be unminimizable
In the below code, I create two windows, and use a window delegate to make sure that whenever the first is fullscreened, its menubar and dock are hidden properly. However, when I fullscreen the first window and go back to the desktop to see my second window, the second window's minimize button is grayed out and using miniaturize on it will not work either. I've tried various things; it seems like if I fullscreen the second window and the unfullscreen it, it then becomes minimizable without additional side effects. Is there any reason why this is happening? This seems like a bug in AppKit... so how do I work around it programmatically? #import <Cocoa/Cocoa.h> @interface AppDelegate : NSObject <NSApplicationDelegate, NSWindowDelegate> @property (strong) NSWindow *mainWindow; @property (strong) NSWindow *secondaryWindow; @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { NSRect mainRect = NSMakeRect(100, 300, 400, 300); self.mainWindow = [[NSWindow alloc] initWithContentRect:mainRect styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskMiniaturizable | NSWindowStyleMaskResizable) backing:NSBackingStoreBuffered defer:NO]; [self.mainWindow setTitle:@"Main Window (Go Fullscreen Here)"]; [self.mainWindow setDelegate:self]; NSTextField *mainLabel = [NSTextField labelWithString:@"1. Click the green zoom/fullscreen button on THIS window.\n\n2. Look at the other window's yellow minimize button."]; [mainLabel setFrame:NSMakeRect(20, 100, 360, 100)]; [[self.mainWindow contentView] addSubview:mainLabel]; [self.mainWindow makeKeyAndOrderFront:nil]; NSRect secondaryRect = NSMakeRect(550, 300, 400, 300); self.secondaryWindow = [[NSWindow alloc] initWithContentRect:secondaryRect styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskMiniaturizable | NSWindowStyleMaskResizable) backing:NSBackingStoreBuffered defer:NO]; [self.secondaryWindow setTitle:@"Secondary Window (The Victim)"]; NSButton *testButton = [NSButton buttonWithTitle:@"Try code [window miniaturize:]" target:self action:@selector(attemptProgrammaticMinimize:)]; [testButton setFrame:NSMakeRect(80, 130, 240, 40)]; [[self.secondaryWindow contentView] addSubview:testButton]; [self.secondaryWindow makeKeyAndOrderFront:nil]; } - (NSApplicationPresentationOptions)window:(NSWindow *)window willUseFullScreenPresentationOptions:(NSApplicationPresentationOptions)proposedOptions { return NSApplicationPresentationFullScreen | NSApplicationPresentationHideMenuBar | NSApplicationPresentationHideDock; } - (void)attemptProgrammaticMinimize:(id)sender { [self.secondaryWindow miniaturize:nil]; NSLog(@"[Repro] Minimize attempted"); } - (BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender { return YES; } @end int main(int argc, const char * argv[]) { @autoreleasepool { NSApplication *app = [NSApplication sharedApplication]; [app setActivationPolicy:NSApplicationActivationPolicyRegular]; AppDelegate *delegate = [[AppDelegate alloc] init]; [app setDelegate:delegate]; [app activateIgnoringOtherApps:YES]; [app run]; } return 0; }
3
0
421
7h
Full keyboard access blocks NSTextField from being the initial first responder in NSPopover
I'm working on this UI where I present a popover and user fills in some brief information. There are various buttons and a single editable text field in the UI. When 'Full Keyboard access' is disabled in System Settings and the popover is presented the editable NSTextField is the initial first responder and the user can begin typing immediately. This is the behavior that I expect and want. Now when full keyboard access is enabled the text field does not become the immediate first responder (and none of the buttons in the popover have 'focus' state either) so initially hitting a key does nothing. To me this feels unnatural and is not the expected behavior. To interact with the text field with full keyboard access I have to do one of the following: Use the mouse to click the text field (which is an extra step). Or Press tab several times to move 'Focus' (initially no button has it) all the way down to the textfield. Both requirements slow down the user. Is this expected behavior? Shouldn't the initial key view follow the natural first responder (in this case an editable text field) and the user can tab away from that starting location? instead nobody has key focus when the popover is first presented until tabbing is initiated. I can currently 'workaround' this it seems by manually setting the text field as first responder in viewDidAppear [self.view.window makeFirstResponder:self.theTextField]; Then the text field accepts keyboard input immediately. But when 'Full keyboard access' is disabled (which I assume is the more typical configuration) this is not required, the text field just gets first responder by default. If this is not the expected behavior let me know and I may file a feedback.
0
0
81
1d
NSSplitViewController-like inspector in custom view
From the currently available information, it seems like the only way to get the new-in-Tahoe sidebar inspector effect is to use a NSSplitView in conjunction with NSSplitviewController & inspectorWithViewController:. I'm currently trying to get the same inspector effect - which also affects the looks of controls inside the inspector, like text fields, which switch to a gray-ish background - in a totally custom splitter-like view hierarchy that is way more complex than NSSplitView and thus cannot inherit or take advantage of it. Is there a way to integrate this effect in a custom view? Maybe using NSVisualEffectView or NSGlassEffectView?
1
0
110
6d
SwiftUI animation is laggy in NSStatusItem since macOS 26 Tahoe
My app is a bit of a special case and relies on a custom view in a NSStatusItem. I use a NSHostingView and add it as a subview to my NSStatusItem's .button property. Since macOS 26 Tahoe, even simple animations like a .frame change of a Circle won't animate smoothly even though the same SwiftUI animates normally in a WindowGroup. class AppDelegate: NSObject, NSApplicationDelegate { private let statusItem: NSStatusItem = NSStatusBar.system.statusItem(withLength: NSStatusItem.variableLength) func applicationDidFinishLaunching(_ aNotification: Notification) { let subview = NSHostingView(rootView: AnimationView()) let view = self.statusItem.button view?.addSubview(subview) subview.translatesAutoresizingMaskIntoConstraints = false guard let view = view else { return } NSLayoutConstraint.activate([ subview.centerXAnchor.constraint(equalTo: view.centerXAnchor), subview.centerYAnchor.constraint(equalTo: view.centerYAnchor), subview.widthAnchor.constraint(equalToConstant: 22), subview.heightAnchor.constraint(equalToConstant: 22) ]) } } struct AnimationView: View { @State private var isTapped = false @State private var size: CGSize = .init(width: 4, height: 4) var body: some View { Circle() .fill(.pink) .frame(width: size.width, height: size.height) .frame(width: 20, height: 20) // .frame(maxHeight: .infinity) // .padding(.horizontal, 9) // .frame(height: 22) .contentShape(Rectangle()) // .background(Color.blue.opacity(0.5)) .onTapGesture { withAnimation(.interactiveSpring(response: 0.85, dampingFraction: 0.26, blendDuration: 0.45)) { // withAnimation(.spring()) { if isTapped { size = .init(width: 4, height: 4) } else { size = .init(width: 16, height: 16) } } isTapped.toggle() }} } Example project: https://app.box.com/s/q28upunrgkxyyd97ovslgud9yitqaxfk
1
0
259
1w
Various menu bar NSStatusItem issues with macOS 27
It seems like macOS 27 beta 2 has some issues with NSStatusItem buttons added to the menu bar - this creates difficulties for some menu bar extra apps. NSStatusItem buttons does not receive mouse hover/movement events - FB23329983 On macOS 27, views inside an NSStatusItem button no longer receive hover or mouse-movement events. The same code works correctly on macOS 26. What I tried: An NSTrackingArea attached to a subview of NSStatusBarButton An NSTrackingArea attached directly to the status-bar button Replacing NSStatusItem.view with a custom view Embedding an NSHostingView and using SwiftUI onHover/onContinuousHover NSStatusItem button highlight cannot be set programmatically. - FB23330269 The following code no longer has any effect (does not provide the highlight capsule): NSStatusItem.button?.highlight(true) NSStatusItem window occlusionState no longer reflects hidden menu bar visibility - FB23349447 The following no longer works: statusItem.button?.window?.occlusionState.contains(.visible) These changes may be related to some of the touch related changes or maybe it's about how menu items are now seemingly more "managed" in a way that their position, visibility may change in a way that is transparent/undetectable to the app.
5
2
514
2w
NSTrackingSeparatorToolbarItem causes problems when putting a window in full screen on Golden Gate (macOS 27)
NSTrackingSeparatorToolbarItem adds a white band over the top of the leading split view panes when in full screen mode on macOS 27. That white band appears to have the height of the toolbar. I filed FB23827858 with a sample project and a video demonstrating the issue. I also wrote about it at: https://virtualsanity.com/202607/nstrackingseparatortoolbaritem-causes-problems-when-putting-a-window-in-full-screen-on-golden-gate-macos-27/ I am hoping this is addressed before macOS 27 ships.
Topic: UI Frameworks SubTopic: AppKit Tags:
1
0
198
2w
How to style SwiftUI sidebar row selections like native macOS apps (Finder, Photos)
https://gist.github.com/MorusPatre/4b1e93973c3e4133794512fd7eefee48 This Is a Test App to find out how to actually achieve the exact sidebar styling Apple uses for Finder, Photos etc. The crucial part is how do I make it so the symbol and name of the selected row use the accent colour with active and inactive styling rather than having the accent colour for the row background? It shouldn't be that complicated I feel like but every AI model (even Claude Fable 5) fails at that and I haven't found apps or videos where that is explained so is that just a classic case of "Apple doesn't want you to know"?
2
0
287
3w
SwiftUI on macOS equivalent of NSSavePanel for choosing a destination URL?
In AppKit, NSSavePanel can be used to ask the user for a destination URL before the app creates a file. What is the SwiftUI equivalent for this? .fileImporter covers the NSOpenPanel case well enough, but I have not found a SwiftUI API that matches the simple NSSavePanel case where the app only needs the URL. There's a new API in .fileExporter that appears close, but it requires a non nil WritableDocument, and seems designed around SwiftUI performing the file export. My use case is a macOS app that creates new documents backed by SQLite. SQLite needs a file path so it can create the database at that location. With NSSavePanel, I can ask the user where to save the document, receive a URL, and then create the SQLite database myself. Is there a SwiftUI API for this on macOS 26 or later? If not, is NSSavePanel still the recommended approach for this case?
6
0
316
3w
Issue with Auto-Blur Effect of NSScrollViews under NSToolbar, Ref: WWDC25
Hello, I'm building an app that is designed to largely mimick Apple's own audio auto-switch behavior when switching between different audio output devices like MacBook Pro speakers and AirPods. The purpose is to "lend a hand" to certain apps, like CrossOver (wine) ran x68-64 apps that don't seem to respond well to CoreAudio changing the audio output after the x68-64 program has already init its audio after startup. Thus, I don't actually need much of a GUI except for a few specific features, and perhaps later some ehancements I'd like to add that can make use of a proper GUI. I've decided to implement the MacOS Tahoe Apple Liquid Glass UI to keep the user experience as streamlined and intuitive as possible. I've largely been successful: The GitHub page goes into greater detail showing the greater context of the AppKit API's I'm using to achieve this UI design. There is just one issue I haven't been able to solve, how to get the sidebar tab(s) to blur when scrolled underneath the Window Controls (Traffic Light) buttons. These tabs are part of a NSScrollView underneath the NSToolbar aligned from the top-most left and right window edges, but split from the right-hand content side via NSSplitViewController > NSSplitViewItem (again exact topology is at the page "link" below). On the content side (right side), I used NSSplitViewItemAccessoryViewController to create the blur zone so that when its own NSScrollView content is scrolled upwards, past the toolbar NSToolbar, it would apply a progressive tint+blur effect, just as Apple has implemented in their own apps. This wasn't really automatic since I did have to elect to use it as part of a MacOS 26.1+ specific class (NSScrollEdgeEffectStyle), but it's working on the content side nonetheless: Now I am trying to get the same effect working on the sidebar side and am having issues with this. Please see the page below as it summarizes our test attempts with greater detail. I've only gotten this far by reading "obscure" comments in the SDK's so I'm really hoping this is just a ID10T error in that I've missed something. Note: even though I only have 3 tabs currently in the sidebar NSScrollView, I will eventually populate this further, especially with some user configurable stuff on my roadmap. That said, the sidebar is only "scrollable" right now because I've left the "vertical scroll elasticity" enabled, intentionally. (.verticalScrollElasticity [IS NOT] .none! Therefore, I can still "scroll" the enumerated tabs inside the sidebar's NSScrollView upward behind the Traffic Light buttons, to validate if the blur+tint effect is being rendered. I say all of that to ask if, perhaps, the reason that the blur+tint effect is not rendering in the Window could be because there's not enough content to render in the sidebar to produce a scrollbar, and simply leaving .verticalScrollElasticity "enabled" is not sufficient to produce this effect? I don't know that for sure, but it's the only thing I can think of at this point. Its not obvious to me though. This app is written entirely in Swift (v6.3.3) and will require a minimum of MacOS Tahoe 26.1.X due to the AppKit API's I'm using (namely NSScrollEdgeEffectStyle). GitHub Page documenting issue in greater detail (remove the spaces): HT TP S:// gitdev.brianbutts.me /sidebar-scroll-edge-blur. html
1
0
504
Jul ’26
NSApp.activate() does not work with menu bar (background) apps
NSApp(ignoringOtherApps:) is deprecated but there is no other working alternative for menu bar apps. NSApp.activate() does not work when no app windows are active and we want to show a window from a menu bar application. Making it impossible for the app to open a window and make it active. Is it really an intended behavior? Here is a sample project showing the issue: https://github.com/wojciech-kulik/macos-menu-bar-bug Steps to reproduce: Run the app. Focus some other app like Finder or Safari. Click on the app's menu bar icon and select "Open". The app window will appear below the other app's window, instead of being brought to the front. NSApp(ignoringOtherApps: true) works as expected though. I also created a feedback ticket: FB23508310
10
1
405
Jul ’26
NSMenuItem.separator() appears as blank space in Finder Sync extension context menu
Hi, I’m developing a macOS Finder Sync extension and noticed that NSMenuItem.separator() does not appear to render as a standard separator line when used inside the menu returned from FIFinderSyncController. In a normal AppKit NSMenu, the separator renders as expected. However, when the same kind of menu is returned from the Finder Sync extension, the separator appears as a blank/full-height empty row rather than a thin dividing line. Example: override func menu(for menuKind: FIMenuKind) -> NSMenu { let menu = NSMenu(title: "") menu.addItem(NSMenuItem( title: "First Action", action: #selector(firstAction(_:)), keyEquivalent: "" )) menu.addItem(NSMenuItem.separator()) menu.addItem(NSMenuItem( title: "Second Action", action: #selector(secondAction(_:)), keyEquivalent: "" )) return menu } Expected result: The separator should render as a normal macOS menu separator line between the two menu items. Actual result: In Finder’s context menu, the separator is displayed as blank vertical space / an empty menu row. I understand that Finder Sync menus are rendered by Finder and may not support every NSMenuItem feature. However, NSMenuItem.separator() is a very standard way to visually group menu commands, so I wanted to ask: Is this a known limitation of Finder Sync extension menus? Is there a supported way to display a real separator line in Finder Sync context menus? Should this be filed as a Feedback Assistant issue against Finder Sync / AppKit? I’m trying to avoid fake separators such as disabled menu items with "────" as the title, since that does not feel native and may not behave well with different fonts, accessibility settings, or appearance modes. Thanks!
0
0
300
Jun ’26
Does @IBSegueAction still not work for AppKit relationship segues from NSWindowController?
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.
2
0
876
Jun ’26
NSTableView: checking for mouse-driven selection changes on macOS 27
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!
Topic: UI Frameworks SubTopic: AppKit Tags:
8
0
442
Jun ’26
IKPictureTaker shows blank panel on macOS 26 — popUpRecentsMenu silently fails with no callback
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?
3
0
604
Jun ’26
How to override NSTextView dragging behaviour without overriding mouseDown:?
I have an NSTextView subclass that overrides mouseDown: to allow for image resizing. If a user clicks and drags on the edges of an image, I implement custom behaviour that resizes the image (and shows resizing cursors). If the user clicks anywhere else, super's implementation is called. This all works great. As of macOS 27, however, the transition to gesture recognisers instead of overriding mouseDown: means that I should probably be moving away from the above approach. NSTextView now uses the new NSTextSelectionManager to implement selection and dragging via gesture recognisers, although, according to the release notes: Existing NSTextView subclasses that override mouseDown: continue to work through a binary-compatible fallback path. (163365571) It's unclear whether this means that we therefore should still override mouseDown: for custom behaviour in NSTextView, but to me, this, along with the content of Tech Note TN3212, strongly implies that, although it will continue to work thanks to "a binary-compatible fallback", we should entirely move away from overriding mouseDown: in the future. If that is indeed the case, how do we implement custom dragging behaviour--such as for resizing images as in my example--in NSTextView? There still seems to be no way of doing it other than overriding mouseDown:. I had thought that I might be able to add an NSPanGestureRecognizer to the text view and have it fail via its delegate methods if the clicks were outside of an image's edges, but a pan gesture recogniser added to an NSTextView is entirely ignored, presumably because of the private gestures already added. Fortunately everything continues to work for now, but I would like to update my code as much as possible.
Topic: UI Frameworks SubTopic: AppKit Tags:
4
0
398
Jun ’26
NSTextView.menuForEvent - getting the affected range on macOS 27
I have an NSTextView subclass that replaces the standard context menu with a custom one by building its own menu in an menuForEvent: override. The context menu that is shown depends on what is selected in the text view, so it checks the current selectedRange to determine which commands should be included. (I could do much the same via the NSTextViewDelegate method textView(_:menu:for:at:), but since my text view subclass is used in several areas, each with their own delegate, it's better to do it in menuForEvent(_:).) This has all worked fine for years, but with NSTextView's transition to gesture recognisers and NSTextSelectionManager for handling text selections in macOS 27, the timings have changed. Previously, if you Ctrl-clicked on a word so that the word is selected and the context menu appears, setSelectedRanges:affinity:stillSelecting: would be called first and then menuForEvent: would be called. On macOS 27, however, the order of events is reversed: menuForEvent: is called first, before setSelectedRanges:affinity:stillSelecting:. (If you implement NSMenuDelegate.menuNeedsUpdate:, that is also called before setSelectedRanges:....) This means that you can no longer rely on selectedRanges in menuForEvent:, because on macOS 27, selectedRanges in menuForEvent: represents the previous selection, not the selection you will actually see on screen when the menu appears. This makes building a custom context menu somewhat tricky. I suspect this is a bug and have reported it as such (FB23251873, with apologies to the engineers for the pleading tone in that report; it was at the end of a long week of getting my head around the gesture recogniser changes. :) ). But it occurs to me that there is nothing in the documentation that guarantees that selectedRanges will be accurate in menuForEvent:; it's just always worked this way. So am I missing something here? Is there a better or more reliable way of getting the range that will be affected by the contextual menu in NSTextView? (The delegate method only provides a single character index, which isn't enough information for spelling corrections and such which require a range.) My current workaround is to rebuild the context menu in setSelectedRanges:affinity:stillSelecting: if it is called between menuForEvent: and didCloseMenu:withEvent:.
Topic: UI Frameworks SubTopic: AppKit Tags:
2
0
329
Jun ’26
How do you correctly use a SwiftUI View inside an NSToolbarItem?
I've been struggling to get consistent UI and UX behaviour of SwiftUI Views inside NSToolbarItems and was wondering if there is an official way to use them. I've now revisited this issue in macOS 27 and continue to see some idiosyncrasies. In the attached screenshot, you can see that the highlight area on mouse down between to the two buttons is different. This is the easiest example I've come up with that shows SwiftUI Views exhibiting different behaviour than AppKit Views. Two questions: Is an NSHostingView a valid and supported view type for NSToolbarItem.view? If so, are there any rules that govern how the SwiftUI view should be configured? (ex: frame, sizing options, supported SwiftUI Views, preferred "root view" types, etc?) Sample code that created the two NSToolbarItem buttons in the screenshot. macOS 27 ZY21R0CMGL (Public Beta 1) Xcode 27.0 beta Minimum Deployment target: 27.0 // Left-Top SwiftUI Button (Clipped Highlighting) let item = NSToolbarItem(itemIdentifier: itemIdentifier) let rootView = Button { } label: { Image(systemName: "sidebar.trailing") } item.view = NSHostingView(rootView: rootView) // ... snip .. // Right-Bottom AppKit Button (Correct Highlighting) let item = NSToolbarItem(itemIdentifier: itemIdentifier) item.image = NSImage(systemSymbolName: "sidebar.trailing", accessibilityDescription: nil) Both screenshots are taken on mouse down.
2
0
246
Jun ’26
Annoying popup window in Xcode Previews when the initial controller of the main storyboard is a macOS window
I started a project targeting macOS and used Storyboard app lifecycle. I also used Xcode Previews in this project. If I: Keep the entry point of the main storyboard to a window controller. (as default setup in macOS), Turn the Xcode window into full-screen, That window controller would pop up its window every time Xcode Previews refreshes. I tested in Xcode 26.3 RC and many versions before.
7
0
471
Jun ’26
window:willUseFullScreenPresentationOptions: with NSApplicationPresentationHideDock causes other windows to be unminimizable
In the below code, I create two windows, and use a window delegate to make sure that whenever the first is fullscreened, its menubar and dock are hidden properly. However, when I fullscreen the first window and go back to the desktop to see my second window, the second window's minimize button is grayed out and using miniaturize on it will not work either. I've tried various things; it seems like if I fullscreen the second window and the unfullscreen it, it then becomes minimizable without additional side effects. Is there any reason why this is happening? This seems like a bug in AppKit... so how do I work around it programmatically? #import <Cocoa/Cocoa.h> @interface AppDelegate : NSObject <NSApplicationDelegate, NSWindowDelegate> @property (strong) NSWindow *mainWindow; @property (strong) NSWindow *secondaryWindow; @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { NSRect mainRect = NSMakeRect(100, 300, 400, 300); self.mainWindow = [[NSWindow alloc] initWithContentRect:mainRect styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskMiniaturizable | NSWindowStyleMaskResizable) backing:NSBackingStoreBuffered defer:NO]; [self.mainWindow setTitle:@"Main Window (Go Fullscreen Here)"]; [self.mainWindow setDelegate:self]; NSTextField *mainLabel = [NSTextField labelWithString:@"1. Click the green zoom/fullscreen button on THIS window.\n\n2. Look at the other window's yellow minimize button."]; [mainLabel setFrame:NSMakeRect(20, 100, 360, 100)]; [[self.mainWindow contentView] addSubview:mainLabel]; [self.mainWindow makeKeyAndOrderFront:nil]; NSRect secondaryRect = NSMakeRect(550, 300, 400, 300); self.secondaryWindow = [[NSWindow alloc] initWithContentRect:secondaryRect styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskMiniaturizable | NSWindowStyleMaskResizable) backing:NSBackingStoreBuffered defer:NO]; [self.secondaryWindow setTitle:@"Secondary Window (The Victim)"]; NSButton *testButton = [NSButton buttonWithTitle:@"Try code [window miniaturize:]" target:self action:@selector(attemptProgrammaticMinimize:)]; [testButton setFrame:NSMakeRect(80, 130, 240, 40)]; [[self.secondaryWindow contentView] addSubview:testButton]; [self.secondaryWindow makeKeyAndOrderFront:nil]; } - (NSApplicationPresentationOptions)window:(NSWindow *)window willUseFullScreenPresentationOptions:(NSApplicationPresentationOptions)proposedOptions { return NSApplicationPresentationFullScreen | NSApplicationPresentationHideMenuBar | NSApplicationPresentationHideDock; } - (void)attemptProgrammaticMinimize:(id)sender { [self.secondaryWindow miniaturize:nil]; NSLog(@"[Repro] Minimize attempted"); } - (BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender { return YES; } @end int main(int argc, const char * argv[]) { @autoreleasepool { NSApplication *app = [NSApplication sharedApplication]; [app setActivationPolicy:NSApplicationActivationPolicyRegular]; AppDelegate *delegate = [[AppDelegate alloc] init]; [app setDelegate:delegate]; [app activateIgnoringOtherApps:YES]; [app run]; } return 0; }
Replies
3
Boosts
0
Views
421
Activity
7h
Full keyboard access blocks NSTextField from being the initial first responder in NSPopover
I'm working on this UI where I present a popover and user fills in some brief information. There are various buttons and a single editable text field in the UI. When 'Full Keyboard access' is disabled in System Settings and the popover is presented the editable NSTextField is the initial first responder and the user can begin typing immediately. This is the behavior that I expect and want. Now when full keyboard access is enabled the text field does not become the immediate first responder (and none of the buttons in the popover have 'focus' state either) so initially hitting a key does nothing. To me this feels unnatural and is not the expected behavior. To interact with the text field with full keyboard access I have to do one of the following: Use the mouse to click the text field (which is an extra step). Or Press tab several times to move 'Focus' (initially no button has it) all the way down to the textfield. Both requirements slow down the user. Is this expected behavior? Shouldn't the initial key view follow the natural first responder (in this case an editable text field) and the user can tab away from that starting location? instead nobody has key focus when the popover is first presented until tabbing is initiated. I can currently 'workaround' this it seems by manually setting the text field as first responder in viewDidAppear [self.view.window makeFirstResponder:self.theTextField]; Then the text field accepts keyboard input immediately. But when 'Full keyboard access' is disabled (which I assume is the more typical configuration) this is not required, the text field just gets first responder by default. If this is not the expected behavior let me know and I may file a feedback.
Replies
0
Boosts
0
Views
81
Activity
1d
NSSplitViewController-like inspector in custom view
From the currently available information, it seems like the only way to get the new-in-Tahoe sidebar inspector effect is to use a NSSplitView in conjunction with NSSplitviewController & inspectorWithViewController:. I'm currently trying to get the same inspector effect - which also affects the looks of controls inside the inspector, like text fields, which switch to a gray-ish background - in a totally custom splitter-like view hierarchy that is way more complex than NSSplitView and thus cannot inherit or take advantage of it. Is there a way to integrate this effect in a custom view? Maybe using NSVisualEffectView or NSGlassEffectView?
Replies
1
Boosts
0
Views
110
Activity
6d
SwiftUI animation is laggy in NSStatusItem since macOS 26 Tahoe
My app is a bit of a special case and relies on a custom view in a NSStatusItem. I use a NSHostingView and add it as a subview to my NSStatusItem's .button property. Since macOS 26 Tahoe, even simple animations like a .frame change of a Circle won't animate smoothly even though the same SwiftUI animates normally in a WindowGroup. class AppDelegate: NSObject, NSApplicationDelegate { private let statusItem: NSStatusItem = NSStatusBar.system.statusItem(withLength: NSStatusItem.variableLength) func applicationDidFinishLaunching(_ aNotification: Notification) { let subview = NSHostingView(rootView: AnimationView()) let view = self.statusItem.button view?.addSubview(subview) subview.translatesAutoresizingMaskIntoConstraints = false guard let view = view else { return } NSLayoutConstraint.activate([ subview.centerXAnchor.constraint(equalTo: view.centerXAnchor), subview.centerYAnchor.constraint(equalTo: view.centerYAnchor), subview.widthAnchor.constraint(equalToConstant: 22), subview.heightAnchor.constraint(equalToConstant: 22) ]) } } struct AnimationView: View { @State private var isTapped = false @State private var size: CGSize = .init(width: 4, height: 4) var body: some View { Circle() .fill(.pink) .frame(width: size.width, height: size.height) .frame(width: 20, height: 20) // .frame(maxHeight: .infinity) // .padding(.horizontal, 9) // .frame(height: 22) .contentShape(Rectangle()) // .background(Color.blue.opacity(0.5)) .onTapGesture { withAnimation(.interactiveSpring(response: 0.85, dampingFraction: 0.26, blendDuration: 0.45)) { // withAnimation(.spring()) { if isTapped { size = .init(width: 4, height: 4) } else { size = .init(width: 16, height: 16) } } isTapped.toggle() }} } Example project: https://app.box.com/s/q28upunrgkxyyd97ovslgud9yitqaxfk
Replies
1
Boosts
0
Views
259
Activity
1w
Various menu bar NSStatusItem issues with macOS 27
It seems like macOS 27 beta 2 has some issues with NSStatusItem buttons added to the menu bar - this creates difficulties for some menu bar extra apps. NSStatusItem buttons does not receive mouse hover/movement events - FB23329983 On macOS 27, views inside an NSStatusItem button no longer receive hover or mouse-movement events. The same code works correctly on macOS 26. What I tried: An NSTrackingArea attached to a subview of NSStatusBarButton An NSTrackingArea attached directly to the status-bar button Replacing NSStatusItem.view with a custom view Embedding an NSHostingView and using SwiftUI onHover/onContinuousHover NSStatusItem button highlight cannot be set programmatically. - FB23330269 The following code no longer has any effect (does not provide the highlight capsule): NSStatusItem.button?.highlight(true) NSStatusItem window occlusionState no longer reflects hidden menu bar visibility - FB23349447 The following no longer works: statusItem.button?.window?.occlusionState.contains(.visible) These changes may be related to some of the touch related changes or maybe it's about how menu items are now seemingly more "managed" in a way that their position, visibility may change in a way that is transparent/undetectable to the app.
Replies
5
Boosts
2
Views
514
Activity
2w
NSTrackingSeparatorToolbarItem causes problems when putting a window in full screen on Golden Gate (macOS 27)
NSTrackingSeparatorToolbarItem adds a white band over the top of the leading split view panes when in full screen mode on macOS 27. That white band appears to have the height of the toolbar. I filed FB23827858 with a sample project and a video demonstrating the issue. I also wrote about it at: https://virtualsanity.com/202607/nstrackingseparatortoolbaritem-causes-problems-when-putting-a-window-in-full-screen-on-golden-gate-macos-27/ I am hoping this is addressed before macOS 27 ships.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
1
Boosts
0
Views
198
Activity
2w
How to style SwiftUI sidebar row selections like native macOS apps (Finder, Photos)
https://gist.github.com/MorusPatre/4b1e93973c3e4133794512fd7eefee48 This Is a Test App to find out how to actually achieve the exact sidebar styling Apple uses for Finder, Photos etc. The crucial part is how do I make it so the symbol and name of the selected row use the accent colour with active and inactive styling rather than having the accent colour for the row background? It shouldn't be that complicated I feel like but every AI model (even Claude Fable 5) fails at that and I haven't found apps or videos where that is explained so is that just a classic case of "Apple doesn't want you to know"?
Replies
2
Boosts
0
Views
287
Activity
3w
SwiftUI on macOS equivalent of NSSavePanel for choosing a destination URL?
In AppKit, NSSavePanel can be used to ask the user for a destination URL before the app creates a file. What is the SwiftUI equivalent for this? .fileImporter covers the NSOpenPanel case well enough, but I have not found a SwiftUI API that matches the simple NSSavePanel case where the app only needs the URL. There's a new API in .fileExporter that appears close, but it requires a non nil WritableDocument, and seems designed around SwiftUI performing the file export. My use case is a macOS app that creates new documents backed by SQLite. SQLite needs a file path so it can create the database at that location. With NSSavePanel, I can ask the user where to save the document, receive a URL, and then create the SQLite database myself. Is there a SwiftUI API for this on macOS 26 or later? If not, is NSSavePanel still the recommended approach for this case?
Replies
6
Boosts
0
Views
316
Activity
3w
Issue with Auto-Blur Effect of NSScrollViews under NSToolbar, Ref: WWDC25
Hello, I'm building an app that is designed to largely mimick Apple's own audio auto-switch behavior when switching between different audio output devices like MacBook Pro speakers and AirPods. The purpose is to "lend a hand" to certain apps, like CrossOver (wine) ran x68-64 apps that don't seem to respond well to CoreAudio changing the audio output after the x68-64 program has already init its audio after startup. Thus, I don't actually need much of a GUI except for a few specific features, and perhaps later some ehancements I'd like to add that can make use of a proper GUI. I've decided to implement the MacOS Tahoe Apple Liquid Glass UI to keep the user experience as streamlined and intuitive as possible. I've largely been successful: The GitHub page goes into greater detail showing the greater context of the AppKit API's I'm using to achieve this UI design. There is just one issue I haven't been able to solve, how to get the sidebar tab(s) to blur when scrolled underneath the Window Controls (Traffic Light) buttons. These tabs are part of a NSScrollView underneath the NSToolbar aligned from the top-most left and right window edges, but split from the right-hand content side via NSSplitViewController > NSSplitViewItem (again exact topology is at the page "link" below). On the content side (right side), I used NSSplitViewItemAccessoryViewController to create the blur zone so that when its own NSScrollView content is scrolled upwards, past the toolbar NSToolbar, it would apply a progressive tint+blur effect, just as Apple has implemented in their own apps. This wasn't really automatic since I did have to elect to use it as part of a MacOS 26.1+ specific class (NSScrollEdgeEffectStyle), but it's working on the content side nonetheless: Now I am trying to get the same effect working on the sidebar side and am having issues with this. Please see the page below as it summarizes our test attempts with greater detail. I've only gotten this far by reading "obscure" comments in the SDK's so I'm really hoping this is just a ID10T error in that I've missed something. Note: even though I only have 3 tabs currently in the sidebar NSScrollView, I will eventually populate this further, especially with some user configurable stuff on my roadmap. That said, the sidebar is only "scrollable" right now because I've left the "vertical scroll elasticity" enabled, intentionally. (.verticalScrollElasticity [IS NOT] .none! Therefore, I can still "scroll" the enumerated tabs inside the sidebar's NSScrollView upward behind the Traffic Light buttons, to validate if the blur+tint effect is being rendered. I say all of that to ask if, perhaps, the reason that the blur+tint effect is not rendering in the Window could be because there's not enough content to render in the sidebar to produce a scrollbar, and simply leaving .verticalScrollElasticity "enabled" is not sufficient to produce this effect? I don't know that for sure, but it's the only thing I can think of at this point. Its not obvious to me though. This app is written entirely in Swift (v6.3.3) and will require a minimum of MacOS Tahoe 26.1.X due to the AppKit API's I'm using (namely NSScrollEdgeEffectStyle). GitHub Page documenting issue in greater detail (remove the spaces): HT TP S:// gitdev.brianbutts.me /sidebar-scroll-edge-blur. html
Replies
1
Boosts
0
Views
504
Activity
Jul ’26
How to manage TestFlight subscriptions on macOS?
I purchased a subscription within my TestFlight macOS build. I would like to access a screen to manage subscriptions and cancel it. How can I do that? I can't find this screen. In the App Store app I can only see my personal purchases.
Replies
1
Boosts
0
Views
476
Activity
Jul ’26
NSApp.activate() does not work with menu bar (background) apps
NSApp(ignoringOtherApps:) is deprecated but there is no other working alternative for menu bar apps. NSApp.activate() does not work when no app windows are active and we want to show a window from a menu bar application. Making it impossible for the app to open a window and make it active. Is it really an intended behavior? Here is a sample project showing the issue: https://github.com/wojciech-kulik/macos-menu-bar-bug Steps to reproduce: Run the app. Focus some other app like Finder or Safari. Click on the app's menu bar icon and select "Open". The app window will appear below the other app's window, instead of being brought to the front. NSApp(ignoringOtherApps: true) works as expected though. I also created a feedback ticket: FB23508310
Replies
10
Boosts
1
Views
405
Activity
Jul ’26
NSMenuItem.separator() appears as blank space in Finder Sync extension context menu
Hi, I’m developing a macOS Finder Sync extension and noticed that NSMenuItem.separator() does not appear to render as a standard separator line when used inside the menu returned from FIFinderSyncController. In a normal AppKit NSMenu, the separator renders as expected. However, when the same kind of menu is returned from the Finder Sync extension, the separator appears as a blank/full-height empty row rather than a thin dividing line. Example: override func menu(for menuKind: FIMenuKind) -> NSMenu { let menu = NSMenu(title: "") menu.addItem(NSMenuItem( title: "First Action", action: #selector(firstAction(_:)), keyEquivalent: "" )) menu.addItem(NSMenuItem.separator()) menu.addItem(NSMenuItem( title: "Second Action", action: #selector(secondAction(_:)), keyEquivalent: "" )) return menu } Expected result: The separator should render as a normal macOS menu separator line between the two menu items. Actual result: In Finder’s context menu, the separator is displayed as blank vertical space / an empty menu row. I understand that Finder Sync menus are rendered by Finder and may not support every NSMenuItem feature. However, NSMenuItem.separator() is a very standard way to visually group menu commands, so I wanted to ask: Is this a known limitation of Finder Sync extension menus? Is there a supported way to display a real separator line in Finder Sync context menus? Should this be filed as a Feedback Assistant issue against Finder Sync / AppKit? I’m trying to avoid fake separators such as disabled menu items with "────" as the title, since that does not feel native and may not behave well with different fonts, accessibility settings, or appearance modes. Thanks!
Replies
0
Boosts
0
Views
300
Activity
Jun ’26
Does @IBSegueAction still not work for AppKit relationship segues from NSWindowController?
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.
Replies
2
Boosts
0
Views
876
Activity
Jun ’26
Apple Developer Program? Nah,
Why should we get apple developer program for appkit and to publish apps?
Replies
0
Boosts
0
Views
170
Activity
Jun ’26
NSTableView: checking for mouse-driven selection changes on macOS 27
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!
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
8
Boosts
0
Views
442
Activity
Jun ’26
IKPictureTaker shows blank panel on macOS 26 — popUpRecentsMenu silently fails with no callback
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?
Replies
3
Boosts
0
Views
604
Activity
Jun ’26
How to override NSTextView dragging behaviour without overriding mouseDown:?
I have an NSTextView subclass that overrides mouseDown: to allow for image resizing. If a user clicks and drags on the edges of an image, I implement custom behaviour that resizes the image (and shows resizing cursors). If the user clicks anywhere else, super's implementation is called. This all works great. As of macOS 27, however, the transition to gesture recognisers instead of overriding mouseDown: means that I should probably be moving away from the above approach. NSTextView now uses the new NSTextSelectionManager to implement selection and dragging via gesture recognisers, although, according to the release notes: Existing NSTextView subclasses that override mouseDown: continue to work through a binary-compatible fallback path. (163365571) It's unclear whether this means that we therefore should still override mouseDown: for custom behaviour in NSTextView, but to me, this, along with the content of Tech Note TN3212, strongly implies that, although it will continue to work thanks to "a binary-compatible fallback", we should entirely move away from overriding mouseDown: in the future. If that is indeed the case, how do we implement custom dragging behaviour--such as for resizing images as in my example--in NSTextView? There still seems to be no way of doing it other than overriding mouseDown:. I had thought that I might be able to add an NSPanGestureRecognizer to the text view and have it fail via its delegate methods if the clicks were outside of an image's edges, but a pan gesture recogniser added to an NSTextView is entirely ignored, presumably because of the private gestures already added. Fortunately everything continues to work for now, but I would like to update my code as much as possible.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
4
Boosts
0
Views
398
Activity
Jun ’26
NSTextView.menuForEvent - getting the affected range on macOS 27
I have an NSTextView subclass that replaces the standard context menu with a custom one by building its own menu in an menuForEvent: override. The context menu that is shown depends on what is selected in the text view, so it checks the current selectedRange to determine which commands should be included. (I could do much the same via the NSTextViewDelegate method textView(_:menu:for:at:), but since my text view subclass is used in several areas, each with their own delegate, it's better to do it in menuForEvent(_:).) This has all worked fine for years, but with NSTextView's transition to gesture recognisers and NSTextSelectionManager for handling text selections in macOS 27, the timings have changed. Previously, if you Ctrl-clicked on a word so that the word is selected and the context menu appears, setSelectedRanges:affinity:stillSelecting: would be called first and then menuForEvent: would be called. On macOS 27, however, the order of events is reversed: menuForEvent: is called first, before setSelectedRanges:affinity:stillSelecting:. (If you implement NSMenuDelegate.menuNeedsUpdate:, that is also called before setSelectedRanges:....) This means that you can no longer rely on selectedRanges in menuForEvent:, because on macOS 27, selectedRanges in menuForEvent: represents the previous selection, not the selection you will actually see on screen when the menu appears. This makes building a custom context menu somewhat tricky. I suspect this is a bug and have reported it as such (FB23251873, with apologies to the engineers for the pleading tone in that report; it was at the end of a long week of getting my head around the gesture recogniser changes. :) ). But it occurs to me that there is nothing in the documentation that guarantees that selectedRanges will be accurate in menuForEvent:; it's just always worked this way. So am I missing something here? Is there a better or more reliable way of getting the range that will be affected by the contextual menu in NSTextView? (The delegate method only provides a single character index, which isn't enough information for spelling corrections and such which require a range.) My current workaround is to rebuild the context menu in setSelectedRanges:affinity:stillSelecting: if it is called between menuForEvent: and didCloseMenu:withEvent:.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
2
Boosts
0
Views
329
Activity
Jun ’26
How do you correctly use a SwiftUI View inside an NSToolbarItem?
I've been struggling to get consistent UI and UX behaviour of SwiftUI Views inside NSToolbarItems and was wondering if there is an official way to use them. I've now revisited this issue in macOS 27 and continue to see some idiosyncrasies. In the attached screenshot, you can see that the highlight area on mouse down between to the two buttons is different. This is the easiest example I've come up with that shows SwiftUI Views exhibiting different behaviour than AppKit Views. Two questions: Is an NSHostingView a valid and supported view type for NSToolbarItem.view? If so, are there any rules that govern how the SwiftUI view should be configured? (ex: frame, sizing options, supported SwiftUI Views, preferred "root view" types, etc?) Sample code that created the two NSToolbarItem buttons in the screenshot. macOS 27 ZY21R0CMGL (Public Beta 1) Xcode 27.0 beta Minimum Deployment target: 27.0 // Left-Top SwiftUI Button (Clipped Highlighting) let item = NSToolbarItem(itemIdentifier: itemIdentifier) let rootView = Button { } label: { Image(systemName: "sidebar.trailing") } item.view = NSHostingView(rootView: rootView) // ... snip .. // Right-Bottom AppKit Button (Correct Highlighting) let item = NSToolbarItem(itemIdentifier: itemIdentifier) item.image = NSImage(systemSymbolName: "sidebar.trailing", accessibilityDescription: nil) Both screenshots are taken on mouse down.
Replies
2
Boosts
0
Views
246
Activity
Jun ’26
Annoying popup window in Xcode Previews when the initial controller of the main storyboard is a macOS window
I started a project targeting macOS and used Storyboard app lifecycle. I also used Xcode Previews in this project. If I: Keep the entry point of the main storyboard to a window controller. (as default setup in macOS), Turn the Xcode window into full-screen, That window controller would pop up its window every time Xcode Previews refreshes. I tested in Xcode 26.3 RC and many versions before.
Replies
7
Boosts
0
Views
471
Activity
Jun ’26