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?

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?

After updating to Sonoma, the following is logged in the Xcode console when an editable text field becomes key. This doesn't occur on any text field, but it seems to happen when the text field is within an NSPopover or an NSSavePanel. ViewBridge to RemoteViewService Terminated: Error Domain=com.apple.ViewBridge Code=18 "(null)" UserInfo={com.apple.ViewBridge.error.hint=this process disconnected remote view controller -- benign unless unexpected, com.apple.ViewBridge.error.description=NSViewBridgeErrorCanceled} What does this mean?

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.

After updating to Sonoma and Xcode 16, I get this when I run my macOS (objective C) app from Xcode: Class Trace is implemented in both /System/Library/PrivateFrameworks/AudioAnalytics.framework/Versions/A/AudioAnalytics (0x273300e68) and /Users/jean/Library/Developer/Xcode/DerivedData/STRyper-ezekeictrpwjnggxusdnbwqpzqtf/Build/Products/Debug/STRyper.app/Contents/MacOS/STRyper (0x10015b8f0). One of the two will be used. Which one is undefined. How do I solve this without changing the class name? Trace is a subclass of NSManagedObject. FYI, the core data model uses the "Xcode 8.0" tools version and the module of the class is set to "Global namespace". Changing the class name doing so would force me to create a new core data model, and mess with other things as I encode some core data objects to files using NSCoding (which uses class names). Thanks.

After each macOS update come new annoying log messages. So after updating to Sonoma and Xcode 16, I see the following logged in the Xcode console whenever my app shows an NSPredicateEditor. Failed to find localization for values: All, of the following are true I tried setting the "localize" attribute to "never" in the attributes inspector of the corresponding menu/text fields from interface builder, to no avail. Any suggestions ?

It seems that when an entity has and ordered to-many relationship to the same entity, inserting an object into the ordered set causes other objects of the set to turn into faults during the next save of the managed object context. I verified it with several applications. For the sake of example, the entity will be called Folder and the ordered to-many relationship subfolders (an NSOrdereset), with a cascade delete rule. The reciprocal to-one relationship is called parent. Assuming you have a Folder object with two subfolders, removing the last subfolder from the set (setting its parent to nil) and reinserting it at index 0 with insertObject:<>inSubfoldersAtIndex:0 will turn the other subfolder into a fault at the next save. Now assuming that other folder has a name attribute (NSString) that is bound to a textfield in your UI, the name of that subfolder will disappear when the context saves, since it becomes nil while the subfolder is turned into a fault. Is this expected behavior? Note: I'm using Objective C, Xcode 15 and macOS sonoma, but I've seen this issue occur on previous macOS versions.

Since the macOS 14.4 and Xcode 15.3 update, I'm getting these message posted in the Xcode log when I run a Mac app, even for template apps. BOOL _NSPersistentUIDeleteItemAtFileURL(NSURL *const __strong) Failed to stat item: file:///Users/xxx/Library/Containers/xxx/Data/Library/Saved%20Application%20State/xxx.savedState/restorecount.plist I've already reported this to Apple. I just wanted to know if I was the only one affected (it happens on all my development Macs).

This message is logged in Xcode when I start editing a text field in my macOS app. This started appearing in Sonoma. This doesn't happen in Ventura (same Xcode project). Every text field in the app is affected, regardless of the window. What could be the cause of this?

When an NSButton's value and hidden state are bound to properties, changing either property enables the button. See example code: @interface MyClass () @property (nonatomic) BOOL buttonHidden; @property (nonatomic) BOOL buttonState; @end @implementation MyClass { __weak IBOutlet NSButton *button; // The button is in a view designed in IB } - (void)awakeFromNib { [super awakeFromNib]; [button bind:NSHiddenBinding toObject:self withKeyPath:@"buttonHidden" options:nil]; [button bind:NSValueBinding toObject:self withKeyPath:@"buttonState" options:nil]; button.enabled = NO; self.buttonHidden = NO; // This enables the button. If this line isn't executed, the buttons stays disabled. } @end Note that the issue occurs only of both properties are bound. I wonder if this is by design or a bug.

I started wondering after I saw jerky scrolling in my app when it draws a lot of curves (NSBezierPath), under Sonoma. So I made a simple Cocoa app, using the Xcode 15 objC template. The app only has a NSView subclass as a document view of an NSScrollView (not a subclass), which has copiesOnScroll set to YES. The document view returns YES to isOpaque and its class returns YES to isCompatibleWithResponsiveScrolling. Yet whenever I scroll, -drawRect is called on the document view and the dirtyRect passed is the same as its visibleRect. i.e., the view is asked to redraw its whole visible content at every scroll step. Clearly, responsive scrolling isn't working. I tried setting wantsLayer to YES or NO, it doesn't change anything. prepareContentInRect is called, but it doesn't seem that the rect argument covers a region of the view that is not visible. Am I doing something wrong or is responsive scrolling a thing of the past?

I have an issue with my macOS objC app that uses CATextLayer instances that adapt to the app appearance (dark, light). I had no problem with Ventura, so I suppose this is a Sonoma bug. But maybe I'm not doing the right things. Within -updateLayer , I call stringLayer.foregroundColor = NSColor.textColor.CGColor. (stringLayer is an instance of CATextLayer.) NSColor.textColor should adapt to the app appearance. But the color doesn't always change when the app appearance changes. So the text would turn black in dark mode (hence illegible) and white in light mode when I toggle the mode in the system preferences. To investigate wether the issues was specific to the system text color, I tried (again, within -updateLayer): NSColor *color = [NSApp.effectiveAppearance.name isEqualToString:NSAppearanceNameDarkAqua]? NSColor.redColor : NSColor.greenColor; stringLayer.foregroundColor = color.CGColor; I basically get the same issue. The correct color shows when the app launches, but doesn't change the first time I toggle the mode (dark/light). So the wrong color associates with the app appearance (red with light mode and green with dark mode). The code below works : NSColor *color = [NSApp.effectiveAppearance.name isEqualToString:NSAppearanceNameDarkAqua]? NSColor.redColor : NSColor.greenColor; NSDictionary *dic = @{NSFontAttributeName: [NSFont labelFontOfSize:10.0], NSForegroundColorAttributeName:color}; NSAttributedString *string = [[NSAttributedString alloc] initWithString:@"test" attributes: dic]; stringLayer.string = string; But the code below doesn't. The layer text color doesn't change when the app appearance changes. NSDictionary *dic = @{NSFontAttributeName: [NSFont labelFontOfSize:10.0], NSForegroundColorAttributeName:NSColor.textColor}; NSAttributedString *string = [[NSAttributedString alloc] initWithString:@"test" attributes: dic]; stringLayer.string = string; Note that the issue appears to be specific to the foreground color. The background color (which I update in the same method) is always set properly.

I'm getting these log messages: +[CATransaction synchronize] called within transaction whenever I spawn or resize and NSOpenPanel (or save panel). To investigate, I created the simplest possible test app, with no window and only this method that I override in AppDelegate.m: - (void)applicationDidFinishLaunching:(NSNotification *)aNotification { NSOpenPanel *panel = NSOpenPanel.openPanel; panel.allowedFileTypes = @[@"public.plain-text"]; [panel beginWithCompletionHandler:^(NSModalResponse result) { }]; } This is basically all the code I added. And this still triggers the warning message above. The message is also posted whenever I resize the panel. I wasn't getting these messages before updating to Ventura. What am I doing wrong?