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.

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?

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

Hi systems programming guys. I’m exploring the macOS as a low-level itself, so when I use the otool(1) utility to inspect a tiny objc helloworld program, it told me that there is a shared library like /usr/lib/libobjc.A.dylib (not identical) but I didn’t find that in path /usr/lib/. Also the docs sucked (see below). I want to know more details about the objc runtime on macOS (beta 27.6 +) and be seeking for help here because there are few materials online and not even to say the sucked AI. The prima motivation is the runtime itself and how it works. Of course I would love to read disassembled code and manpages or using utilities that Apple offered to understand those things . But I really don’t know where is the runtime if both docs and otool output lied. The latest documentation about Objective-C Runtime is outdate and it said “Objective-C runtime library support functions are implemented in the shared library found at /usr/lib/libobjc.A.dylib.”

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.

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.

We have observed significant UI changes to the SFAuthorizationPluginView login experience in the latest macOS Golden Gate Beta 5. After entering the account password at the SFAuthorizationPluginView screen, we were previously able to access the buttons and other child elements present in the SFAuthorizationPluginView using "accessibilityChildrenInNavigationOrder" . Currently the method returns that there are no child elements eventhough there are clearly child elements presents including apple's native Ok and Cancel buttons.This behaviour is consistently reproducible in our testing. Steps to Reproduce Configure and launch an unlock authorization plug-in using SFAuthorizationPluginView. Display the authorization UI in unlock. Enter the account password. Wait for the authorization UI to finish transitioning to the authenticated state. Query the SFAuthorizationPluginView accessibility hierarchy. Specifically query accessibilityChildrenInNavigationOrder. Observe that the method returns no child accessibility elements. Inspect the UI visually or using Accessibility Inspector and observe that child controls are still present, including the native OK and Cancel buttons. We would like to understand: 1.Is this a known issue with the current macOS Golden Gate Beta? 2.Is this expected behaviour due to the UI redesign, or is it considered a bug? 3.If it is a known issue, is there a fix planned for an upcoming beta or the final release? Any information or guidance would be appreciated. Thank you.

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/

It seems like macOS 27 beta 2 has some issues with NSStatusItem buttons added to the menu bar - this creates difficulties for some menu bar extra apps. NSStatusItem buttons does not receive mouse hover/movement events - FB23329983 On macOS 27, views inside an NSStatusItem button no longer receive hover or mouse-movement events. The same code works correctly on macOS 26. What I tried: An NSTrackingArea attached to a subview of NSStatusBarButton An NSTrackingArea attached directly to the status-bar button Replacing NSStatusItem.view with a custom view Embedding an NSHostingView and using SwiftUI onHover/onContinuousHover NSStatusItem button highlight cannot be set programmatically. - FB23330269 The following code no longer has any effect (does not provide the highlight capsule): NSStatusItem.button?.highlight(true) NSStatusItem window occlusionState no longer reflects hidden menu bar visibility - FB23349447 The following no longer works: statusItem.button?.window?.occlusionState.contains(.visible) These changes may be related to some of the touch related changes or maybe it's about how menu items are now seemingly more "managed" in a way that their position, visibility may change in a way that is transparent/undetectable to the app.

I am trying to use an NSSearchToolbarItem using AppKit directly in Objective-C. If I perform a search and then click the cancel icon, my target/action is called while the NSSearchField still contains the search text (not yet cleared) and the delegate has not yet received the ending search invocation. In other words, it looks exactly the same as if the user had submitted the same search twice. Google's AI suggested using the controlTextDidChange method, but that was deprecated long ago. My current solution is to ignore searches that appear redundant (although they may not be, if the data being searched changes). This is on macOS 26.6.

