I would like to render a divider line in a NSTextView (like the <div> HTML item) on macOS 10.13 or later. I use Objective-C. I've searched for solutions and it looks like the recommended solution is to use a NSTextAttachmentCell. There was supposedly an example provided on the cocoa-dev mailing list but the archives for this useful mailing list are gone. The issue I'm observing with the NSTextAttachmentCell solution is that it is working almost well with a simple NSTextView example but when used in a more complex application, the rendering of the divider is still fine but there's a huge vertical gap between the divider and the text below the divider. The online documentation for the NSTextAttachmentCell class is not really helpful (and contains typos: "With the exceptions of cellBaselineOffset, attachment, and attachment, all of these methods are implemented by the NSCell class.For general information on text attachments, " -> "attachment" twice, no space between "class." and "For general"). Here's the simple code I'm currently testing for the attachment cell: @implementationMyDividerTextAttachmentCell - (NSRect)cellFrameForTextContainer:(NSTextContainer *)textContainer proposedLineFragment:(NSRect)lineFrag glyphPosition:(NSPoint)position characterIndex:(NSUInteger)charIndex { return NSMakeRect(lineFrag.origin.x, lineFrag.origin.y, textContainer.size.width, 10); } - (void)drawWithFrame:(NSRect)cellFrame inView:(nullable NSView *)controlView { [[NSColor darkGrayColor] setStroke]; [NSBezierPath strokeLineFromPoint:NSMakePoint(0, NSMidY(cellFrame)) toPoint:NSMakePoint(NSMaxX(cellFrame), NSMidY(cellFrame))]; }[Q] Is there an obvious reason why there would be a huge gap (think 200 pixels/points) below the divider? What is the recommended way to render a divider line in a NSTextView if it's not NSTextAttachmentCell.

PDFKit's PDFOutline creates fundamentally flawed PDF syntax when it creates outlines ("Bookmarks") in a PDF document. A PDF document is created with three outlines: "Page 1", "Page 2" and "Page 3". Each is a child of the former, so "Page 3" is a child of "Page 2", and "Page 2" is a child of "Page 1". PDFKit produces flawed PDF syntax, with duplicate entries for each bookmark, missing sibling links, and a convoluted Parent > Child relationship. 3 0 obj << /Type /Pages /Parent 45 0 R /Count 8 /Kids [ 2 0 R 6 0 R 9 0 R 12 0 R 15 0 R 18 0 R 21 0 R 24 0 R ] >> endobj 28 0 obj << /Type /Pages /Parent 45 0 R /Count 3 /Kids [ 27 0 R 31 0 R 34 0 R ] >> endobj 45 0 obj << /Type /Pages /MediaBox [0 0 612 792] /Count 11 /Kids [ 3 0 R 28 0 R ] >> endobj 46 0 obj << /Type /Catalog /Outlines 1 0 R /Pages 45 0 R >> endobj 1 0 obj << /First 47 0 R /Last 48 0 R >> endobj 48 0 obj << /Last 49 0 R /Count -1 /First 50 0 R /Title (Page 1) /Dest [ 2 0 R /XYZ 0 841.88 null ] /Parent 51 0 R >> endobj 51 0 obj << >> endobj 50 0 obj << /Last 52 0 R /Count -1 /First 53 0 R /Title (Page 2) /Dest [ 6 0 R /XYZ 0 841.88 null ] /Parent 51 0 R >> endobj 53 0 obj << /Dest [ 9 0 R /XYZ 0 841.88 null ] /Count 0 /Title (Page 3) /Parent 51 0 R >> endobj 52 0 obj << /Dest [ 9 0 R /XYZ 0 841.88 null ] /Count 0 /Title (Page 3) /Parent 51 0 R >> endobj 49 0 obj << /Last 52 0 R /Count -1 /First 53 0 R /Title (Page 2) /Dest [ 6 0 R /XYZ 0 841.88 null ] /Parent 51 0 R >> endobj 47 0 obj << /Last 49 0 R /Count -1 /First 50 0 R /Title (Page 1) /Dest [ 2 0 R /XYZ 0 841.88 null ] /Parent 51 0 R >> endobj(The Parent of all the outline objects is given as object 51, which is blank. The First/Last objects don't link correctly to the expected hierarchy, etc, etc.) Acrobat preflight will flag this as a syntax error, though the bookmarks do largely function in most viewers. Preview doesn't show the top-level outline, though that might relate to FB4013726, filed in 2018. I have shown the created syntax to ChatGPT, which also confirmed that the syntax does not conform to the expected PDF spec: This isn’t simply a matter of PDFKit choosing an unnecessarily elaborate but valid representation. There are genuine structural problems: The top-level Page 1 object’s /Parent does not point to the /Outlines dictionary. The child objects’ /Parent does not point to their actual containing outline. There are duplicate outline objects for Page 1, Page 2 and Page 3. The required sibling Prev/Next chains are absent. The /First//Last relationships don’t correspond cleanly to the claimed hierarchy. The errors are entirely reproducible in any PDFOutlines created by PDFKit. I have filed this as FB25328043. ... and in 2021 as FB8960602. ... and in 2019 as FB5313583.

