When scrolling a basic NSScrollView there seems to be a sudden jump after each flick. Scrolling does not appear smooth and is disorientating. A scroll jump seems to happen directly after letting go of a scroll flick using a trackpad/mouse. Right at that moment the scroll turns into a momentum scroll, slowly decreasing the speed. But the first frame after the gesture the content jumps forward, more than what is expected. Observations: Counterintuitively, scrolling appears to be smoother when disabling NSScrollView.isCompatibleWithResponsiveScrolling. If disabled using a custom NSScrollView subclass there is no large jump anymore. Scrolling also appears to be smoother using a SwiftUI ScrollView. I assume that has the same behaviour as a disabled isCompatibleWithResponsiveScrolling Ironically a WKWebView scrolls much smoother. No sudden jump is observable. It also seems to scroll with faster acceleration, but the individual frames do appear smoother. Why is this better than a native NSScrollView? Elastic scrolling at the bounds of the scroll view also appears much smoother for WKWebViews. When pulling to refresh there is a jump for NSScrollView/SwiftUI, but not for WKWebView. When using an NSScrollView with isCompatibleWithResponsiveScrolling disabled, scrolling appears just as smooth as WKWebView on macOS 13 Ventura and below. On macOS 14 Sonoma scrolling behaviour is suddenly different. Please see a sample project with 4 different scroll views side by side: https://github.com/floorish/ScrollTest Screen recordings show the sudden jumps when scrolling and when elastic scrolling. Tested on Intel & Arm Macs, macOS 11 Big Sur through 15 Sequoia, built with Xcode 16. Should isCompatibleWithResponsiveScrolling be disabled on Sonoma+? Are there any drawbacks? There is also no overdraw anymore since Monterey, as described in https://developer.apple.com/library/archive/releasenotes/AppKit/RN-AppKitOlderNotes/#10_9Scrolling Even with responsive scrolling disabled, why is WKWebView scrolling much smoother than NSScrollView?

Since upgrading to macOS 27, I have encountered native menus becoming unresponsive. It is reproducible via a short sequence of mouse actions in Apple’s TextEdit application. The following linked zip contains a Python reproduction script and a shell launcher that prepares its dependencies: https://drive.google.com/uc?export=download\&id=1q9DtRC7zpnhK50v4VmvuRAf2sq6I9jaz Expected: The menu continues responding to mouse movement, clicks and Escape. Observed: The menu becomes unresponsive after the sequence. Could anyone confirm whether the attached reproduction triggers the issue on their system? Is this a known AppKit menu-tracking issue, and are there any suggested workarounds or additional diagnostics that would help investigate it? Thank you.

If my NSDocument.canConcurrentlyReadDocuments(ofType:) implementation returns true, often when launching the app, an untitled document is created regardless whether another document is restored. If document reading is not concurrent, an untitled document is only created when no other document is restored, as expected. The issue happens on most app launches when a document is restored. If the restored document takes long to load (which can be simulated by putting sleep(1) in the Document.read(from:ofType:) implementation), the issue always happens. Is this expected, or is there a workaround? I created FB25340015.

