Here's the result of a blank app from Xcode: https://imgur.com/a/1hMmwbO now there's only 3 items in the storyboard configuration: https://imgur.com/a/iGWWQE7 So I try to replicate that in code (some of this reproducer was generated by ChatGPT however the same issue I'm descrbing has been hit when using Python to objc bridges to construct the GUI) by specifying these 3 actions appropriately and see if the rest pops up. The code below changes the activation policy so that when I run ./a.out from the terminal it doesn't show as a window of Terminal but a separate app #import <Cocoa/Cocoa.h> @interface AppDelegate : NSObject <NSApplicationDelegate> @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)notification { // Build main menu NSMenu *mainMenu = [[NSMenu alloc] initWithTitle:@"MainMenu"]; // --- App menu with Quit --- NSMenuItem *appMenuItem = [[NSMenuItem alloc] init]; NSMenu *appMenu = [[NSMenu alloc] initWithTitle:@"App"]; NSMenuItem *quitItem = [[NSMenuItem alloc] initWithTitle:@"Quit" action:@selector(terminate:) keyEquivalent:@"q"]; [appMenu addItem:quitItem]; [appMenuItem setSubmenu:appMenu]; [mainMenu addItem:appMenuItem]; // --- Window menu with only Minimize, Zoom, Bring All to Front --- NSMenuItem *windowMenuItem = [[NSMenuItem alloc] initWithTitle:@"Window" action:NULL keyEquivalent:@""]; NSMenu *windowMenu = [[NSMenu alloc] initWithTitle:@"Window"]; [windowMenu addItem:[[NSMenuItem alloc] initWithTitle:@"Minimize" action:@selector(performMiniaturize:) keyEquivalent:@"m"]]; [windowMenu addItem:[[NSMenuItem alloc] initWithTitle:@"Zoom" action:@selector(performZoom:) keyEquivalent:@""]]; [windowMenu addItem:[NSMenuItem separatorItem]]; [windowMenu addItem:[[NSMenuItem alloc] initWithTitle:@"Bring All to Front" action:@selector(arrangeInFront:) keyEquivalent:@""]]; [windowMenuItem setSubmenu:windowMenu]; [mainMenu addItem:windowMenuItem]; [NSApp setMainMenu:mainMenu]; // Optional demo window (remove if you want zero windows) NSWindow *w = [[NSWindow alloc] initWithContentRect:NSMakeRect(200,200,400,200) styleMask:(NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskResizable | NSWindowStyleMaskMiniaturizable) backing:NSBackingStoreBuffered defer:NO]; [w setTitle:@"Demo"]; [w makeKeyAndOrderFront:nil]; [NSApp setActivationPolicy:NSApplicationActivationPolicyRegular]; } - (BOOL)applicationShouldTerminateAfterLastWindowClosed:(NSApplication *)sender { return YES; } @end int main(int argc, const char * argv[]) { @autoreleasepool { AppDelegate *delegate = [AppDelegate new]; [NSApplication sharedApplication]; [NSApp setDelegate:delegate]; return NSApplicationMain(argc, argv); } } Now, I only see 3 items that's literally specified https://imgur.com/a/LylRsaJ So, what allows interface builder to auto-add these extra items as opposed by creating it in code? Is there something in this reproducer of the Window menu that is missing that needs to make it happen programatically? Thanks! All tests done on macOS Tahoe

Getting this crash after I do this in PDFKit a lot: PDFSelection *nextSelect = [self.pdfView.document findString:currentSearchString fromSelection:currentSelction withOptions:NSCaseInsensitiveSearch]; if (nextSelect != nil) { self.pdfView.currentSelection = nextSelect; [self.pdfView scrollSelectionToVisible:nil]; } Which often leads to: 0 CoreFoundation 0x000000019ced4770 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x000000019c9b2418 objc_exception_throw + 88 2 CoreFoundation 0x000000019cfffe10 -[__NSPlaceholderDictionary initWithObjects:forKeys:count:] + 724 3 CoreFoundation 0x000000019cfa1ae4 +[NSDictionary dictionaryWithObjects:forKeys:count:] + 52 4 PDFKit 0x00000001cb56e0fc -[PDFView _axPostPageChangeNotification:] + 348 5 Foundation 0x000000019e6a25e4 __NSFireDelayedPerform + 372 6 CoreFoundation 0x000000019ce92290 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 32 7 CoreFoundation 0x000000019ce91f50 __CFRunLoopDoTimer +

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?