I'm distributing a Unity-built game on the Mac App Store and I've been rejected twice under Guideline 4 (Design) with the same wording: "We still noticed that the app presents a window that does not contain the necessary title bar buttons and includes an interface window but is missing the required App Menu and Dock Icon or Menu Bar Extra." I'd like to hear from anyone who has hit this with a Unity (or otherwise non-native) macOS app and got it resolved. What I'm seeing: When the game runs, the macOS menu bar is displayed, but it only shows the app name and a single "Window" menu. The standard menus Apple expects (App menu with About/Quit, Edit, Window, Help) are not there. Unity does not populate the native macOS menu bar on its own, and there's no Player Setting that generates these menus. What I've already tried: Switched the app from borderless window to a standard windowed mode, so the window has its title bar and close/minimize/zoom buttons. Confirmed the Dock icon appears with the running indicator in standard windowed mode. Verified there is no LSUIElement key forcing the app into accessory mode in Info.plist. Despite this, the rejection came back identical. My questions: For those who passed review, did you populate the full native menu bar (App / Edit / Window / Help), or did Apple accept the app another way? Is a complete standard menu bar strictly required, or does shipping the app in fullscreen — where macOS hides the menu bar by design, as with most Mac games — satisfy the reviewer on this point? For the "title bar buttons" and "Dock icon" part of the rejection specifically: what exactly does the reviewer expect to see, and does fullscreen change how they evaluate it? If you resolved this, did you mention the change in the App Review notes, and did that help? Any concrete experience — especially with games that launch fullscreen — would be very helpful. Thanks.

Hello, I am currently developing a printed data security feature for a cross-platform DLP system. On other platforms, this functionality relies on a cross-platform third-party library. On macOS, this library depends on the Core Graphics and AppKit frameworks. So, such dependency makes it impossible to use the code within a launch daemon, which is where this mechanism needs to run. As an alternative approach, I am considering implementing the necessary functionality inside a CUPS filter. However, I have some doubts regarding the execution context of the CUPS filter process. Is it safe to use AppKit within a CUPS filter? Thank you in advance.

In the below code, I create two windows, and use a window delegate to make sure that whenever the first is fullscreened, its menubar and dock are hidden properly. However, when I fullscreen the first window and go back to the desktop to see my second window, the second window's minimize button is grayed out and using miniaturize on it will not work either. I've tried various things; it seems like if I fullscreen the second window and the unfullscreen it, it then becomes minimizable without additional side effects. Is there any reason why this is happening? This seems like a bug in AppKit... so how do I work around it programmatically? #import <Cocoa/Cocoa.h> @interface AppDelegate : NSObject <NSApplicationDelegate, NSWindowDelegate> @property (strong) NSWindow *mainWindow; @property (strong) NSWindow *secondaryWindow; @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { NSRect mainRect = NSMakeRect(100, 300, 400, 300); self.mainWindow = [[NSWindow alloc] initWithContentRect:mainRect styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskMiniaturizable | NSWindowStyleMaskResizable) backing:NSBackingStoreBuffered defer:NO]; [self.mainWindow setTitle:@"Main Window (Go Fullscreen Here)"]; [self.mainWindow setDelegate:self]; NSTextField *mainLabel = [NSTextField labelWithString:@"1. Click the green zoom/fullscreen button on THIS window.\n\n2. Look at the other window's yellow minimize button."]; [mainLabel setFrame:NSMakeRect(20, 100, 360, 100)]; [[self.mainWindow contentView] addSubview:mainLabel]; [self.mainWindow makeKeyAndOrderFront:nil]; NSRect secondaryRect = NSMakeRect(550, 300, 400, 300); self.secondaryWindow = [[NSWindow alloc] initWithContentRect:secondaryRect styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskMiniaturizable | NSWindowStyleMaskResizable) backing:NSBackingStoreBuffered defer:NO]; [self.secondaryWindow setTitle:@"Secondary Window (The Victim)"]; NSButton *testButton = [NSButton buttonWithTitle:@"Try code [window miniaturize:]" target:self action:@selector(attemptProgrammaticMinimize:)]; [testButton setFrame:NSMakeRect(80, 130, 240, 40)]; [[self.secondaryWindow contentView] addSubview:testButton]; [self.secondaryWindow makeKeyAndOrderFront:nil]; } - (NSApplicationPresentationOptions)window:(NSWindow *)window willUseFullScreenPresentationOptions:(NSApplicationPresentationOptions)proposedOptions { return NSApplicationPresentationFullScreen | NSApplicationPresentationHideMenuBar | NSApplicationPresentationHideDock; } - (void)attemptProgrammaticMinimize:(id)sender { [self.secondaryWindow miniaturize:nil]; NSLog(@"[Repro] Minimize attempted"); } - (BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender { return YES; } @end int main(int argc, const char * argv[]) { @autoreleasepool { NSApplication *app = [NSApplication sharedApplication]; [app setActivationPolicy:NSApplicationActivationPolicyRegular]; AppDelegate *delegate = [[AppDelegate alloc] init]; [app setDelegate:delegate]; [app activateIgnoringOtherApps:YES]; [app run]; } return 0; }