Our macOS app crashes intermittently on the main thread inside system frames only. No frame of our own code is in the crashed thread's stack. I would like to know whether others have seen this, and whether there is a known cause or workaround. Environment macOS 14.7.4 (23H420) MacBookPro16,1 (16-inch, 2019), Intel Core i7-9750H, dual GPU (Intel UHD Graphics 630 + AMD Radeon Pro 5300M, automatic graphics switching) Built-in display only, as far as we can tell. We have no record of an external display being connected. The same machine crashed 3 times in 7 days with this same crash signature. Crash Exception Type: EXC_BAD_ACCESS (SIGSEGV) Exception Codes: KERN_INVALID_ADDRESS at 0x000000010a5f9008 Crashed Thread: 0 Dispatch queue: com.apple.main-thread Time Since Wake: 4798 seconds VM Region Info: 0x10a5f9008 is not in any region. CoreAnimation 10a5f8000-10a5f9000 [4K] rw-/rwx ---> GAP OF 0x2000 BYTES CoreAnimation 10a5fb000-10a5fd000 [8K] r--/r-- Thread 0 Crashed: 0 SkyLight SLSWindowServerClientManagedDisplayGetCurrentSpace + 181 1 AppKit -[NSScreen _notchFrame] + 85 2 AppKit _NSScreenFrameByAdjustingFrameForNotch + 55 3 AppKit -[NSScreen _layoutFrame] + 130 4 AppKit -[NSScreen visibleFrame] + 47 5 AppKit -[NSWindow(NSWindowResizing) _resizableEdgesForGrowing:shrinking:] + 589 6 AppKit -[NSWindow(NSWindowResizing) _getEdgeResizingRects:] + 37 7 AppKit -[NSWindow(NSWindow_Theme) _regionForOpaqueViewsModifiedForResizing:] + 53 8 AppKit -[NSWindow(NSWindow_Theme) _resetDragMargins] + 343 9 AppKit -[NSWindow(NSWindow_Theme) _resetDragMarginsIfNeeded] + 43 10 AppKit __NSWindowGetDisplayCycleObserverForUpdateStructuralRegions_block_invoke + 375 11 AppKit NSDisplayCycleObserverInvoke + 140 12 AppKit NSDisplayCycleFlush + 878 13 QuartzCore CA::Transaction::run_commit_handlers(CATransactionPhase) + 95 14 QuartzCore CA::Transaction::commit() + 377 15 AppKit -[_NSScrollingConcurrentMainThreadSynchronizer _synchronize:preCommitHandler:completionHandler:] + 336 ...What we know The faulting address is just past a mapped 4K CoreAnimation region, which suggests a stale pointer into a dynamically mapped region. Near the faulting instruction there is a loop that advances by 0x14 bytes per iteration, which might be a table walk. This is our reading of the disassembly only, not confirmed. About 1 second before the crash, our app closed a secondary window (a standalone chat window). This is the only UI action we see just before the crash, and it happened once, so we cannot say it is the trigger. The crash is not tied to a specific app feature, and it was not right after wake (about 80 minutes after the last wake). Separately, we see crashes on other Intel Macs inside SkyLight called from NSDisplayTiming, across macOS 13 to 26, with the same kind of "address outside any mapped region" fault. We believe they may share a root cause, but we have not proven it. Questions Has anyone seen _notchFrame / SLSWindowServerClientManagedDisplayGetCurrentSpace crashing like this, especially on a Mac with no physical notch? Is -[NSWindow _resetDragMargins] known to read screen geometry at a time when the display configuration or active space can change? Is there anything an app can do (for example, when and how it closes windows, or where it reads NSScreen.visibleFrame) to avoid this, or is this a system bug that should go to Feedback Assistant? I can share the full crash report if it helps. I'll also file a Feedback and post the FB number here.

After updating a MacBook Pro (M1 Pro) from macOS 15.8 to the 15.8.2 release candidate (24H219), every OpenGL context that is attached to a window has no default framebuffer. NSOpenGLView and -[NSOpenGLContext setView:] are both affected, so anything drawn that way shows a blank window. I filed FB25133383 with a minimal sample, kernel log and call trace. Symptoms kCGLCPHasDrawable is 0, glCheckFramebufferStatus(GL_FRAMEBUFFER) returns GL_FRAMEBUFFER_UNDEFINED (0x8219), and glClear raises GL_INVALID_FRAMEBUFFER_OPERATION (0x506). For every attach attempt the kernel logs: (IOGPUFamily) IOGPUGLDrawableUserClient::set_surface(sIOGPUGLDrawableClientSetSurfaceData *): Invalid surface ID = N CGLSetSurface returns kCGLBadDrawable (10005). Stepping through it, CGSBindSurface succeeds and the IOGPU user-client call then fails with kIOReturnBadArgument. What still works Offscreen FBOs in the same context. CAOpenGLLayer and NSOpenGLLayer render correctly in the same process. Only the window-surface path is broken. Minimal sample (public API only) // clang -fobjc-arc -Wno-deprecated-declarations -framework Cocoa -framework OpenGL repro.m -o repro && ./repro #define GL_SILENCE_DEPRECATION 1 #import <Cocoa/Cocoa.h> #import <OpenGL/OpenGL.h> #import <OpenGL/gl.h> #import <OpenGL/glext.h> @interface ReproView : NSOpenGLView @end @implementation ReproView - (void)drawRect:(NSRect)dirtyRect { NSOpenGLContext *ctx = [self openGLContext]; [ctx makeCurrentContext]; GLint hasDrawable = -1; CGLGetParameter(ctx.CGLContextObj, kCGLCPHasDrawable, &hasDrawable); GLenum status = glCheckFramebufferStatus(GL_FRAMEBUFFER); glClearColor(0, 1, 0, 1); glClear(GL_COLOR_BUFFER_BIT); GLenum err = glGetError(); printf("hasDrawable=%d status=0x%x glError=0x%x\n", hasDrawable, status, err); fflush(stdout); [ctx flushBuffer]; } @end int main(void) { @autoreleasepool { NSApplication *app = [NSApplication sharedApplication]; [app setActivationPolicy:NSApplicationActivationPolicyRegular]; NSWindow *win = [[NSWindow alloc] initWithContentRect:NSMakeRect(200, 300, 240, 240) styleMask:NSWindowStyleMaskTitled | NSWindowStyleMaskClosable backing:NSBackingStoreBuffered defer:NO]; NSOpenGLPixelFormatAttribute attrs[] = { NSOpenGLPFADoubleBuffer, NSOpenGLPFAAccelerated, 0 }; NSOpenGLPixelFormat *pf = [[NSOpenGLPixelFormat alloc] initWithAttributes:attrs]; [win.contentView addSubview:[[ReproView alloc] initWithFrame:NSMakeRect(20, 20, 200, 200) pixelFormat:pf]]; [win makeKeyAndOrderFront:nil]; [app activateIgnoringOtherApps:YES]; dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 5 * NSEC_PER_SEC), dispatch_get_main_queue(), ^{ [app terminate:nil]; }); [app run]; } return 0; } Expected: a green square and hasDrawable=1 status=0x8cd5 glError=0x0. On 24H219: nothing is drawn and it prints hasDrawable=0 status=0x8219 glError=0x506. Scope Same result for arm64 and x86_64 under Rosetta, layer-backed or not, main thread or background thread. Affected on my Mac: Sony Imaging Edge Desktop Viewer (NSOpenGLView), DJI Studio (Qt 6, NSOpenGLContext) and its Quick Look extension. Public reports with the same symptom on 24H219: kitty #10645, Alacritty #9067, Godot #124311, Bambu Studio #12530 (all on GitHub). They cover M1, M4, M4 Pro and M4 Max, and the Alacritty report says 15.8.1 was fine. Questions Is this a known issue in the 15.8.2 RC, and will it be fixed before 15.8.2 ships? Is anyone seeing it on the macOS 26.7.2 RC or the 27.2 beta? Workaround for developers in the meantime: render into an IOSurface-backed FBO and present that surface in a CALayer, or use CAOpenGLLayer.