I have a SwiftUI Mac Catalyst app that shows a video player using a UIViewControllerRepresentable AVPlayerViewController. When I tap the full screen button on the native playback control, the app crashes. The app crashes only when built with Xcode 26. When I build with Xcode 16, this does not cause a crash. Here is some of the crash log: 0 CoreFoundation 0x000000019a5cc770 __exceptionPreprocess + 176 1 libobjc.A.dylib 0x000000019a0aa418 objc_exception_throw + 88 2 CoreFoundation 0x000000019a69b7fc -[NSException initWithCoder:] + 0 3 AppKit 0x000000019eeee1d0 -[NSBezierPath(NSBezierPathDevicePrimitives) _deviceMoveToPoint:] + 104 4 AppKit 0x000000019eeec930 -[NSBezierPath appendBezierPathWithRoundedRect:xRadius:yRadius:] + 200 5 AppKit 0x000000019eeea238 +[NSBezierPath bezierPathWithRoundedRect:xRadius:yRadius:] + 88 6 AVKitMacHelper 0x0000000247d73cc4 -[AVScrubberSliderCell drawBarInside:flipped:] + 1264 7 AppKit 0x000000019f35cf7c -[NSSliderCell drawInteriorWithFrame:inView:] + 680 8 AppKit 0x000000019f35ccbc -[NSSliderCell drawWithFrame:inView:] + 104 Any ideas!?