I'm working on this UI where I present a popover and user fills in some brief information. There are various buttons and a single editable text field in the UI. When 'Full Keyboard access' is disabled in System Settings and the popover is presented the editable NSTextField is the initial first responder and the user can begin typing immediately. This is the behavior that I expect and want. Now when full keyboard access is enabled the text field does not become the immediate first responder (and none of the buttons in the popover have 'focus' state either) so initially hitting a key does nothing. To me this feels unnatural and is not the expected behavior. To interact with the text field with full keyboard access I have to do one of the following: Use the mouse to click the text field (which is an extra step). Or Press tab several times to move 'Focus' (initially no button has it) all the way down to the textfield. Both requirements slow down the user. Is this expected behavior? Shouldn't the initial key view follow the natural first responder (in this case an editable text field) and the user can tab away from that starting location? instead nobody has key focus when the popover is first presented until tabbing is initiated. I can currently 'workaround' this it seems by manually setting the text field as first responder in viewDidAppear [self.view.window makeFirstResponder:self.theTextField]; Then the text field accepts keyboard input immediately. But when 'Full keyboard access' is disabled (which I assume is the more typical configuration) this is not required, the text field just gets first responder by default. If this is not the expected behavior let me know and I may file a feedback.

From the currently available information, it seems like the only way to get the new-in-Tahoe sidebar inspector effect is to use a NSSplitView in conjunction with NSSplitviewController & inspectorWithViewController:. I'm currently trying to get the same inspector effect - which also affects the looks of controls inside the inspector, like text fields, which switch to a gray-ish background - in a totally custom splitter-like view hierarchy that is way more complex than NSSplitView and thus cannot inherit or take advantage of it. Is there a way to integrate this effect in a custom view? Maybe using NSVisualEffectView or NSGlassEffectView?