This type of message (see title) is logged in the Xcode console each time a contextual menu (incuding a menu from an NSPopupButton) appears in my app, under macOS 27 (Xcode 27). What does it mean?

On macOS 27, dragged rows on my app's table views are excessively clipped (see image). I don't override methods like `tableView:draggingSession:willBeginAtPoint:forRowIndexes:` so I don’t supply my own drag images, and I don’t use NSTableView suclasses. I tried on a toy project containg with a single table view in a window, and it did not reproduce this behavior. I wonder if my issue if it’s due to my app’s table views being embedded in split views or something. Anyway, how can I fix that?

Overview I'm developing an app that depends on NSScrollView to implement a scrollable and zoomable canvas. I need to override NSScrollView.scrollWheel(with:) to implement Option-zooming (holding Option while scrolling up/down to zoom in/out). I've found that simply adding these three lines of code in my NSScrollView subclass: override func scrollWheel(with event: NSEvent) { super.scrollWheel(with: event) }is enough to cause a live scroll to never end, and NSScrollView.didEndLiveScrollNotification to never fire. My app depends on that notification firing so that it can disable some interactions during a live scroll. Furthermore, while the NSScrollView is "stuck" in the live scroll, it's not possible to perform a live magnify. There are also some other effects, including elevated CPU usage and persistent scroll indicators. The issue is occurring with Xcode 27.1 (27A9275) and macOS 27.2 (26B123). I have modified the macOS App project template to showcase the issue. The sample project, along with a screen recording of the issue, can be downloaded from here: https://drive.google.com/drive/folders/1F5sF2NA230NkGbQdLfbV6vM1XmfY1-uT?usp=sharing I hope that Apple can fix this issue soon, as it's a frustrating user experience when the canvas gets stuck while scrolling. I've already filed this in Feedback Assistant under FB25362729. Steps to Reproduce To recreate the issue, follow these steps: Download and extract the "Xcode Project.zip" file from the link above. Open the extracted "NSScrollViewTest" project in Xcode. Build and run the "NSScrollViewTest" app. Scroll all the way to the right edge of the gray canvas using the horizontal scroll gesture on Magic Trackpad. If you comment out lines 8–10 of ScrollView.swift, the issue goes away. The "Issue Recording.mov" file from the link above provides a detailed video of how to recreate the issue.

MacOS 27 (or perhaps 26, I never used it) introduces two bugs in NSTableView (and delegate). It's always a pleasure when you find that your app no longer works properly. First, when the delegate responds to tableView:pasteboardWriterForRow:, no row can be selected by click & drag (even if the method returns nil). Which mean that clicking and dragging the mouse on rows that are not draggable simply does nothing (no selection), which is a frustrating user experience, especially considering that the same action selects rows on macOS 15. The second bug is that tableView.verticalMotionCanBeginDrag = NO is simply ignored. It doesn’t work. So, a click followed by an immediate vertical drag drags the clicked row instead of selecting rows if tableView:pasteboardWriterForRow: does not return nil. Again, it did select rows on macOS 15. That's what verticalMotionCanBeginDrag = NO is for. To work around the first bug, I implement respondsToSelector: in the delegate to return NO when the selector is tableView:pasteboardWriterForRow: and the clicked row is not draggable. This solution is not elegant, as theclickedRow property of the tableview always returns -1 when the method is called. Which means I need to determine the clicked row by other means (using the mouse location and stuff). (This solution should in principle allow working around the second bug, but I haven’t implemented it yet. It would require determining the delay between the click and the drag and the direction of the drag). So my question is: does anyone see a better workaround for these bugs?