Can anyone help to understand what is causing this warning message on this SampleCode. it happens when data in table gets updated it happens when I have lot of items in table and search for lets say # 6543 and then clear the search. "WARNING: Application performed a reentrant operation in its NSTableView delegate. This warning will become an assert in the future." If there are just few items in table, the warning is not there. And it started when updated to Xcode Version 14 and upward import SwiftUI import Foundation @main struct TestProjectSWIFTApp: App {     @StateObject var mydata: MyData = MyData()     var body: some Scene {         WindowGroup {             ContentView()                 .environmentObject(mydata)         }              } } struct ContentView: View {     @EnvironmentObject var mydata: MyData     var body: some View {         NavigationView{             NavigationLink("TABLE",  destination: MyTable())                      }     } } struct User: Identifiable {     let id: UUID = UUID()     var name: String     var score: Int } struct MyTable: View {     @EnvironmentObject var mydata: MyData     @State private var sortOrder = [KeyPathComparator(\User.name)]     @State var searchText: String = ""     var searchResults : [User] {         if searchText.isEmpty {             return mydata.alldata         } else {             return mydata.alldata.filter{$0.name.localizedCaseInsensitiveContains(searchText)}         }     }          var body: some View {                  Button("Generate new data", action: {             mydata.updateTable()         })                  Table(searchResults, sortOrder: $sortOrder) {             TableColumn("Score"){                 Text("\(Double($0.score))")             }             TableColumn("user", value: \.name)         }         .onChange(of: sortOrder) {             mydata.alldata.sort(using: $0)         }         .searchable(text: $searchText)     } } @MainActor class MyData : ObservableObject{     @Published var alldata: [User] = []               init(){         self.setData()     }          func setData(){         alldata = [             User(name: "User 1", score: 95),             User(name: "User 2", score: 80),             User(name: "User 3", score: 85)         ]     }          func updateTable(){         var newallData: [User] = []         var x = 0         while x < 10000{             newallData.append(User(name: "User #\(x)", score:  Int.random(in: 10..<999999)))                          x = x + 1         }         alldata = newallData     }      }

I have a few NSMenuItem's the set the image property. I only did this for a few specific context menus and this was done before Tahoe wanted to use SF Symbols for every menu item. Now when my app is built with Xcode 27, these context menus aren't showing their images at all. For example I have code like: -(void)viewDidLoad { [super viewDidLoad]; NSImage *specialImage = [NSImage imageNamed:@"SpecialImage"]; self.specialMenuItem.image = specialImage; } I never got around to adding SF Symbols for every NSMenuItem and it looks like macOS Golden Gates reverted that behavior. Maybe something to do with reverting that...has something to do with this. But as I said previously these menu items aren't using SF Symbols as their images, they are not connected to standard actions in the menu bar like Edit -> Undo. These are my own context menu items. If I run the version of this app built with Xcode 26 the images show up. But when building from Xcode 27 SDK setting the image property on NSMenuItem does not work. -- Ah I see there is this in the header now: /// Set an image that is displayed next to the menu item's title. // Note that in macOS 27 and later, AppKit determines the >visibility of menu item images, and will typically hide images. >Use the preferredImageVisibility property with the .visible constant to specify that an image should always be visible. Seriously what on earth is this? I have an entire context menu where not displaying an image would be completely inappropriate. Imagine when you right click a file in Finder and go Open -> Open With... and all the menu items for applications didn't show the icons. I have to beg the system for permission to display an image in my app's context menu? Why involve yourself in that situation? Why not preferredTitleVisibility too so the system can reserve the right to not display NSMenuItem titles? Furthermore, if I set the image property on an NSMenuItem is NSMenuItemImageVisibilityVisible (great name BTW!) not implied? Why would I set the property, if I didn't want it to be displayed?

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!