My app is a bit of a special case and relies on a custom view in a NSStatusItem. I use a NSHostingView and add it as a subview to my NSStatusItem's .button property. Since macOS 26 Tahoe, even simple animations like a .frame change of a Circle won't animate smoothly even though the same SwiftUI animates normally in a WindowGroup. class AppDelegate: NSObject, NSApplicationDelegate { private let statusItem: NSStatusItem = NSStatusBar.system.statusItem(withLength: NSStatusItem.variableLength) func applicationDidFinishLaunching(_ aNotification: Notification) { let subview = NSHostingView(rootView: AnimationView()) let view = self.statusItem.button view?.addSubview(subview) subview.translatesAutoresizingMaskIntoConstraints = false guard let view = view else { return } NSLayoutConstraint.activate([ subview.centerXAnchor.constraint(equalTo: view.centerXAnchor), subview.centerYAnchor.constraint(equalTo: view.centerYAnchor), subview.widthAnchor.constraint(equalToConstant: 22), subview.heightAnchor.constraint(equalToConstant: 22) ]) } } struct AnimationView: View { @State private var isTapped = false @State private var size: CGSize = .init(width: 4, height: 4) var body: some View { Circle() .fill(.pink) .frame(width: size.width, height: size.height) .frame(width: 20, height: 20) // .frame(maxHeight: .infinity) // .padding(.horizontal, 9) // .frame(height: 22) .contentShape(Rectangle()) // .background(Color.blue.opacity(0.5)) .onTapGesture { withAnimation(.interactiveSpring(response: 0.85, dampingFraction: 0.26, blendDuration: 0.45)) { // withAnimation(.spring()) { if isTapped { size = .init(width: 4, height: 4) } else { size = .init(width: 16, height: 16) } } isTapped.toggle() }} } Example project: https://app.box.com/s/q28upunrgkxyyd97ovslgud9yitqaxfk

NSTrackingSeparatorToolbarItem adds a white band over the top of the leading split view panes when in full screen mode on macOS 27. That white band appears to have the height of the toolbar. I filed FB23827858 with a sample project and a video demonstrating the issue. I also wrote about it at: https://virtualsanity.com/202607/nstrackingseparatortoolbaritem-causes-problems-when-putting-a-window-in-full-screen-on-golden-gate-macos-27/ I am hoping this is addressed before macOS 27 ships.

https://gist.github.com/MorusPatre/4b1e93973c3e4133794512fd7eefee48 This Is a Test App to find out how to actually achieve the exact sidebar styling Apple uses for Finder, Photos etc. The crucial part is how do I make it so the symbol and name of the selected row use the accent colour with active and inactive styling rather than having the accent colour for the row background? It shouldn't be that complicated I feel like but every AI model (even Claude Fable 5) fails at that and I haven't found apps or videos where that is explained so is that just a classic case of "Apple doesn't want you to know"?

In AppKit, NSSavePanel can be used to ask the user for a destination URL before the app creates a file. What is the SwiftUI equivalent for this? .fileImporter covers the NSOpenPanel case well enough, but I have not found a SwiftUI API that matches the simple NSSavePanel case where the app only needs the URL. There's a new API in .fileExporter that appears close, but it requires a non nil WritableDocument, and seems designed around SwiftUI performing the file export. My use case is a macOS app that creates new documents backed by SQLite. SQLite needs a file path so it can create the database at that location. With NSSavePanel, I can ask the user where to save the document, receive a URL, and then create the SQLite database myself. Is there a SwiftUI API for this on macOS 26 or later? If not, is NSSavePanel still the recommended approach for this case?

Hello, I'm building an app that is designed to largely mimick Apple's own audio auto-switch behavior when switching between different audio output devices like MacBook Pro speakers and AirPods. The purpose is to "lend a hand" to certain apps, like CrossOver (wine) ran x68-64 apps that don't seem to respond well to CoreAudio changing the audio output after the x68-64 program has already init its audio after startup. Thus, I don't actually need much of a GUI except for a few specific features, and perhaps later some ehancements I'd like to add that can make use of a proper GUI. I've decided to implement the MacOS Tahoe Apple Liquid Glass UI to keep the user experience as streamlined and intuitive as possible. I've largely been successful: The GitHub page goes into greater detail showing the greater context of the AppKit API's I'm using to achieve this UI design. There is just one issue I haven't been able to solve, how to get the sidebar tab(s) to blur when scrolled underneath the Window Controls (Traffic Light) buttons. These tabs are part of a NSScrollView underneath the NSToolbar aligned from the top-most left and right window edges, but split from the right-hand content side via NSSplitViewController > NSSplitViewItem (again exact topology is at the page "link" below). On the content side (right side), I used NSSplitViewItemAccessoryViewController to create the blur zone so that when its own NSScrollView content is scrolled upwards, past the toolbar NSToolbar, it would apply a progressive tint+blur effect, just as Apple has implemented in their own apps. This wasn't really automatic since I did have to elect to use it as part of a MacOS 26.1+ specific class (NSScrollEdgeEffectStyle), but it's working on the content side nonetheless: Now I am trying to get the same effect working on the sidebar side and am having issues with this. Please see the page below as it summarizes our test attempts with greater detail. I've only gotten this far by reading "obscure" comments in the SDK's so I'm really hoping this is just a ID10T error in that I've missed something. Note: even though I only have 3 tabs currently in the sidebar NSScrollView, I will eventually populate this further, especially with some user configurable stuff on my roadmap. That said, the sidebar is only "scrollable" right now because I've left the "vertical scroll elasticity" enabled, intentionally. (.verticalScrollElasticity [IS NOT] .none! Therefore, I can still "scroll" the enumerated tabs inside the sidebar's NSScrollView upward behind the Traffic Light buttons, to validate if the blur+tint effect is being rendered. I say all of that to ask if, perhaps, the reason that the blur+tint effect is not rendering in the Window could be because there's not enough content to render in the sidebar to produce a scrollbar, and simply leaving .verticalScrollElasticity "enabled" is not sufficient to produce this effect? I don't know that for sure, but it's the only thing I can think of at this point. Its not obvious to me though. This app is written entirely in Swift (v6.3.3) and will require a minimum of MacOS Tahoe 26.1.X due to the AppKit API's I'm using (namely NSScrollEdgeEffectStyle). GitHub Page documenting issue in greater detail (remove the spaces): HT TP S:// gitdev.brianbutts.me /sidebar-scroll-edge-blur. html