My app displays some text that should appear the same regardless of the container view or window size, i.e. it should grow and shrink with the container view or window. On iOS there is UILabel.adjustsFontSizeToFitWidth but I couldn't find any equivalent API on macOS. On the internet some people suggest to iteratively set a smaller font size until the text fits the available space, but I thought there must be a more efficient solution. How does UILabel.adjustsFontSizeToFitWidth do it? My expectation was that setting a font's size to a fraction of the window width or height would do the trick, but when resizing the window I can see a slightly different portion of it. class ViewController: NSViewController { override func loadView() { view = MyView(frame: CGRect(x: 0, y: 0, width: 400, height: 400)) NSLayoutConstraint.activate([view.widthAnchor.constraint(equalTo: view.heightAnchor, multiplier: 3), view.heightAnchor.constraint(greaterThanOrEqualToConstant: 100)]) } } class MyView: NSView { let textField = NSTextField(labelWithString: String(repeating: "a b c d e f g h i j k l m n o p q r s t u v w x y z ", count: 2)) override init(frame frameRect: NSRect) { super.init(frame: frameRect) textField.translatesAutoresizingMaskIntoConstraints = false textField.setContentCompressionResistancePriority(.defaultLow, for: .horizontal) addSubview(textField) NSLayoutConstraint.activate([textField.topAnchor.constraint(equalTo: topAnchor), textField.leadingAnchor.constraint(equalTo: leadingAnchor), textField.trailingAnchor.constraint(equalTo: trailingAnchor)]) } required init?(coder: NSCoder) { fatalError("init(coder:) has not been implemented") } override func resize(withOldSuperviewSize oldSize: NSSize) { // textField.font = .systemFont(ofSize: frame.width * 0.05) textField.font = .systemFont(ofSize: frame.height * 0.1) } }

I had noticed an unsettling behaviour about NSDocument some years ago and created FB7392851, but the feedback didn't go forward, so I just updated it and hopefully here or there someone can explain what's going on. When running a simple document-based app with a text view, what I type before closing the app may be discarded without notice. To reproduce it, you can use the code below, then: Type "asdf" in the text view. Wait until the Xcode console logs "saving". You can trigger it by switching to another app and back again. Type something else in the text view, such as "asdf" on a new line. Quit the app. Relaunch the app. The second line has been discarded. Am I doing something wrong or is this a bug? Is there a workaround? class ViewController: NSViewController { @IBOutlet var textView: NSTextView! } class Document: NSDocument { private(set) var text = "" override class var autosavesInPlace: Bool { return true } override func makeWindowControllers() { let storyboard = NSStoryboard(name: NSStoryboard.Name("Main"), bundle: nil) let windowController = storyboard.instantiateController(withIdentifier: NSStoryboard.SceneIdentifier("Document Window Controller")) as! NSWindowController (windowController.contentViewController as? ViewController)?.textView.string = text self.addWindowController(windowController) } override func data(ofType typeName: String) throws -> Data { Swift.print("saving") text = (windowControllers.first?.contentViewController as? ViewController)?.textView.string ?? "" return Data(text.utf8) } override func read(from data: Data, ofType typeName: String) throws { text = String(decoding: data, as: UTF8.self) (windowControllers.first?.contentViewController as? ViewController)?.textView.string = text } }

macOS 26 sometimes draws the title bar background even when setting NSWindow.titlebarAppearsTransparent = true and I don't understand the logic behind it, or how I can turn this off. I'm trying to do something similar to Xcode's "Welcome to Xcode" window which has a left view and a right table view. In my simplified example, the window contains a label and a text view. This used to work in macOS 15, but in macOS 26 the text view is partially covered by the title bar: As soon as I remove the line scrollView.hasVerticalScroller = true, the title bar isn't drawn anymore: The title bar also isn't drawn when removing the view on the left of the text view: I created FB20341654. This may be related to this other issue: NSWindow.titlebarAppearsTransparent only works after collapsing and expanding sidebar @main class AppDelegate: NSObject, NSApplicationDelegate { func applicationDidFinishLaunching(_ aNotification: Notification) { let window = NSWindow(contentViewController: ViewController()) window.titlebarAppearsTransparent = true window.titleVisibility = .hidden window.styleMask = [.titled, .closable, .fullSizeContentView] window.makeKeyAndOrderFront(nil) } } class ViewController: NSViewController { override func loadView() { view = NSView(frame: CGRect(x: 0, y: 0, width: 400, height: 200)) let scrollView = NSScrollView() scrollView.hasVerticalScroller = true // commenting this line out solves the issue scrollView.translatesAutoresizingMaskIntoConstraints = false scrollView.automaticallyAdjustsContentInsets = false let documentView = NSTextView() documentView.string = (0..<10).map({ "\($0)" }).joined(separator: "\n") scrollView.documentView = documentView let stack = NSStackView(views: [ NSTextField(labelWithString: "asdfasdfasdfasdf"), // commenting this line out also solves the issue scrollView ]) stack.orientation = .horizontal view.addSubview(stack) NSLayoutConstraint.activate([stack.topAnchor.constraint(equalTo: view.topAnchor), stack.leadingAnchor.constraint(equalTo: view.leadingAnchor), stack.trailingAnchor.constraint(equalTo: view.trailingAnchor), stack.bottomAnchor.constraint(equalTo: view.bottomAnchor)]) } }

Hi, I have encountered a strange issue on macOS 14 (Sonoma). I am creating a barrage (danmaku) effect: I have an NSView called BarragePipe which is a long horizontal rectangle (width = 50000). I treat this view as a "train" moving from right to left with animation. I add subviews (BarrageItem, which are also NSViews with text) to this "train." The background of BarragePipe is set to transparent, so visually it looks like the text items are moving across the screen. Here's the problem: On macOS 14, only the BarrageItem views whose X position is between 0 and the screen width display their text correctly. If a BarrageItem is positioned with X > screen width, its background still renders, but the text does not appear. This did not happen on previous macOS versions. It seems like the system is optimizing rendering for off-screen views. Has anyone encountered this? Is there a workaround to make the text always visible, regardless of the view's frame position? Thanks!

Environment macOS: Sequoia 15.x AppKit: NSTextField + custom NSFormatter Input: Korean IME Description I set a formatter to allow only 1 character. When typing with Korean IME, the field sometimes shows 2 characters while typing. Question How should I handle this case? Should it be done in NSFormatter or in the field editor (NSTextView)?

NSHostingSceneRepresentation, introduced in macOS 26, allows calling SwiftUI’s windows and other elements set in a Scene from AppKit. However, while Settings and WindowGroup set in the Scene can be invoked as expected using environment.openSettings() and environment.openWindow(id:) respectively, calling Window or WindowUtility doesn’t work. That is, the app just fails to open the desired window with the provided ID, and no error message or other feedback/crash/freeze appears. I expect that executing the openUtilityWindow(_:)action in the following code will display the UtilityWindow set in the scene. However, the window does not actually open. @main final class AppDelegate: NSObject, NSApplicationDelegate { private let scene = NSHostingSceneRepresentation { UtilityWindow("Utility Window", id: "UtilityWindow") { Text("Utility Window") .scenePadding() } } func applicationWillFinishLaunching(_ notification: Notification) { NSApp.addSceneRepresentation(self.scene) } @IBAction func openUtilityWindow(_ sender: Any?) { self.scene.environment.openWindow(id: "UtilityWindow") } } Is there something wrong with my implementation and expectation? Or is this a bug in NSHostingSceneRepresentation? Just in case, I’ve already filed this issue withFeedback Assistant: FB20310722 This feedback also includes a sample project reproducing this issue.

I can compile this #import <Cocoa/Cocoa.h> @interface AppDelegate : NSObject <NSApplicationDelegate> @property (strong) NSWindow *window; @property (strong) NSSlider *slider; @end @implementation AppDelegate - (void)applicationDidFinishLaunching:(NSNotification *)notification { // Window size NSRect frame = NSMakeRect(0, 0, 400, 300); NSUInteger style = NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskResizable; self.window = [[NSWindow alloc] initWithContentRect:frame styleMask:style backing:NSBackingStoreBuffered defer:NO]; [self.window setTitle:@"Centered Slider Example"]; [self.window makeKeyAndOrderFront:nil]; // Slider size CGFloat sliderWidth = 200; CGFloat sliderHeight = 32; CGFloat windowWidth = self.window.frame.size.width; CGFloat windowHeight = self.window.frame.size.height; CGFloat sliderX = (windowWidth - sliderWidth) / 2; CGFloat sliderY = (windowHeight - sliderHeight) / 2; self.slider = [[NSSlider alloc] initWithFrame:NSMakeRect(sliderX, sliderY, sliderWidth, sliderHeight)]; [self.slider setMinValue:0]; [self.slider setMaxValue:100]; [self.slider setDoubleValue:50]; [self.window.contentView addSubview:self.slider]; } @end int main(int argc, const char * argv[]) { @autoreleasepool { NSApplication *app = [NSApplication sharedApplication]; AppDelegate *delegate = [[AppDelegate alloc] init]; [app setDelegate:delegate]; [app run]; } return 0; } with (base) johnzhou@Johns-MacBook-Pro liquidglasstest % clang -framework Foundation -framework AppKit testobjc.m and get this neat liquid glass effect: https://github.com/user-attachments/assets/4199493b-6011-4ad0-9c9f-25db8585e547 However if I use pyobjc to make an equivalent import sys from Cocoa import ( NSApplication, NSApp, NSWindow, NSSlider, NSMakeRect, NSWindowStyleMaskTitled, NSWindowStyleMaskClosable, NSWindowStyleMaskResizable, NSBackingStoreBuffered, NSObject ) class AppDelegate(NSObject): def applicationDidFinishLaunching_(self, notification): # Create the main window window_size = NSMakeRect(0, 0, 400, 300) style = NSWindowStyleMaskTitled | NSWindowStyleMaskClosable | NSWindowStyleMaskResizable self.window = NSWindow.alloc().initWithContentRect_styleMask_backing_defer_( window_size, style, NSBackingStoreBuffered, False ) self.window.setTitle_("Centered Slider Example") self.window.makeKeyAndOrderFront_(None) # Slider size and positioning slider_width = 200 slider_height = 32 window_width = self.window.frame().size.width window_height = self.window.frame().size.height slider_x = (window_width - slider_width) / 2 slider_y = (window_height - slider_height) / 2 self.slider = NSSlider.alloc().initWithFrame_(NSMakeRect(slider_x, slider_y, slider_width, slider_height)) self.slider.setMinValue_(0) self.slider.setMaxValue_(100) self.slider.setDoubleValue_(50) self.window.contentView().addSubview_(self.slider) if __name__ == "__main__": app = NSApplication.sharedApplication() delegate = AppDelegate.alloc().init() app.setDelegate_(delegate) app.run() I get a result shown at https://github.com/user-attachments/assets/7da022bc-122b-491d-9e08-030dcb9337c3 which does not have the new liquid glass effect. Why is this? Is this perhaps related to the requirement that you must compile on latest Xcode as indicated in the docs? Why, is the compiler doing some magic?

In my Mac app, there is a menu item whose title is "Copy", and another called "Zoom to Marker". Apparently appkit sees fit to inject its own images into these items (off-state images I suppose). Why it was consider a good idea to begin with is unclear, because how can you be sure these images are appropriate? If that wasn't bad enough, the framework does not even check that these menu items already have off state images. So now the menu items get two images! How do I prevent this? Note: I use Xcode 16.

I have an NSSplitViewController with three columns: sidebar full-height content view with NSScrollView/NSTableView detail view. There's no (visible) titlebar and no toolbar. This layout has worked fine for years, but in Tahoe an unwanted overlay (~30-50px high) appears at the top of any column containing a scroll view with table content. Xcode suggests it's an NSScrollPocket. My research suggests it... Only affects columns with NSScrollView Plain NSView columns are unaffected Overlay height varies (~50px or ~30px depending on how I mess with title / toolbar settings) Disabling titlebar/toolbar settings reduces but doesn't eliminate the overlay The overlay obscures content and there doesn't appear to be any API to control its visibility. Is this intended behavior, and if so, is there a way to disable it for applications that don't need this UI element? If it helps visualise the desired result, the app is https://indigostack.app Any guidance would be appreciated!

When disabling the opacity slider of color panels, my app crashes with unsatisfiable layout constraints. Feel free reproduce with a minimal test project: A macOS app based on the Xcode 26.0 template with only one line added to the ViewController's viewDidLoad() function: NSColorPanel.shared.showsAlpha = false The issue doesn't occur if this property is set to "true" or not set at all. I just filed a corresponding bug report (FB20269686), although I don't expect any feedback from Apple ... as numerous issues I reported were never updated or commented at all (after migrating from RADARs).

I have some working Objective-C code that displays a WKWebView and allows printing that content. However, it uses the method -[WKWebView printOperationWithPrintInfo:], which the documentation says is deprecated as of macOS 10.15. However, it doesn't say why this method is deprecated, or what the recommended replacement is. The declaration in WKWebView.h does not even indicate that the method is deprecated. But as an alternative, I tried using +[NSPrintOperation printOperationWithView:printInfo]. Doing it that way just prints a blank page. So, should I keep doing it the doubtful way?

Hi everyone, After upgrading to macOS 26 (Tahoe) I’ve run into an issue: NSTextField becomes noticeably blurry when its parent layer is transformed (CATransform3D or CGAffineTransform). On macOS 15 (Sequoia) the exact same code worked fine — text stayed sharp. Interestingly, an NSImage backed by a PDF representation transforms without any problem and remains perfectly crisp, but labels do not. What I’ve tried so far Checked the contentsScale of the layers Setting magnificationFilter = .nearest Toggled shouldRasterize on/off and adjusted rasterizationScale Have there been any Core Animation or AppKit changes in macOS 26 that affect text rendering when transforming layers? What’s the recommended way now to keep NSTextField text sharp (similar to how vector PDF images behave) when scaling its parent layer? Any insights, best practices, or workarounds would be greatly appreciated. Thanks in advance!

create a sample XCode project using Objective-C and stroybook (xib) using latest XCode beta open MainMenu.xib, and select Main Menu → File → Print... remove the image like below 4. build it 5. run it on macOS 26 beta 7 6. The menu item "print.." still have "Image" Is there any way to remove image for one menu item. I have also tried NSMenuItem.image = nil, but still not work. The issue I met on my own app is that I cannot remove icons for "Zoom In", "Zoom Out" and many other menu items, which makes the menu items not aligned properly.

I noticing that Monterey defaults to the NSWindowToolbarStyleAutomatic / NSWindowToolbarStyleUnified toolbar style, which suppresses the "use Small Size" menu item and customization checkbox. So I've set the window to use NSWindowToolbarStyleExpanded. However, the toolbar will no longer change to a smaller icon size, as it did in MacOS 10.14, 10.15, and 11.0. I've tried to set the toolbar item sizing to "Automatic" for all of our toolbar icons, but that results in bad positioning in both Regular and Small Size mode -- the height is way too big. The native size of the icon .png files are 128 x 128. What's odd is that if I resize the window with the toolbar to be wider, the NSToolbarItems in the overflow area will be displayed in the toolbar are 128 x 128, where the rest of the toolbar icons get displayed as a 32 x 32 icon. The only way to get it to layout remotely correct is to make the NSToolbarItem to have an explicit minimum size of 24 x 24 and maximum size of 32 x 32. And that USED to allow "small size", but on Monterey, it no longer does. Anyone had any success with small size icons on Monterey?

Is there a way to access an Icon Composer .icon file in Swift or Objective-C? Any way to get this in an NSImage object that I can display in an image view? Thanks.

When I compiled my legacy project with Tahoe's macOS 26 SDK, NSRulerViews are showing a very different design: Under prior macOS versions the horizontal and verrical ruler's background were blurring the content view, which was extending under the rulers, showing through their transparency. With Tahoe the horizontal ruler is always reflecting the scrollview's background color, showing the blurred content view beneath. And the vertical ruler is always completely transparent (without any blurring), showing the content together with the ruler's markers and ticks. It's difficult to describe, I'll try to replicate this behavior with a minimal test project, and probably file a bug report / enhancement request. But before I take next steps, can anyone confirm this observation? Maybe it is an intentional design decision by Apple?