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

AppKit Documentation

Posts under AppKit subtopic

Post

Replies

Boosts

Views

Activity

Repeated Swift error breakpoint stops in system frameworks during AppKit startup and window creation
I debug an Objective-C++ AppKit application in CLion. The application runs normally, but a “When any is thrown” breakpoint stops repeatedly during startup and window creation, making it difficult to debug. One stop occurs before any window is created: [NSApplication run] → finishLaunching → _customizeMainMenu → [NSTextView _supportsWritingTools] → GenerativeModels → JSONDecoder → swift_willThrow. LLDB identifies a decoding frame as GenerativeModels.AvailabilityStore.ReadinessEntry.Criteria.init(from:). Other stops occur while NSDocumentController attempts to reopen documents, and while AppKit resets gesture recognizers during NSWindow creation. All the supplied stops reach swift_willThrow; the app continues after resuming. Are these expected handled errors? Is there a supported way to prevent the startup Writing Tools check from throwing? I can provide the complete stacks and a minimal reproduction if helpful. I'm on MacOS Tahoe 26.6.2 (25G83) Xcode 26.4.1 - Build version 17E202 Apple clang version 21.0.0 (clang-2100.0.123.102) I'm building from within CLion 2026.2.3 and using the bundled LLDB (21.1.7), but the problem also occurs when using the one from XCode (21.0) Disabling Apple Intelligence in the OS settings does not help.
Topic: UI Frameworks SubTopic: AppKit
0
0
27
1d
CALayer with valid contents and correct configuration is excluded from window compositing on Apple Silicon (works fine on Intel)
macOS/Hardware details: macOS version: 27.0 (build 26A428) Hardware: Apple Silicon Mac (arm64) App architecture: Native arm64 Xcode/SDK: Built against MacOSX27.0 SDK Deployment target: MACOSX_DEPLOYMENT_TARGET = 26.0 Regression history: Same app/codebase previously built and ran correctly on macOS 13 (Ventura), Intel — issue only appears after migrating the build to Apple Silicon; no changes were made to the affected view's drawing or layer-configuration code between the two builds We have a custom, layer-backed NSView (part of a hand-rolled tree/list control that draws its own content via Core Graphics into the layer's contents) that renders completely blank on screen on Apple Silicon Macs, while an adjacent sibling view using the identical view class, drawing code, and layer configuration renders correctly. Using lldb and Xcode's View Debugger against the live process, we've confirmed: The layer's actual backing content is correct: capturing it directly via -renderInContext: produces the expected fully-drawn image (text and icons all present). Every inspectable property of the broken view/layer (hidden, alphaValue, opaque, wantsLayer, isFlipped/isGeometryFlipped, zPosition, masksToBounds, contentsScale, mask, transform, backgroundColor, contents, sublayers, superlayer) is identical to the working sibling view — no configuration difference exists anywhere. The layer's superlayer link is intact and points to the correct parent, ruling out a detached/orphaned layer. Standard remediation attempts — setNeedsDisplay:, displayIfNeeded, toggling wantsLayer, detaching/reattaching the view from its superview, changing zPosition — all have zero effect. Most notably, directly setting layer.backgroundColor to an opaque solid color on the live, correctly-connected layer (verified via property readback) produces no visible change on screen at all. Because even an unconditional background color change is not reflected, the layer appears to be excluded from what's actually sent to the window server for compositing, rather than simply failing to draw updated content. Since all inspectable state is correct and identical to a working sibling view, we've been unable to identify any application-level cause. The view remains fully interactive — clicks and hit-testing resolve correctly to the right underlying data — only the visual output is missing. Are there known Apple Silicon-specific changes to CALayer/NSView compositing (window server layer inclusion, contentsScale/backing-store allocation, or layer-backed view promotion) that could cause a fully valid, connected CALayer with correct contents to be silently dropped from the composited frame? Any suggestions for further diagnostic tools (e.g. Quartz Debug, CARenderServer logging, or WindowServer compositing traces) to narrow this down further would help.
Topic: UI Frameworks SubTopic: AppKit
0
0
13
1d
App Exposé swipe and Control–Down differ for accessory apps on macOS 27
On macOS 27.0 (26A428), Apple silicon, a physical four-finger App Exposé swipe does not expose my active AppKit accessory application's windows, including its Settings window. Control–Down does. Filed as FB24919003. I narrowed the behavior down with a two-window AppKit probe and a main menu. In an automated comparison using the same synthetic system gesture sequence each time, .accessory selected the previously active regular application's windows, .regular selected the probe's windows, and switching back to .accessory restored the mismatch. A separately generated Control–Down selected the accessory probe correctly. I activated the other regular app and then reactivated the probe before each comparison. The probe comparison did not test physical finger recognition. The macOS release that introduced this behavior is unconfirmed. The sample below uses only public AppKit APIs and is simplified from the tested probe; it compiles but has not yet been live-tested. It has no gesture recognizers, event taps, global shortcuts, custom window subclasses, or AltTab implementation. Steps for a physical-trackpad comparison: Enable the four-finger downward App Exposé gesture and Control–Down for Application windows in System Settings. Launch the sample in accessory mode and leave both windows open. Click another regular app's window, then click the sample's first window. Swipe down. Record which app's windows appear, then press Escape. Repeat the other-app → sample activation sequence, press Control–Down, record the result, then press Escape. Choose Use regular mode, repeat the activation sequence, and test again. Choose Use accessory mode, repeat the activation sequence, and test again. Start each invocation with App Exposé closed. Reactivation after each mode change matters for the comparison. Apple's window-management guide presents the swipe and Control–Down as ways to show the current app's windows. Is there a supported configuration that makes an accessory app participate in the gesture path while preserving .accessory and avoiding a Dock icon? Has anyone compared this on macOS 26 and 27? The Feedback report contains the exact tested probe as well as this simplified source. Here is the complete simplified sample, using only public AppKit APIs. Save it as AccessoryExposeSample.swift: import Cocoa final class AppDelegate: NSObject, NSApplicationDelegate { private var windows = [NSWindow]() private let modeLabel = NSTextField(labelWithString: "Activation policy: accessory") func applicationDidFinishLaunching(_ notification: Notification) { installMenu() for index in 0..<2 { addWindow(index) } windows[0].makeKeyAndOrderFront(nil) NSApp.activate(ignoringOtherApps: true) } private func installMenu() { let menu = NSMenu() let item = NSMenuItem() let submenu = NSMenu(title: "AccessoryExposeSample") submenu.addItem(withTitle: "Quit AccessoryExposeSample", action: #selector(NSApplication.terminate(_:)), keyEquivalent: "q") item.submenu = submenu menu.addItem(item) NSApp.mainMenu = menu } private func addWindow(_ index: Int) { let window = NSWindow(contentRect: NSRect(x: 100 + index * 480, y: 240, width: 460, height: 280), styleMask: [.titled, .closable, .miniaturizable], backing: .buffered, defer: false) window.title = "Accessory Exposé Sample \(index + 1)" window.isReleasedWhenClosed = false let stack = NSStackView() stack.orientation = .vertical stack.spacing = 16 stack.frame = NSRect(x: 20, y: 20, width: 420, height: 240) if index == 0 { stack.addArrangedSubview(modeLabel) stack.addArrangedSubview(NSButton(title: "Use accessory mode", target: self, action: #selector(useAccessoryMode))) stack.addArrangedSubview(NSButton(title: "Use regular mode", target: self, action: #selector(useRegularMode))) } else { stack.addArrangedSubview(NSTextField(labelWithString: "Second ordinary titled window")) } let reminder = NSTextField(wrappingLabelWithString: "Before each test, click another regular app, then click this window. After changing modes, repeat that activation sequence. Compare a downward App Exposé swipe with Control–Down.") reminder.preferredMaxLayoutWidth = 400 stack.addArrangedSubview(reminder) window.contentView?.addSubview(stack) windows.append(window) window.orderFront(nil) } @objc private func useAccessoryMode() { setPolicy(.accessory) } @objc private func useRegularMode() { setPolicy(.regular) } private func setPolicy(_ policy: NSApplication.ActivationPolicy) { guard NSApp.setActivationPolicy(policy) else { modeLabel.stringValue = "Activation policy change failed" return } modeLabel.stringValue = policy == .accessory ? "Activation policy: accessory" : "Activation policy: regular" windows[0].makeKeyAndOrderFront(nil) NSApp.activate(ignoringOtherApps: true) } } let application = NSApplication.shared application.setActivationPolicy(.accessory) let delegate = AppDelegate() application.delegate = delegate application.run() To build a standalone app bundle with a matching Swift compiler and macOS SDK selected: mkdir -p AccessoryExposeSample.app/Contents/MacOS "$(xcrun --find swiftc)" -swift-version 5 -sdk "$(xcrun --sdk macosx --show-sdk-path)" AccessoryExposeSample.swift -o AccessoryExposeSample.app/Contents/MacOS/AccessoryExposeSample cat > AccessoryExposeSample.app/Contents/Info.plist <<'PLIST' <?xml version="1.0" encoding="UTF-8"?> <plist version="1.0"><dict> <key>CFBundleIdentifier</key><string>local.apple-feedback.accessory-expose-sample</string> <key>CFBundleExecutable</key><string>AccessoryExposeSample</string> <key>CFBundleName</key><string>AccessoryExposeSample</string> <key>CFBundlePackageType</key><string>APPL</string> <key>LSUIElement</key><true/> </dict></plist> PLIST open AccessoryExposeSample.app
0
0
34
2d
Equivalent of coalescedTouchesForTouch in AppKit?
This method on UIEvent gets you more touch positions, and I think it's useful for a drawing app, to respond with greater precision to the position of the Pencil stylus. Is there a similar thing in macOS, for mouse or tablet events? I found this property mouseCoalescingEnabled, but the docs there don't describe how to get the extra events.
Topic: UI Frameworks SubTopic: AppKit Tags:
3
1
501
2d
NSColorSampler can leave ColorSampler.xpc capturing all mouse clicks after the host app quits
I encountered a severe NSColorSampler failure on macOS 27.0 (26A5425a). After invoking: NSColorSampler().show { selectedColor in // Handle selected colour } the system colour sampler became stuck. The pointer disappeared and all mouse clicks were captured across macOS. Pressing Escape did not recover it. Quitting the host application also did not restore clicking. The Apple-owned process remained active after the application exited: /System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/ColorSampler.xpc/Contents/MacOS/ColorSampler Sending SIGTERM to that process had no effect. Force-terminating it with SIGKILL immediately restored mouse clicking. Environment: macOS 27.0, build 26A5425a MacBook Pro Mac16,8 Apple M4 Pro SwiftUI content hosted inside a borderless AppKit window Expected behaviour: selecting a colour, pressing Escape, or terminating the host application should cancel sampling and release all captured input. Actual behaviour: ColorSampler.xpc survives the host application and continues preventing all mouse clicks system-wide. Feedback Assistant report: FB24722293 Has anyone else reproduced this with NSColorSampler, particularly from a borderless AppKit window?
1
0
420
6d
Warning Every time NSPopover closes on Golden Gate "Invalid attempt to open a new transaction during CA commit. This is likely to break AppKit transactional behavior. Break on NSCGSTransactionCreatedDuringCommitError to debug."
This warning logs out every time an NSPopover animates closed on macOS Golden Gate: Warning: Invalid attempt to open a new transaction during CA commit. This is likely to break AppKit transactional behavior. Break on NSCGSTransactionCreatedDuringCommitError to debug. I set the breakpoint but am unable to see anything useful. I hit _NSReturnCarbonMenu () just about every second with that breakpoint enabled and a bunch of lldb_unnamed_symbols. Anyone else seeing this? Doesn't seem to be causing any issues but logs so often it is impossible to completely ignore.
1
0
388
1w
NSTextView.shouldDrawInsertionPoint doesn't work with TextKit 2
The following code only ever causes shouldDrawInsertionPoint to be printed (no drawInsertionPoint), but even if that method returns false, the blinking insertion point is still drawn. On the other hand, with TextKit 1 it works as expected. Is there a way to hide the default insertion point in TextKit 2? My app draws its own. I've filed FB13684251. class TextView: NSTextView { override var shouldDrawInsertionPoint: Bool { print("shouldDrawInsertionPoint") return false } override func drawInsertionPoint(in rect: NSRect, color: NSColor, turnedOn flag: Bool) { print("drawInsertionPoint", flag) } } ``
Topic: UI Frameworks SubTopic: AppKit Tags:
12
0
1.1k
1w
NSTrackingSeparatorToolbarItem causes white bar over top of content in macOS 27 developer beta 5
macOS 27 developer beta 5 introduces a bug where an NSTrackingSeparatorToolbarItem in a toolbar causes a bar to appear under the toolbar, overlaying the content. I have a blog post about this at: https://www.virtualsanity.com/202608/nstrackingseparatortoolbaritem-causes-white-bar-over-top-of-content-in-macos-27-developer-beta-5/ I reported this as FB24266969. A sample project and a screenshot are included in both the blog post and the feedback report.
Topic: UI Frameworks SubTopic: AppKit Tags:
7
1
645
1w
Bug or Feature: Changes to Window Reopen Behavior in macOS 26
Since macOS 26 Beta 1, I notice that the window reopening behavior had changed. Say there are two desktops (spaces), one might: open an app window in desktop 1 close that window switch to desktop 2 reopen the app window (by click on dock tile, spotlight search...) Prior to macOS 26, that window will always reopen in current desktop. This is IMO the right behavior because these windows are most likely transient (message app, chat app, utilities app or note app). In macOS 26, however, will switch to desktop 1 (where the window is closed) and reopen the window in desktop 1. This is weird to me because: Window is "closed", hence it should not be attached to desktop 1 anymore, unlike minimize. Switching desktop interrupts user's current workflow. It's annoying to switch back specially when there're many desktops. This behavior is inconsistent. Some reopen in current desktop, some reopen in previous desktop. Apps like Music, Notes and Calendar reopened in previous desktop, while Mail, Messages, and Freeform reopened in current desktop. I did a little bit of experiment, and find out that apps that reopened in current desktop are most likely because they take an extra step to release the window when it's closed. I believe this is a bug, so I fire a feedback (FB18016497) back in beta 1. But I did not get any response or similar report from others, to a point that I kinda wonder if this is intended. I can easily force my app to reopen in current desktop by nullifying my window controller in windowWillClose, but this behavior essentially change how one can use the Spaces feature that I think I should bring this up to the community and see what other developers or engineers thinks about it.
Topic: UI Frameworks SubTopic: AppKit Tags:
5
1
625
1w
Spotlight Shows "Helper Apps" That Are Inside Main App Bundle That Are Not Intended to Be Launched By The User
I have Mac apps that embed “Helper Apps” inside their main bundle. The helper apps do work on behalf of the main application. The helper app doesn’t show a dock icon, it does show minimal UI like an open panel in certain situations (part of NSService implementation). And it does make use of the NSApplication lifecycle and auto quits after it completes all work. Currently the helper app is inside the main app bundle at: /Contents/Applications/HelperApp.app Prior to Tahoe these were never displayed to user in LaunchPad but now the Spotlight based AppLauncher displays them. What’s the recommended way to get these out of the Spotlight App list on macOS Tahoe? Thanks in advance.
8
0
850
1w
Title bar double-click / Fill on macOS 27
I’m seeing a reproducible title-bar interaction issue on macOS 27 RC (26A428). This issue has been present since at least macOS 27 build 26A5416b (Developer Beta 6 / Public Beta 4) and is still reproducible on the Release Candidate, build 26A428. My System Settings → Desktop & Dock → Window title bar double-click action is configured to Fill. In several system apps with sidebars, including: Finder System Settings Reminders Feedback Assistant the right side of the title bar shows a visible rectangular region when the pointer hovers over it. The more important problem is that the middle portion of this region appears to intercept the title-bar double-click. Double-clicking there does nothing, while double-clicking very close to the top or bottom edge of the same region correctly triggers Fill. This makes the normal title-bar gesture surprisingly difficult to use because the center of the title bar is naturally where I would double-click. Interestingly, the sidebar area does not have this problem: double-clicking the top, middle, or bottom portions of the sidebar title-bar area all works normally. Feedback Assistant makes the behavior particularly easy to see because its left sidebar and rightmost pane behave normally, while the title-bar region above the middle pane exhibits the problem. Steps to reproduce: Set “Double-click a window’s title bar” to Fill in Desktop & Dock settings. Open Finder, System Settings, Reminders, or Feedback Assistant. Move the pointer over the right/content portion of the title bar until the rectangular hover region appears. Double-click around the center of that region. The Fill action does not occur. Double-click very close to the upper or lower edge of the same region. Fill works normally. I have reproduced this on macOS 27 RC build 26A428, including: a newly created macOS user account Safe Mode so it does not appear to be caused by migrated preferences, caches, login items, or third-party software. A screen recording demonstrating the exact hit-testing behavior was submitted through Feedback Assistant. Feedback: FB24462749 Is anyone else able to reproduce this? It looks as though some view or overlay in the new title-bar/toolbar area may be intercepting mouse events.
1
0
263
2w
crash when trying to show NSAlert with Mac 27 beta with European and russian languages
Feedback Assistant Submission ID Reference : FB24634485 Attached is a sample code where after setting setlocale() to any of European languages or Russian language results in crash when calling NSAlert. Here is code snippet and crash log for reference. #import <Cocoa/Cocoa.h> int main(int argc, const char * argv[]) { @autoreleasepool { NSString* locale = @“fr_FR.UTF8"; setlocale(LC_ALL, locale.UTF8String); return NSApplicationMain(argc, argv); } } (IBAction)showAlertButtonTapped:(id)sender { NSAlert *alert = [[NSAlert alloc] init]; alert.messageText = NSLocalizedString(@"alert_title", nil); alert.informativeText = NSLocalizedString(@"alert_message", nil); alert.alertStyle = NSAlertStyleInformational; [alert addButtonWithTitle:NSLocalizedString(@"alert_ok_button", nil)]; [alert runModal]; } Crashlog
0
0
157
2w
Empty small white window appears
I recently ported my app from the Sequoia SDK to the Tahoe SDK. The app is written in Objective C and does not use ARC. Everything works well after the major cleanup, except .... A times I see a small empty window pop up. Clicking out of the application usually gets rid of it. I can make it happen fairly regularly on an displayed sheet which presents two NSImageView objects. The user clicks on a button which displays a popup menu; modifies an image then applies the results to one or both of the image views. Having spent two days on this it seems as if the actual setImage on the image view is causing the popup. If I cut out the setImage, it never happens ... even with all other steps in place. I've disabled all animations and tried dozens of things all to no avail. It is not consistent but I can make it happen on two Macs (both running Tahoe). It never happens on Sequoia or earlier when running the build produced with the Tahoe SDK. Any suggestions would be appreciated.
Topic: UI Frameworks SubTopic: AppKit
1
0
606
Aug ’26
How to force the temporary fullscreen sidebar as overlay?
My app uses an NSSplitViewController with three vertical split-view items: A sidebar created using +[NSSplitViewItem sidebarWithViewController:] The main content An inspector-like pane Through macOS Sequoia, it always had the following fullscreen sidebar behavior: (The sidebar was collapsed.) Moving the pointer to the left edge of the screen temporarily revealed it. The sidebar appeared as an overlay. The main content and inspector retained their existing frames. After building with the Golden Gate SDK, the temporarily revealed sidebar no longer behaves as an overlay. Depending on minimumThickness and maximumThickness of the items, this either resizes the main content or shifts the complete remaining layout to the side. The resulting animation also stutters because the content is laid out for every intermediate width. Explicitly toggling the sidebar using -[NSSplitViewController toggleSidebar:] is a different case and works correctly in my app. The problem specifically concerns only the automatic, temporary fullscreen reveal initiated by moving the pointer to the screen edge. I want that to remain as an overlay. I have experimented with the split-view items’ holdingPriority, minimumThickness, maximumThickness, minimumThicknessForInlineSidebars and collapseBehavior, but have not found a way to restore the previous overlay behavior. Any ideas how to do that? Thanks a lot!
Topic: UI Frameworks SubTopic: AppKit
2
0
146
Aug ’26
NSTextView Weird Selection Behavior with NSTextAttachmentCells
I have an NSTextView that displays several NSTextAttachmentCells. I notice this weird behavior. Sometimes if I just click in an empty area of the text view the entire text content selects. So I implemented the delegate method to catch it: - (NSRange)textView:(NSTextView *)textView willChangeSelectionFromCharacterRange:(NSRange)oldSelectedCharRange toCharacterRange:(NSRange)newSelectedCharRange { if (newSelectedCharRange.length > 1 && newSelectedCharRange.length > oldSelectedCharRange.length) { NSEvent *currentEvent = NSApp.currentEvent; NSLog(@"Selection expanded from %@ to %@. Event type: %ld, click count: %ld, modifier flags: %lu, current selected ranges: %@", NSStringFromRange(oldSelectedCharRange), NSStringFromRange(newSelectedCharRange), (long)currentEvent.type, (long)currentEvent.clickCount, (unsigned long)currentEvent.modifierFlags, self.selectedRanges); // put a break point here. } return newSelectedCharRange; } And I reproduced the issue and this logs out: Selection expanded from {0, 0} to {0, 6}. Event type: 2, click count: 1, modifier flags: 0, current selected ranges: ( "NSRange: {0, 6} Click count is only 1 so I didn't accidentally triple click. I know on Golden Gate use of NSEvent.currentEvent isn't the way (but I'm not there yet). A simple workaround would be to block the selection right here in the delegate method when clickCount != 3 (but again I know NSEvent.currentEvent in Golden Gate won't be reliable). Anyone run into this and have any ideas? It seems to happen after I did a triple click in the text view at some point previously (but not this click). So I got the feeling that maybe the text view isn't resetting some private properties and is treating this single click as a triple click. But I really don't know. Edit: Hmm maybe it has nothing to do with a previous triple click. May have to do with text selection not accounting for the geometry of the NSTextAttachmentCells. Not sure. But I still have to figure out a way to workaround this because a random select all is really annoying! Call stack looks like: ** -[MyTextView textView:willChangeSelectionFromCharacterRange:toCharacterRange:] at MyTextView.m -[NSTextView(NSSharing) setSelectedRanges:affinity:stillSelecting:] () -[MyTextView setSelectedRanges:affinity:stillSelecting:] MyTextView.m +[NSInputAnalytics(TrackedActionsManager) allowActionTrackingAnalyticsWithName:forAction:] () n -[NSTextView mouseDown:] () -[MyTextView mouseDown:] ** If you're wondering what my -mouseDown: override does it just calls super. I realize this is not a whole lot to go on but any help would be appreciated.
5
0
633
Aug ’26
WKWebView+Purch+StoreKit=Deadend
Does anyone have any advice on working a way around this, or through this? My app is wrapped and WKWebView displays HTML/CSS/JAVA and StoreKit is iOS framework. I used choicely up wrap it because i don't own a mac. The only part i can't control is this. I'll likely have to wrap it myself, rent a cloud Mac and submit directly to ensure everything is attached to the binary. I can't control that from choicely. any other ideas!? I’ve been over a month trying to get this going. It’s live but with no way to transact the subscribers I’m already getting. HELP PLEASE!
0
0
373
Aug ’26
NSToolbarItemViewer no longer resolves hit-testing to a view-based NSToolbarItem's subviews — interactive controls in custom toolbar item views receive no mouse events (regression in macOS 27 beta)
Area: AppKit / NSToolbar Type: Incorrect/Unexpected Behavior (Regression) Summary On macOS 27 beta, when an NSToolbarItem uses a custom view (NSToolbarItem.view) containing interactive controls (e.g. NSButton), clicks on those controls are silently swallowed. Window-level hit-testing stops at the private NSToolbarItemViewer instead of descending into the item's view hierarchy, so the controls never receive mouseDown and their target/action never fires. The same code works correctly on macOS 26 and earlier. This breaks the long-standing, documented view-based toolbar item pattern. Any app that places custom interactive controls inside toolbar items is affected. Steps to Reproduce Create a window with an NSToolbar. In toolbar(_:itemForItemIdentifier:willBeInsertedIntoToolbar:), return an NSToolbarItem whose view is a container NSView holding an NSButton with a target/action. Run on macOS 27 beta and click the button. Minimal repro (complete AppDelegate): import Cocoa @main class AppDelegate: NSObject, NSApplicationDelegate, NSToolbarDelegate { var window: NSWindow! func applicationDidFinishLaunching(_ notification: Notification) { window = NSWindow(contentRect: NSRect(x: 200, y: 200, width: 600, height: 400), styleMask: [.titled, .closable, .resizable], backing: .buffered, defer: false) let toolbar = NSToolbar(identifier: "Main") toolbar.delegate = self window.toolbar = toolbar window.makeKeyAndOrderFront(nil) } func toolbar(_ toolbar: NSToolbar, itemForItemIdentifier id: NSToolbarItem.Identifier, willBeInsertedIntoToolbar flag: Bool) -> NSToolbarItem? { let item = NSToolbarItem(itemIdentifier: id) let container = NSView(frame: NSRect(x: 0, y: 0, width: 120, height: 28)) let button = NSButton(title: "Click Me", target: self, action: #selector(clicked)) button.frame = container.bounds container.addSubview(button) item.view = container return item } @objc func clicked() { NSLog("BUTTON CLICKED") } // never logged on macOS 27 beta func toolbarDefaultItemIdentifiers(_ toolbar: NSToolbar) -> [NSToolbarItem.Identifier] { [NSToolbarItem.Identifier("CustomItem")] } func toolbarAllowedItemIdentifiers(_ toolbar: NSToolbar) -> [NSToolbarItem.Identifier] { toolbarDefaultItemIdentifiers(toolbar) } } Expected Results: Clicking the button highlights it and fires its action, as on macOS 26 and every earlier release: window hit-testing resolves to the NSButton inside the toolbar item's custom view. Actual Results The click is silently consumed. The button never receives mouseDown, its action never fires, and no toolbar item action is sent either (the item is view-based and has no target/action of its own). Diagnostic Evidence We instrumented hitTest(_:) throughout the hierarchy in our production app and observed, for a single leftMouseDown over the button: The custom subview's own hitTest is invoked during the traversal and correctly returns the NSButton. However, hit-testing initiated from the window's frame view (NSThemeFrame) resolves to NSToolbarItemViewer itself — the subview's result is discarded on the way up. Observed hit path: NSToolbarItemViewer <- NSToolbarView <- NSTitlebarView <- NSTitlebarContainerView <- NSThemeFrame Consequently AppKit dispatches mouseDown to NSToolbarItemViewer, which does nothing for a view-based item, and the event is dropped. This looks like an extension of the macOS 26 beta issue where NSGlassContainerView inside NSToolbarView intercepted hit-testing over the title bar (FB18201935, developer forums thread 788928). On macOS 27 the interception now also applies inside NSToolbarItemViewer for view-based items. Impact All interactive controls hosted in view-based toolbar items are unusable: buttons, search fields, segmented controls, etc. In our production app (RingCentral Video, a video-conferencing client), every in-meeting title-bar control (meeting info, network quality, view switcher, report) stopped responding on macOS 27 beta. We have shipped an application-level workaround that re-dispatches the event to the control when window hit-testing terminates at an ancestor of it, but this requires every affected app to implement custom event routing around a private view's behavior. FB24375035
Topic: UI Frameworks SubTopic: AppKit
1
0
141
Aug ’26
Custom pointer color makes -[NSCursor set] re-render from PDF on every call, pinning a CPU core across unrelated apps (macOS 27.0)
Filed as FB24344519. Posting here too because the scope is wider than any single app, and other developers may be getting "your app uses too much CPU" reports that are not actually their bug. Environment: macOS 27.0 (26A5406e), Apple Silicon (M5 Max). SUMMARY When a custom pointer color is set, every -[NSCursor set] call re-renders the pointer artwork from a PDF, with no caching. Any app whose UI frequently invalidates AppKit tracking areas then burns most of a CPU core continuously, with the mouse completely stationary. Trigger: defaults read com.apple.universalaccess cursorIsCustomized 1 That is System Settings > Accessibility > Display > Pointer, with a custom fill and outline color set. With default pointer colors, -[NSCursor set] is nearly free. CALL PATH (sampled with the mouse untouched) CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK -[_NSTrackingAreaAKManager _activeTrackingAreasNeedUpdate]_block_invoke -[_NSTrackingAreaAKManager _updateActiveTrackingAreasForWindowLocation:modifierFlags:] -[NSCursor set] -[NSCursor _reallySet] _AXFCursorSetAndReturnSeed (AccessibilityFoundation) -[_AXFMouseCursorGenerator createImageForScale:] -[_AXFMouseCursorGeneratorLayer _createImageForScale:color:] -[_AXFMouseCursorGeneratorLayer _pdfPage] / _pdf CGPDFScannerScan -> CGPDFDrawingContextDrawPath createImageWithSizeRenderInstructions __createImageWithMaskedColor_block_invoke CGContextClipToMask -> CGContextDrawImage -> A8_image_mark_rgb32 The pointer artwork is re-parsed from PDF and re-composited on every tracking-area update. SCOPE Main-thread samples in that path, mouse stationary: com.apple.weather.menu (Catalyst/UIKit): 1170 / 1327 = 88% Cloudflare WARP (Flutter): 1095 / 1154 = 95% Dayflow (SwiftUI/AppKit): 273 / 431 = 63% (bursts) Three unrelated UI toolkits, identical stack, including one of Apple's own menu bar apps. Apps with a mostly static UI are unaffected on the same machine with the same setting enabled, so the amplifier appears to be tracking-area invalidation frequency rather than the toolkit. Direct measurement of WeatherMenu with the trackpad untouched: 21.8 seconds of CPU in a 30 second window (73% of one core), sustained indefinitely, and 491 minutes of CPU time over 3 days of uptime. STEPS TO REPRODUCE System Settings > Accessibility > Display > Pointer. Set a custom pointer fill and outline color. Enable the Weather menu bar item (Control Center > Weather). Leave the machine idle. Do not touch the trackpad or mouse. Watch com.apple.weather.menu in Activity Monitor. Expected: near 0% CPU while idle. -[NSCursor set] with an unchanged cursor should be a cheap no-op. Actual: 65-75% of a core held indefinitely with no user input. CAVEAT I have not toggled cursorIsCustomized back off to confirm the CPU drops, so the dependency is inferred from the stack reaching the custom-color renderer (_createImageForScale:color:, createImageWithMaskedColor), which is only used when a custom pointer color is set. About a minute for anyone to verify. NOTES FOR OTHER DEVELOPERS Two things that cost me time: ps %CPU on macOS is a short decaying average, not steady state. It made an app look like it sat at 80% when its actual idle draw was under 4%. Compare cumulative CPU time deltas instead. sample counts blocked threads too, so "N% of main-thread samples" is not the same as N% CPU. Check whether the leaf frames are actually running code first. If your users report high CPU you cannot reproduce, it may be worth asking whether they have a custom pointer color set. SUGGESTED FIX Cache the generated cursor image in _AXFMouseCursorGenerator, and make -[NSCursor set] a no-op when the cursor and scale are unchanged, rather than re-parsing and re-rendering the PDF on every call. Happy to provide full samples or a sysdiagnose.
Topic: UI Frameworks SubTopic: AppKit
0
0
172
Aug ’26
NSInternalInconsistencyException assertion from [NSRemoteView containingWindowWillOrderOnScreen:] on macOS 27 (26A5378j)
Is anyone else getting these assertion crashes on developer beta 3 of Golden Gate? I've gotten more than a dozen crash logs from users running macOS 27 (26A5378j) that all look like this: assertion failed: '<NSRemoteView: 0x79cb366700 com.apple.SafariPlatformSupport.Helper SPCompletionListServiceViewController> notified of <NSStatusBarWindow: 0x79cbef7480> but expected (null)' in -[NSRemoteView containingWindowWillOrderOnScreen:] on line 4221 of file /AppleInternal/Library/BuildRoots/4~CSuOugB1YCxzYMPRWEumvvfCTNtf98eItTmsbJU/Library/Caches/com.apple.xbs/TemporaryDirectory.N8fh9t/Sources/ViewBridge/NSRemoteView.m but with various windows from my app after "notified of". They're getting thrown when one of my windows is made frontmost, either using NSWindow.orderFrontRegardless or NSWindow.makeKeyAndOrderFront, or (in the case above) when my status item is shown. It's intermittent - I've been unable to reproduce it so far - but definitely happening repeatedly based on my Sentry crash logging. Is this a bug in Golden Gate b3, or am I doing something to provoke this? I've submitted it via Feedback Assistant (FB23642313). Thanks Jon P.S. Full stack trace attached for the exception thrown when the assertion fails for NSStatusBarWindow NSInternalInconsistencyException stack trace.txt
Topic: UI Frameworks SubTopic: AppKit
10
4
1.7k
Aug ’26
Vertically Off-Center Components in NSSearchToolbarItem in macOS 27 Developer Beta 5
In macOS 27 developer beta 5, search fields in toolbars (NSSearchToolbarItem instances) have their placeholder text, search strings, and magnifying glass icons vertically off-center. I reported this as FB24286690. You can see this in the Feedback Assistant app. The “Search” placeholder text, the magnifying glass, and the search string are all closer to the top of the toolbar item than the bottom. My feedback has a sample project demonstrating this, along with screenshots. I have a more detailed writeup at: https://www.virtualsanity.com/202608/vertically-off-center-components-in-nssearchtoolbaritem-in-macos-27-developer-beta-5/
Topic: UI Frameworks SubTopic: AppKit Tags:
0
0
249
Aug ’26
Repeated Swift error breakpoint stops in system frameworks during AppKit startup and window creation
I debug an Objective-C++ AppKit application in CLion. The application runs normally, but a “When any is thrown” breakpoint stops repeatedly during startup and window creation, making it difficult to debug. One stop occurs before any window is created: [NSApplication run] → finishLaunching → _customizeMainMenu → [NSTextView _supportsWritingTools] → GenerativeModels → JSONDecoder → swift_willThrow. LLDB identifies a decoding frame as GenerativeModels.AvailabilityStore.ReadinessEntry.Criteria.init(from:). Other stops occur while NSDocumentController attempts to reopen documents, and while AppKit resets gesture recognizers during NSWindow creation. All the supplied stops reach swift_willThrow; the app continues after resuming. Are these expected handled errors? Is there a supported way to prevent the startup Writing Tools check from throwing? I can provide the complete stacks and a minimal reproduction if helpful. I'm on MacOS Tahoe 26.6.2 (25G83) Xcode 26.4.1 - Build version 17E202 Apple clang version 21.0.0 (clang-2100.0.123.102) I'm building from within CLion 2026.2.3 and using the bundled LLDB (21.1.7), but the problem also occurs when using the one from XCode (21.0) Disabling Apple Intelligence in the OS settings does not help.
Topic: UI Frameworks SubTopic: AppKit
Replies
0
Boosts
0
Views
27
Activity
1d
CALayer with valid contents and correct configuration is excluded from window compositing on Apple Silicon (works fine on Intel)
macOS/Hardware details: macOS version: 27.0 (build 26A428) Hardware: Apple Silicon Mac (arm64) App architecture: Native arm64 Xcode/SDK: Built against MacOSX27.0 SDK Deployment target: MACOSX_DEPLOYMENT_TARGET = 26.0 Regression history: Same app/codebase previously built and ran correctly on macOS 13 (Ventura), Intel — issue only appears after migrating the build to Apple Silicon; no changes were made to the affected view's drawing or layer-configuration code between the two builds We have a custom, layer-backed NSView (part of a hand-rolled tree/list control that draws its own content via Core Graphics into the layer's contents) that renders completely blank on screen on Apple Silicon Macs, while an adjacent sibling view using the identical view class, drawing code, and layer configuration renders correctly. Using lldb and Xcode's View Debugger against the live process, we've confirmed: The layer's actual backing content is correct: capturing it directly via -renderInContext: produces the expected fully-drawn image (text and icons all present). Every inspectable property of the broken view/layer (hidden, alphaValue, opaque, wantsLayer, isFlipped/isGeometryFlipped, zPosition, masksToBounds, contentsScale, mask, transform, backgroundColor, contents, sublayers, superlayer) is identical to the working sibling view — no configuration difference exists anywhere. The layer's superlayer link is intact and points to the correct parent, ruling out a detached/orphaned layer. Standard remediation attempts — setNeedsDisplay:, displayIfNeeded, toggling wantsLayer, detaching/reattaching the view from its superview, changing zPosition — all have zero effect. Most notably, directly setting layer.backgroundColor to an opaque solid color on the live, correctly-connected layer (verified via property readback) produces no visible change on screen at all. Because even an unconditional background color change is not reflected, the layer appears to be excluded from what's actually sent to the window server for compositing, rather than simply failing to draw updated content. Since all inspectable state is correct and identical to a working sibling view, we've been unable to identify any application-level cause. The view remains fully interactive — clicks and hit-testing resolve correctly to the right underlying data — only the visual output is missing. Are there known Apple Silicon-specific changes to CALayer/NSView compositing (window server layer inclusion, contentsScale/backing-store allocation, or layer-backed view promotion) that could cause a fully valid, connected CALayer with correct contents to be silently dropped from the composited frame? Any suggestions for further diagnostic tools (e.g. Quartz Debug, CARenderServer logging, or WindowServer compositing traces) to narrow this down further would help.
Topic: UI Frameworks SubTopic: AppKit
Replies
0
Boosts
0
Views
13
Activity
1d
App Exposé swipe and Control–Down differ for accessory apps on macOS 27
On macOS 27.0 (26A428), Apple silicon, a physical four-finger App Exposé swipe does not expose my active AppKit accessory application's windows, including its Settings window. Control–Down does. Filed as FB24919003. I narrowed the behavior down with a two-window AppKit probe and a main menu. In an automated comparison using the same synthetic system gesture sequence each time, .accessory selected the previously active regular application's windows, .regular selected the probe's windows, and switching back to .accessory restored the mismatch. A separately generated Control–Down selected the accessory probe correctly. I activated the other regular app and then reactivated the probe before each comparison. The probe comparison did not test physical finger recognition. The macOS release that introduced this behavior is unconfirmed. The sample below uses only public AppKit APIs and is simplified from the tested probe; it compiles but has not yet been live-tested. It has no gesture recognizers, event taps, global shortcuts, custom window subclasses, or AltTab implementation. Steps for a physical-trackpad comparison: Enable the four-finger downward App Exposé gesture and Control–Down for Application windows in System Settings. Launch the sample in accessory mode and leave both windows open. Click another regular app's window, then click the sample's first window. Swipe down. Record which app's windows appear, then press Escape. Repeat the other-app → sample activation sequence, press Control–Down, record the result, then press Escape. Choose Use regular mode, repeat the activation sequence, and test again. Choose Use accessory mode, repeat the activation sequence, and test again. Start each invocation with App Exposé closed. Reactivation after each mode change matters for the comparison. Apple's window-management guide presents the swipe and Control–Down as ways to show the current app's windows. Is there a supported configuration that makes an accessory app participate in the gesture path while preserving .accessory and avoiding a Dock icon? Has anyone compared this on macOS 26 and 27? The Feedback report contains the exact tested probe as well as this simplified source. Here is the complete simplified sample, using only public AppKit APIs. Save it as AccessoryExposeSample.swift: import Cocoa final class AppDelegate: NSObject, NSApplicationDelegate { private var windows = [NSWindow]() private let modeLabel = NSTextField(labelWithString: "Activation policy: accessory") func applicationDidFinishLaunching(_ notification: Notification) { installMenu() for index in 0..<2 { addWindow(index) } windows[0].makeKeyAndOrderFront(nil) NSApp.activate(ignoringOtherApps: true) } private func installMenu() { let menu = NSMenu() let item = NSMenuItem() let submenu = NSMenu(title: "AccessoryExposeSample") submenu.addItem(withTitle: "Quit AccessoryExposeSample", action: #selector(NSApplication.terminate(_:)), keyEquivalent: "q") item.submenu = submenu menu.addItem(item) NSApp.mainMenu = menu } private func addWindow(_ index: Int) { let window = NSWindow(contentRect: NSRect(x: 100 + index * 480, y: 240, width: 460, height: 280), styleMask: [.titled, .closable, .miniaturizable], backing: .buffered, defer: false) window.title = "Accessory Exposé Sample \(index + 1)" window.isReleasedWhenClosed = false let stack = NSStackView() stack.orientation = .vertical stack.spacing = 16 stack.frame = NSRect(x: 20, y: 20, width: 420, height: 240) if index == 0 { stack.addArrangedSubview(modeLabel) stack.addArrangedSubview(NSButton(title: "Use accessory mode", target: self, action: #selector(useAccessoryMode))) stack.addArrangedSubview(NSButton(title: "Use regular mode", target: self, action: #selector(useRegularMode))) } else { stack.addArrangedSubview(NSTextField(labelWithString: "Second ordinary titled window")) } let reminder = NSTextField(wrappingLabelWithString: "Before each test, click another regular app, then click this window. After changing modes, repeat that activation sequence. Compare a downward App Exposé swipe with Control–Down.") reminder.preferredMaxLayoutWidth = 400 stack.addArrangedSubview(reminder) window.contentView?.addSubview(stack) windows.append(window) window.orderFront(nil) } @objc private func useAccessoryMode() { setPolicy(.accessory) } @objc private func useRegularMode() { setPolicy(.regular) } private func setPolicy(_ policy: NSApplication.ActivationPolicy) { guard NSApp.setActivationPolicy(policy) else { modeLabel.stringValue = "Activation policy change failed" return } modeLabel.stringValue = policy == .accessory ? "Activation policy: accessory" : "Activation policy: regular" windows[0].makeKeyAndOrderFront(nil) NSApp.activate(ignoringOtherApps: true) } } let application = NSApplication.shared application.setActivationPolicy(.accessory) let delegate = AppDelegate() application.delegate = delegate application.run() To build a standalone app bundle with a matching Swift compiler and macOS SDK selected: mkdir -p AccessoryExposeSample.app/Contents/MacOS "$(xcrun --find swiftc)" -swift-version 5 -sdk "$(xcrun --sdk macosx --show-sdk-path)" AccessoryExposeSample.swift -o AccessoryExposeSample.app/Contents/MacOS/AccessoryExposeSample cat > AccessoryExposeSample.app/Contents/Info.plist <<'PLIST' <?xml version="1.0" encoding="UTF-8"?> <plist version="1.0"><dict> <key>CFBundleIdentifier</key><string>local.apple-feedback.accessory-expose-sample</string> <key>CFBundleExecutable</key><string>AccessoryExposeSample</string> <key>CFBundleName</key><string>AccessoryExposeSample</string> <key>CFBundlePackageType</key><string>APPL</string> <key>LSUIElement</key><true/> </dict></plist> PLIST open AccessoryExposeSample.app
Replies
0
Boosts
0
Views
34
Activity
2d
Equivalent of coalescedTouchesForTouch in AppKit?
This method on UIEvent gets you more touch positions, and I think it's useful for a drawing app, to respond with greater precision to the position of the Pencil stylus. Is there a similar thing in macOS, for mouse or tablet events? I found this property mouseCoalescingEnabled, but the docs there don't describe how to get the extra events.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
3
Boosts
1
Views
501
Activity
2d
NSColorSampler can leave ColorSampler.xpc capturing all mouse clicks after the host app quits
I encountered a severe NSColorSampler failure on macOS 27.0 (26A5425a). After invoking: NSColorSampler().show { selectedColor in // Handle selected colour } the system colour sampler became stuck. The pointer disappeared and all mouse clicks were captured across macOS. Pressing Escape did not recover it. Quitting the host application also did not restore clicking. The Apple-owned process remained active after the application exited: /System/Library/Frameworks/AppKit.framework/Versions/C/XPCServices/ColorSampler.xpc/Contents/MacOS/ColorSampler Sending SIGTERM to that process had no effect. Force-terminating it with SIGKILL immediately restored mouse clicking. Environment: macOS 27.0, build 26A5425a MacBook Pro Mac16,8 Apple M4 Pro SwiftUI content hosted inside a borderless AppKit window Expected behaviour: selecting a colour, pressing Escape, or terminating the host application should cancel sampling and release all captured input. Actual behaviour: ColorSampler.xpc survives the host application and continues preventing all mouse clicks system-wide. Feedback Assistant report: FB24722293 Has anyone else reproduced this with NSColorSampler, particularly from a borderless AppKit window?
Replies
1
Boosts
0
Views
420
Activity
6d
Warning Every time NSPopover closes on Golden Gate "Invalid attempt to open a new transaction during CA commit. This is likely to break AppKit transactional behavior. Break on NSCGSTransactionCreatedDuringCommitError to debug."
This warning logs out every time an NSPopover animates closed on macOS Golden Gate: Warning: Invalid attempt to open a new transaction during CA commit. This is likely to break AppKit transactional behavior. Break on NSCGSTransactionCreatedDuringCommitError to debug. I set the breakpoint but am unable to see anything useful. I hit _NSReturnCarbonMenu () just about every second with that breakpoint enabled and a bunch of lldb_unnamed_symbols. Anyone else seeing this? Doesn't seem to be causing any issues but logs so often it is impossible to completely ignore.
Replies
1
Boosts
0
Views
388
Activity
1w
NSTextView.shouldDrawInsertionPoint doesn't work with TextKit 2
The following code only ever causes shouldDrawInsertionPoint to be printed (no drawInsertionPoint), but even if that method returns false, the blinking insertion point is still drawn. On the other hand, with TextKit 1 it works as expected. Is there a way to hide the default insertion point in TextKit 2? My app draws its own. I've filed FB13684251. class TextView: NSTextView { override var shouldDrawInsertionPoint: Bool { print("shouldDrawInsertionPoint") return false } override func drawInsertionPoint(in rect: NSRect, color: NSColor, turnedOn flag: Bool) { print("drawInsertionPoint", flag) } } ``
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
12
Boosts
0
Views
1.1k
Activity
1w
NSTrackingSeparatorToolbarItem causes white bar over top of content in macOS 27 developer beta 5
macOS 27 developer beta 5 introduces a bug where an NSTrackingSeparatorToolbarItem in a toolbar causes a bar to appear under the toolbar, overlaying the content. I have a blog post about this at: https://www.virtualsanity.com/202608/nstrackingseparatortoolbaritem-causes-white-bar-over-top-of-content-in-macos-27-developer-beta-5/ I reported this as FB24266969. A sample project and a screenshot are included in both the blog post and the feedback report.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
7
Boosts
1
Views
645
Activity
1w
Bug or Feature: Changes to Window Reopen Behavior in macOS 26
Since macOS 26 Beta 1, I notice that the window reopening behavior had changed. Say there are two desktops (spaces), one might: open an app window in desktop 1 close that window switch to desktop 2 reopen the app window (by click on dock tile, spotlight search...) Prior to macOS 26, that window will always reopen in current desktop. This is IMO the right behavior because these windows are most likely transient (message app, chat app, utilities app or note app). In macOS 26, however, will switch to desktop 1 (where the window is closed) and reopen the window in desktop 1. This is weird to me because: Window is "closed", hence it should not be attached to desktop 1 anymore, unlike minimize. Switching desktop interrupts user's current workflow. It's annoying to switch back specially when there're many desktops. This behavior is inconsistent. Some reopen in current desktop, some reopen in previous desktop. Apps like Music, Notes and Calendar reopened in previous desktop, while Mail, Messages, and Freeform reopened in current desktop. I did a little bit of experiment, and find out that apps that reopened in current desktop are most likely because they take an extra step to release the window when it's closed. I believe this is a bug, so I fire a feedback (FB18016497) back in beta 1. But I did not get any response or similar report from others, to a point that I kinda wonder if this is intended. I can easily force my app to reopen in current desktop by nullifying my window controller in windowWillClose, but this behavior essentially change how one can use the Spaces feature that I think I should bring this up to the community and see what other developers or engineers thinks about it.
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
5
Boosts
1
Views
625
Activity
1w
Spotlight Shows "Helper Apps" That Are Inside Main App Bundle That Are Not Intended to Be Launched By The User
I have Mac apps that embed “Helper Apps” inside their main bundle. The helper apps do work on behalf of the main application. The helper app doesn’t show a dock icon, it does show minimal UI like an open panel in certain situations (part of NSService implementation). And it does make use of the NSApplication lifecycle and auto quits after it completes all work. Currently the helper app is inside the main app bundle at: /Contents/Applications/HelperApp.app Prior to Tahoe these were never displayed to user in LaunchPad but now the Spotlight based AppLauncher displays them. What’s the recommended way to get these out of the Spotlight App list on macOS Tahoe? Thanks in advance.
Replies
8
Boosts
0
Views
850
Activity
1w
Title bar double-click / Fill on macOS 27
I’m seeing a reproducible title-bar interaction issue on macOS 27 RC (26A428). This issue has been present since at least macOS 27 build 26A5416b (Developer Beta 6 / Public Beta 4) and is still reproducible on the Release Candidate, build 26A428. My System Settings → Desktop & Dock → Window title bar double-click action is configured to Fill. In several system apps with sidebars, including: Finder System Settings Reminders Feedback Assistant the right side of the title bar shows a visible rectangular region when the pointer hovers over it. The more important problem is that the middle portion of this region appears to intercept the title-bar double-click. Double-clicking there does nothing, while double-clicking very close to the top or bottom edge of the same region correctly triggers Fill. This makes the normal title-bar gesture surprisingly difficult to use because the center of the title bar is naturally where I would double-click. Interestingly, the sidebar area does not have this problem: double-clicking the top, middle, or bottom portions of the sidebar title-bar area all works normally. Feedback Assistant makes the behavior particularly easy to see because its left sidebar and rightmost pane behave normally, while the title-bar region above the middle pane exhibits the problem. Steps to reproduce: Set “Double-click a window’s title bar” to Fill in Desktop & Dock settings. Open Finder, System Settings, Reminders, or Feedback Assistant. Move the pointer over the right/content portion of the title bar until the rectangular hover region appears. Double-click around the center of that region. The Fill action does not occur. Double-click very close to the upper or lower edge of the same region. Fill works normally. I have reproduced this on macOS 27 RC build 26A428, including: a newly created macOS user account Safe Mode so it does not appear to be caused by migrated preferences, caches, login items, or third-party software. A screen recording demonstrating the exact hit-testing behavior was submitted through Feedback Assistant. Feedback: FB24462749 Is anyone else able to reproduce this? It looks as though some view or overlay in the new title-bar/toolbar area may be intercepting mouse events.
Replies
1
Boosts
0
Views
263
Activity
2w
crash when trying to show NSAlert with Mac 27 beta with European and russian languages
Feedback Assistant Submission ID Reference : FB24634485 Attached is a sample code where after setting setlocale() to any of European languages or Russian language results in crash when calling NSAlert. Here is code snippet and crash log for reference. #import <Cocoa/Cocoa.h> int main(int argc, const char * argv[]) { @autoreleasepool { NSString* locale = @“fr_FR.UTF8"; setlocale(LC_ALL, locale.UTF8String); return NSApplicationMain(argc, argv); } } (IBAction)showAlertButtonTapped:(id)sender { NSAlert *alert = [[NSAlert alloc] init]; alert.messageText = NSLocalizedString(@"alert_title", nil); alert.informativeText = NSLocalizedString(@"alert_message", nil); alert.alertStyle = NSAlertStyleInformational; [alert addButtonWithTitle:NSLocalizedString(@"alert_ok_button", nil)]; [alert runModal]; } Crashlog
Replies
0
Boosts
0
Views
157
Activity
2w
Empty small white window appears
I recently ported my app from the Sequoia SDK to the Tahoe SDK. The app is written in Objective C and does not use ARC. Everything works well after the major cleanup, except .... A times I see a small empty window pop up. Clicking out of the application usually gets rid of it. I can make it happen fairly regularly on an displayed sheet which presents two NSImageView objects. The user clicks on a button which displays a popup menu; modifies an image then applies the results to one or both of the image views. Having spent two days on this it seems as if the actual setImage on the image view is causing the popup. If I cut out the setImage, it never happens ... even with all other steps in place. I've disabled all animations and tried dozens of things all to no avail. It is not consistent but I can make it happen on two Macs (both running Tahoe). It never happens on Sequoia or earlier when running the build produced with the Tahoe SDK. Any suggestions would be appreciated.
Topic: UI Frameworks SubTopic: AppKit
Replies
1
Boosts
0
Views
606
Activity
Aug ’26
How to force the temporary fullscreen sidebar as overlay?
My app uses an NSSplitViewController with three vertical split-view items: A sidebar created using +[NSSplitViewItem sidebarWithViewController:] The main content An inspector-like pane Through macOS Sequoia, it always had the following fullscreen sidebar behavior: (The sidebar was collapsed.) Moving the pointer to the left edge of the screen temporarily revealed it. The sidebar appeared as an overlay. The main content and inspector retained their existing frames. After building with the Golden Gate SDK, the temporarily revealed sidebar no longer behaves as an overlay. Depending on minimumThickness and maximumThickness of the items, this either resizes the main content or shifts the complete remaining layout to the side. The resulting animation also stutters because the content is laid out for every intermediate width. Explicitly toggling the sidebar using -[NSSplitViewController toggleSidebar:] is a different case and works correctly in my app. The problem specifically concerns only the automatic, temporary fullscreen reveal initiated by moving the pointer to the screen edge. I want that to remain as an overlay. I have experimented with the split-view items’ holdingPriority, minimumThickness, maximumThickness, minimumThicknessForInlineSidebars and collapseBehavior, but have not found a way to restore the previous overlay behavior. Any ideas how to do that? Thanks a lot!
Topic: UI Frameworks SubTopic: AppKit
Replies
2
Boosts
0
Views
146
Activity
Aug ’26
NSTextView Weird Selection Behavior with NSTextAttachmentCells
I have an NSTextView that displays several NSTextAttachmentCells. I notice this weird behavior. Sometimes if I just click in an empty area of the text view the entire text content selects. So I implemented the delegate method to catch it: - (NSRange)textView:(NSTextView *)textView willChangeSelectionFromCharacterRange:(NSRange)oldSelectedCharRange toCharacterRange:(NSRange)newSelectedCharRange { if (newSelectedCharRange.length > 1 && newSelectedCharRange.length > oldSelectedCharRange.length) { NSEvent *currentEvent = NSApp.currentEvent; NSLog(@"Selection expanded from %@ to %@. Event type: %ld, click count: %ld, modifier flags: %lu, current selected ranges: %@", NSStringFromRange(oldSelectedCharRange), NSStringFromRange(newSelectedCharRange), (long)currentEvent.type, (long)currentEvent.clickCount, (unsigned long)currentEvent.modifierFlags, self.selectedRanges); // put a break point here. } return newSelectedCharRange; } And I reproduced the issue and this logs out: Selection expanded from {0, 0} to {0, 6}. Event type: 2, click count: 1, modifier flags: 0, current selected ranges: ( "NSRange: {0, 6} Click count is only 1 so I didn't accidentally triple click. I know on Golden Gate use of NSEvent.currentEvent isn't the way (but I'm not there yet). A simple workaround would be to block the selection right here in the delegate method when clickCount != 3 (but again I know NSEvent.currentEvent in Golden Gate won't be reliable). Anyone run into this and have any ideas? It seems to happen after I did a triple click in the text view at some point previously (but not this click). So I got the feeling that maybe the text view isn't resetting some private properties and is treating this single click as a triple click. But I really don't know. Edit: Hmm maybe it has nothing to do with a previous triple click. May have to do with text selection not accounting for the geometry of the NSTextAttachmentCells. Not sure. But I still have to figure out a way to workaround this because a random select all is really annoying! Call stack looks like: ** -[MyTextView textView:willChangeSelectionFromCharacterRange:toCharacterRange:] at MyTextView.m -[NSTextView(NSSharing) setSelectedRanges:affinity:stillSelecting:] () -[MyTextView setSelectedRanges:affinity:stillSelecting:] MyTextView.m +[NSInputAnalytics(TrackedActionsManager) allowActionTrackingAnalyticsWithName:forAction:] () n -[NSTextView mouseDown:] () -[MyTextView mouseDown:] ** If you're wondering what my -mouseDown: override does it just calls super. I realize this is not a whole lot to go on but any help would be appreciated.
Replies
5
Boosts
0
Views
633
Activity
Aug ’26
WKWebView+Purch+StoreKit=Deadend
Does anyone have any advice on working a way around this, or through this? My app is wrapped and WKWebView displays HTML/CSS/JAVA and StoreKit is iOS framework. I used choicely up wrap it because i don't own a mac. The only part i can't control is this. I'll likely have to wrap it myself, rent a cloud Mac and submit directly to ensure everything is attached to the binary. I can't control that from choicely. any other ideas!? I’ve been over a month trying to get this going. It’s live but with no way to transact the subscribers I’m already getting. HELP PLEASE!
Replies
0
Boosts
0
Views
373
Activity
Aug ’26
NSToolbarItemViewer no longer resolves hit-testing to a view-based NSToolbarItem's subviews — interactive controls in custom toolbar item views receive no mouse events (regression in macOS 27 beta)
Area: AppKit / NSToolbar Type: Incorrect/Unexpected Behavior (Regression) Summary On macOS 27 beta, when an NSToolbarItem uses a custom view (NSToolbarItem.view) containing interactive controls (e.g. NSButton), clicks on those controls are silently swallowed. Window-level hit-testing stops at the private NSToolbarItemViewer instead of descending into the item's view hierarchy, so the controls never receive mouseDown and their target/action never fires. The same code works correctly on macOS 26 and earlier. This breaks the long-standing, documented view-based toolbar item pattern. Any app that places custom interactive controls inside toolbar items is affected. Steps to Reproduce Create a window with an NSToolbar. In toolbar(_:itemForItemIdentifier:willBeInsertedIntoToolbar:), return an NSToolbarItem whose view is a container NSView holding an NSButton with a target/action. Run on macOS 27 beta and click the button. Minimal repro (complete AppDelegate): import Cocoa @main class AppDelegate: NSObject, NSApplicationDelegate, NSToolbarDelegate { var window: NSWindow! func applicationDidFinishLaunching(_ notification: Notification) { window = NSWindow(contentRect: NSRect(x: 200, y: 200, width: 600, height: 400), styleMask: [.titled, .closable, .resizable], backing: .buffered, defer: false) let toolbar = NSToolbar(identifier: "Main") toolbar.delegate = self window.toolbar = toolbar window.makeKeyAndOrderFront(nil) } func toolbar(_ toolbar: NSToolbar, itemForItemIdentifier id: NSToolbarItem.Identifier, willBeInsertedIntoToolbar flag: Bool) -> NSToolbarItem? { let item = NSToolbarItem(itemIdentifier: id) let container = NSView(frame: NSRect(x: 0, y: 0, width: 120, height: 28)) let button = NSButton(title: "Click Me", target: self, action: #selector(clicked)) button.frame = container.bounds container.addSubview(button) item.view = container return item } @objc func clicked() { NSLog("BUTTON CLICKED") } // never logged on macOS 27 beta func toolbarDefaultItemIdentifiers(_ toolbar: NSToolbar) -> [NSToolbarItem.Identifier] { [NSToolbarItem.Identifier("CustomItem")] } func toolbarAllowedItemIdentifiers(_ toolbar: NSToolbar) -> [NSToolbarItem.Identifier] { toolbarDefaultItemIdentifiers(toolbar) } } Expected Results: Clicking the button highlights it and fires its action, as on macOS 26 and every earlier release: window hit-testing resolves to the NSButton inside the toolbar item's custom view. Actual Results The click is silently consumed. The button never receives mouseDown, its action never fires, and no toolbar item action is sent either (the item is view-based and has no target/action of its own). Diagnostic Evidence We instrumented hitTest(_:) throughout the hierarchy in our production app and observed, for a single leftMouseDown over the button: The custom subview's own hitTest is invoked during the traversal and correctly returns the NSButton. However, hit-testing initiated from the window's frame view (NSThemeFrame) resolves to NSToolbarItemViewer itself — the subview's result is discarded on the way up. Observed hit path: NSToolbarItemViewer <- NSToolbarView <- NSTitlebarView <- NSTitlebarContainerView <- NSThemeFrame Consequently AppKit dispatches mouseDown to NSToolbarItemViewer, which does nothing for a view-based item, and the event is dropped. This looks like an extension of the macOS 26 beta issue where NSGlassContainerView inside NSToolbarView intercepted hit-testing over the title bar (FB18201935, developer forums thread 788928). On macOS 27 the interception now also applies inside NSToolbarItemViewer for view-based items. Impact All interactive controls hosted in view-based toolbar items are unusable: buttons, search fields, segmented controls, etc. In our production app (RingCentral Video, a video-conferencing client), every in-meeting title-bar control (meeting info, network quality, view switcher, report) stopped responding on macOS 27 beta. We have shipped an application-level workaround that re-dispatches the event to the control when window hit-testing terminates at an ancestor of it, but this requires every affected app to implement custom event routing around a private view's behavior. FB24375035
Topic: UI Frameworks SubTopic: AppKit
Replies
1
Boosts
0
Views
141
Activity
Aug ’26
Custom pointer color makes -[NSCursor set] re-render from PDF on every call, pinning a CPU core across unrelated apps (macOS 27.0)
Filed as FB24344519. Posting here too because the scope is wider than any single app, and other developers may be getting "your app uses too much CPU" reports that are not actually their bug. Environment: macOS 27.0 (26A5406e), Apple Silicon (M5 Max). SUMMARY When a custom pointer color is set, every -[NSCursor set] call re-renders the pointer artwork from a PDF, with no caching. Any app whose UI frequently invalidates AppKit tracking areas then burns most of a CPU core continuously, with the mouse completely stationary. Trigger: defaults read com.apple.universalaccess cursorIsCustomized 1 That is System Settings > Accessibility > Display > Pointer, with a custom fill and outline color set. With default pointer colors, -[NSCursor set] is nearly free. CALL PATH (sampled with the mouse untouched) CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK -[_NSTrackingAreaAKManager _activeTrackingAreasNeedUpdate]_block_invoke -[_NSTrackingAreaAKManager _updateActiveTrackingAreasForWindowLocation:modifierFlags:] -[NSCursor set] -[NSCursor _reallySet] _AXFCursorSetAndReturnSeed (AccessibilityFoundation) -[_AXFMouseCursorGenerator createImageForScale:] -[_AXFMouseCursorGeneratorLayer _createImageForScale:color:] -[_AXFMouseCursorGeneratorLayer _pdfPage] / _pdf CGPDFScannerScan -> CGPDFDrawingContextDrawPath createImageWithSizeRenderInstructions __createImageWithMaskedColor_block_invoke CGContextClipToMask -> CGContextDrawImage -> A8_image_mark_rgb32 The pointer artwork is re-parsed from PDF and re-composited on every tracking-area update. SCOPE Main-thread samples in that path, mouse stationary: com.apple.weather.menu (Catalyst/UIKit): 1170 / 1327 = 88% Cloudflare WARP (Flutter): 1095 / 1154 = 95% Dayflow (SwiftUI/AppKit): 273 / 431 = 63% (bursts) Three unrelated UI toolkits, identical stack, including one of Apple's own menu bar apps. Apps with a mostly static UI are unaffected on the same machine with the same setting enabled, so the amplifier appears to be tracking-area invalidation frequency rather than the toolkit. Direct measurement of WeatherMenu with the trackpad untouched: 21.8 seconds of CPU in a 30 second window (73% of one core), sustained indefinitely, and 491 minutes of CPU time over 3 days of uptime. STEPS TO REPRODUCE System Settings > Accessibility > Display > Pointer. Set a custom pointer fill and outline color. Enable the Weather menu bar item (Control Center > Weather). Leave the machine idle. Do not touch the trackpad or mouse. Watch com.apple.weather.menu in Activity Monitor. Expected: near 0% CPU while idle. -[NSCursor set] with an unchanged cursor should be a cheap no-op. Actual: 65-75% of a core held indefinitely with no user input. CAVEAT I have not toggled cursorIsCustomized back off to confirm the CPU drops, so the dependency is inferred from the stack reaching the custom-color renderer (_createImageForScale:color:, createImageWithMaskedColor), which is only used when a custom pointer color is set. About a minute for anyone to verify. NOTES FOR OTHER DEVELOPERS Two things that cost me time: ps %CPU on macOS is a short decaying average, not steady state. It made an app look like it sat at 80% when its actual idle draw was under 4%. Compare cumulative CPU time deltas instead. sample counts blocked threads too, so "N% of main-thread samples" is not the same as N% CPU. Check whether the leaf frames are actually running code first. If your users report high CPU you cannot reproduce, it may be worth asking whether they have a custom pointer color set. SUGGESTED FIX Cache the generated cursor image in _AXFMouseCursorGenerator, and make -[NSCursor set] a no-op when the cursor and scale are unchanged, rather than re-parsing and re-rendering the PDF on every call. Happy to provide full samples or a sysdiagnose.
Topic: UI Frameworks SubTopic: AppKit
Replies
0
Boosts
0
Views
172
Activity
Aug ’26
NSInternalInconsistencyException assertion from [NSRemoteView containingWindowWillOrderOnScreen:] on macOS 27 (26A5378j)
Is anyone else getting these assertion crashes on developer beta 3 of Golden Gate? I've gotten more than a dozen crash logs from users running macOS 27 (26A5378j) that all look like this: assertion failed: '<NSRemoteView: 0x79cb366700 com.apple.SafariPlatformSupport.Helper SPCompletionListServiceViewController> notified of <NSStatusBarWindow: 0x79cbef7480> but expected (null)' in -[NSRemoteView containingWindowWillOrderOnScreen:] on line 4221 of file /AppleInternal/Library/BuildRoots/4~CSuOugB1YCxzYMPRWEumvvfCTNtf98eItTmsbJU/Library/Caches/com.apple.xbs/TemporaryDirectory.N8fh9t/Sources/ViewBridge/NSRemoteView.m but with various windows from my app after "notified of". They're getting thrown when one of my windows is made frontmost, either using NSWindow.orderFrontRegardless or NSWindow.makeKeyAndOrderFront, or (in the case above) when my status item is shown. It's intermittent - I've been unable to reproduce it so far - but definitely happening repeatedly based on my Sentry crash logging. Is this a bug in Golden Gate b3, or am I doing something to provoke this? I've submitted it via Feedback Assistant (FB23642313). Thanks Jon P.S. Full stack trace attached for the exception thrown when the assertion fails for NSStatusBarWindow NSInternalInconsistencyException stack trace.txt
Topic: UI Frameworks SubTopic: AppKit
Replies
10
Boosts
4
Views
1.7k
Activity
Aug ’26
Vertically Off-Center Components in NSSearchToolbarItem in macOS 27 Developer Beta 5
In macOS 27 developer beta 5, search fields in toolbars (NSSearchToolbarItem instances) have their placeholder text, search strings, and magnifying glass icons vertically off-center. I reported this as FB24286690. You can see this in the Feedback Assistant app. The “Search” placeholder text, the magnifying glass, and the search string are all closer to the top of the toolbar item than the bottom. My feedback has a sample project demonstrating this, along with screenshots. I have a more detailed writeup at: https://www.virtualsanity.com/202608/vertically-off-center-components-in-nssearchtoolbaritem-in-macos-27-developer-beta-5/
Topic: UI Frameworks SubTopic: AppKit Tags:
Replies
0
Boosts
0
Views
249
Activity
Aug ’26