I'm not sure if it's something wrong with my XCode install (Version 27.1, macOS 27.2) or what, because such a serious issue should be mentioned already... Basically, building my objC app with the latest XCode makes the NSSegmentedControl style ineffective. Likewise, changing the style in the attribute of the control in interface builder has no visible effect on the preview either. Changing the style in code or in IB has no effect. The control appears stuck with a style that implements a blue background for the selected segment (some default style I guess). I tried with a minimalistic app that includes only one window and the control. The issue is still present. Any suggestion? Am I the only one experiencing this?

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.

I’m currently running into issues where nextEventMatchingMask is taking at least 0,02 seconds and even in some cases 0,07 seconds just to return a nil event. This is causing me to not be able to hit my target frame rate of 60fps. Is this expected behaviour? It happens but with distantPast and nil untilDates.

We are investigating a Mac App Store version of an app that provides tap-to-click and two-finger dragging for Magic Mouse. We need contact identity, finger positions, touch-down/up, and simultaneous contact count while the pointer is over other apps. We want a supported public API and normal App Sandbox entitlements. We are not asking how to use a private framework or bypass the sandbox. Environment tested: macOS 27.0.1 (26A434), Apple Silicon arm64, Bluetooth Magic Mouse vendor 0x004c / product 0x0269. Both IOHIDManager/IOHIDDevice and CoreHID are tested in a standalone sandboxed diagnostic app, signed with a persistent local certificate. Sandbox is confirmed via SecTask, Input Monitoring granted via System Settings and confirmed by IOHIDCheckAccess. Entitlements: app-sandbox, device.usb, device.bluetooth. No temporary exceptions, no seizeDevice, no SetReport or device reconfiguration. The normal app was still running during capture; we can repeat with it stopped if necessary. We discover four mouse interfaces, primary usage pairs FF00/03, FF00/12, FF00/0B, and 01/02. All open successfully after Input Monitoring is granted. The latter descriptor includes a 0D/05 Touch Pad collection but only vendor-defined payload for that collection. Standard individual contact fields are not declared. Input report IDs 0x3f and 0x44 are declared in addition to mouse report 0x12. Two 60-second captures, one per API, include user-performed phases for hands off, one finger, two fingers, moving each finger independently, scrolling, and physical movement/click. IOHID received 1310 input reports; CoreHID received 2349. Every report was ID 0x12, 8 bytes. Element updates were exclusively Generic Desktop X/Y, without individual contact identity or finger coordinates. Neither 0x3f nor 0x44 was delivered. The diagnostic client only reads mouse interfaces and does not read keyboard input. Questions: Is there a supported public API to observe global individual Magic Mouse contacts in an App Sandbox app, including when another app is active? Is individual-contact data expected to be available through IOHIDDevice input reports or CoreHID for this device? If so, what documented setup and entitlements are required? Are the declared vendor-defined reports 0x3f/0x44 intended for third-party clients, and is their payload documented for this purpose? If there is no supported public route, should this functionality remain outside the Mac App Store, or is there a supported capability path we should investigate? The diagnostic source is independent of the production app. Please advise whether further captures with all other input utilities stopped would help distinguish a driver/client interaction from an unsupported use case. No logs or source attachments are included in this public post.