Hi everyone, Following the update to macOS 27, we have observed a regression/behavioral change in PDFKit regarding how markup annotations (particularly highlights, underlines, and strike-outs) are drawn. Issue Description Whenever a markup annotation (PDFAnnotationSubtypeHighlight / PDFAnnotation) has associated text or contents, PDFKit now automatically renders a yellow speech-bubble / comment note icon directly adjacent to the highlighted region in the margins. Visual Symptom: Instead of a clean text highlight overlay, the document margin is immediately cluttered with comment bubble icons for every single highlighted passage or line. Impact across applications: Because this rendering occurs within the native PDFKit.framework rendering layer, rolling back host applications to earlier releases does not alleviate the issue. It affects both system PDF rendering and third-party PDFKit-based viewers (such as Skim). Expected Behavior: Standard highlight and markup annotations should display their color fill over the text without forcing an external comment icon unless an explicit pop-up / sticky note annotation is requested. Third-Party Tracker Reference This issue is actively being investigated and tracked in the Skim open-source project here: https://sourceforge.net/p/skim-app/bugs/1617/ Questions for DTS / Community: Is there an undocumented flag, preference, or API attribute on PDFAnnotation / PDFView in macOS 27 to disable or hide these automatic markup pop-up icons globally or per annotation? Is this change intentional as part of a redesigned annotation interaction model, or is it an unintended side effect of internal note rendering changes? Any workarounds or insights would be greatly appreciated.

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

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.

The following SwiftUI app snippet causes a 100% reproducible crash on macOS. import SwiftUI struct Rule: Identifiable { let id = UUID() var text = "" } @MainActor @Observable final class Policy { var rules: [Rule] = [ .init(text: "Row 1"), .init(text: "Row 2") ] } @main struct MyApp: App { @State private var policy = Policy() var body: some Scene { WindowGroup { List { ForEach($policy.rules) { $rule in HStack { TextField("Value", text: $rule.text) Spacer() Button("Remove") { policy.rules.removeAll { $0.id == rule.id } } } } } .padding() } } } I first encountered this on macOS 27, but have also reproduced it on macOS 26.6.2. In both cases, the app was compiled with Xcode 27 from a standard “New Project” template. (Default build settings: Swift 5, Main Actor Isolation, Approachable Concurrency enabled.) Steps to reproduce: Open Xcode and select “New Project… > App”. Copy and paste the snippet above into a Swift file. Build and run. Click one of the two text fields to give it focus. Click the Remove button for that same row. The application crashes with an access violation. My assumption is that the row is removed from the array while the TextField still holds a Binding to it. When the text field subsequently loses focus, it attempts to write through a binding whose underlying element no longer exists. There are ways to work around this, but I’d be interested in guidance from the SwiftUI or AppKit team on the intended way to handle this situation. The same kind of issue can arise with custom bindings, but it is particularly difficult to guard against when framework controls perform reactivate actions, like when it loses focuses.

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?

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.

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) } } ``

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.

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.

On macOS 27.0 (26A428) with Xcode 27.0, Apple's unmodified sample Building a document-based app with SwiftUI stops responding permanently when another process replaces an open document's file through NSFileCoordinator. AppKit reverts the document on the main thread, which then blocks in a semaphore wait inside SwiftUI: -[NSDocument relinquishPresentedItemToWriter:]_block_invoke_8 (in AppKit) -[NSDocument _revertToVersion:preservingFirst:error:] (in AppKit) -[NSDocument revertToContentsOfURL:ofType:error:] (in AppKit) URLPlatformDocument.read(from:ofType:) (in SwiftUI) _dispatch_semaphore_wait_slow (in libdispatch.dylib) No other thread is reading the document. In another app using Document, its DocumentReader was never called, and a document with unsaved changes hung the same way in URLPlatformDocument.write(to:ofType:for:originalContentsURL:). Reproduction (the sample plus a short script): https://github.com/DePasqualeOrg/swiftui-document-revert-hang Feedback report: FB24792850

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.