Hello everyone, Since upgrading to macOS 27 Golden Gate, I've been experiencing numerous graphical interface issues on both of my Macs: MacBook Pro M4 Pro (work computer) MacBook Air M4 (personal computer) Both machines use completely separate Apple Accounts, yet they exhibit the same problems. The issues mainly affect window controls, menus, buttons, and title bars. For example: The red, yellow, and green window control buttons sometimes disappear completely. Safari's toolbar or title bar occasionally fails to render properly. When closing another application, such as Microsoft Word, parts of the Safari interface can disappear or become blank. Certain interface elements are not properly redrawn when switching between applications or rearranging windows. I've attached screenshots illustrating these problems. I don't use Stage Manager or any third-party window management utilities. Both Macs are running standard macOS configurations. These issues only started after upgrading to Golden Gate. Given that they occur on two different Apple Silicon Macs with separate Apple Accounts, I strongly suspect a macOS-level window rendering bug rather than a hardware or user-specific issue. The problems are quite disruptive during everyday work. Is anyone else experiencing similar issues? Has Apple acknowledged these rendering bugs, and is there any indication of when a fix might be released? Thanks in advance for your feedback.

Trackpad “Use inertia when scrolling” setting appears to be ignored by native scroll views I'm seeing inconsistent trackpad scrolling behavior on macOS where the system setting Accessibility → Pointer Control → Trackpad Options → Use inertia when scrolling appears to be ignored by many native applications. According to the macOS description of this setting, when inertia is disabled, scrolling should stop immediately when the fingers are lifted from the trackpad. However, in many native or heavily AppKit/SwiftUI-based applications, momentum scrolling remains active even with this option disabled. Examples include built-in macOS applications and other applications that use native scrolling extensively. Steps to reproduce Open System Settings → Accessibility → Pointer Control → Trackpad Options. Disable Use inertia when scrolling. Open a native application containing a scrollable view. Perform a reasonably fast two-finger scroll on the built-in trackpad. Lift both fingers while they are still moving. Expected behavior As soon as the fingers leave the trackpad, scrolling should stop immediately, since Use inertia when scrolling is disabled. Actual behavior In many native scroll views, scrolling continues after the fingers have been lifted, as if inertia were still enabled. More importantly, there also appears to be an abnormal transition between the direct finger-controlled phase and the momentum phase. If the fingers are lifted while still moving, the content often makes an additional sudden jump immediately after finger release before continuing its deceleration. If I stop my fingers completely before lifting them from the trackpad, this jump is either absent or much less noticeable. This makes scrolling feel uneven even when the frame rate itself is stable. Additional observations The behavior seems strongly related to the native macOS scrolling implementation. Applications or scrolling implementations that perform their own smooth scrolling do not show the same behavior, even on the same machine and display. This does not look like a general rendering-performance or low-frame-rate issue. The actual scroll trajectory appears incorrect around the transition from the physical gesture to momentum scrolling. There is an existing Developer Forums report titled “NSScrollView scrolling hitch” describing a very similar jump on the first frame after a scroll gesture transitions into momentum scrolling. In that report, disabling NSScrollView.isCompatibleWithResponsiveScrolling reportedly removes the large jump. My observation may be related, but there is an additional issue here: the user-facing system setting that is supposed to disable scroll inertia does not appear to disable this momentum behavior in many native scroll views at all. Questions Is NSScrollView expected to respect the system Use inertia when scrolling preference? Should NSEvent.momentumPhase events still be generated when this setting is disabled? Is there a separate native scrolling path that bypasses this preference? Could this be related to responsive scrolling or the transition from the regular phase to momentumPhase? Is there currently any workaround for applications or users affected by this behavior? Environment: MacBook Air with Apple M4, built-in trackpad, macOS 27 Beta (26B5112a).

QLPreviewController renders plain text as hyperlink in document downloaded from my ios app. xcode version 27.0, ipadOS - 26.5, ipad Air 11inch(M4). Expected behaviour - plain text should be shown as plain text only. Current Behaviour - When i download a document(excel file) with multiple tables(tabs), it shows some plain text as hyperlink, clicking on those links doesnt work. This works fine in case of single table(tab) document. When it happens The problem shows up only when all three are true: The user downloads the whole report as Excel ("Table Data"), which gives one file with many sheets. 2.The file is opened in the built-in iOS Quick Look / Files viewer. 3.At least one sheet has a real link in its header, footer or cells. It does not happen: 1.In the single table export (one sheet). Tapping the Google link shows the "Leave Files and open this link?" popup and opens the link. 2.In Microsoft Excel (Windows, Mac, iOS, web), even with the same multi-sheet file.

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?

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.

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.

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.