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?

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/***/Library/Containers/***/Data/Library/Saved%20Application%20State/***.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?

This message has started appearing in the Xcode console when I test run my app, I think after the 13.3 macOS update, or the associated Xcode update. This message is posted: when the app launches (my code does not do anything with the app window). when I right click the app window to open a contextual menu while the application is in the background. when I click a button on the window with the cmd key pressed, while the app is in the background. I don't see why a warning should be posted in these situations. It looks like log noise to me. EDIT: this warning is posted even when testing the template Mac app (objective-C, xib) with no additional code. This is on Xcode Version 14.3 (14E222b)

After updating to Ventura 13.4, Xcode 14.3 no longer indexes files in my projects. The "indexing" phase that is reported on the status bar does not list a number of files that it should be processing, and doesn't seem to actually do anything. As a result, autocompletion, code checking, editing in scope, etc. not longer work. Am I the only one experiencing this issue, and how can I fix it?

Hi, quartz debug 4.2 (from the "Additional Tools for Xcode 14.2") doesn't show most tracking rectangles on macOS Ventura. I tested this on two Macs. Any solution to debug tracking areas on this OS? Thanks.

Hello, Amateur developer here. I dusted off a hobby core data app coded mostly under OSX 10.7, and which supported undo "for free" (as Apple say it). It still works when I build it with recent Xcode versions, except that it no longer supports undo. To understand why, I coded the most basic objective-C, core data (not document-based) app. In short, a single table view with a single column bound to an NSArray Controller set in "entity name" mode and bound to the managed object context. The core data model has a single entity class with a single NSString attribute (called "name", and which the table view column shows). It all works well, I can add and remove entities, and change their names from the table. Changes are saved normally... except there is nothing I can undo. The undo menu item is greyed out. I checked that my App Delegate implements the windowWillReturnUndoManager method and that this selector is called regularly. So to check that the undo manager sees anything to undo, I added this method to my App Delegate: - (IBAction)reportUndo:(id)sender {     NSLog(@"undo: %d", [self.persistentContainer.viewContext.undoManager canUndo]); } I can call this method by pressing a button. But it always logs "undo: 0", even after I add or remove entities. I take that the undo manager sees nothing to undo. This seems like rather basic stuff, but I can't understand why it doesn't work give given that it used to work in my more complex app without me doing anything special.

Hell, I'm making a macOS app with an NSScrollView showing a vertical ruler (subclass of NSRulerView). I want its clipview to fill the remaining space left by the ruler, I don't want it to be drawn underneath. Apple says this about the contentInsets property: When the value of this property is equal to NSEdgeInsetsZero, traditional tiling is performed. Rulers, headers, and other subviews are tiled with the contentView frame filling the remaining space. When the value of this property is not equal to NSEdgeInsetsZero, the rulers, headers, and other subviews are inset as specified. The contentView is placed underneath these sibling views and is only inset by the scroll view border and non-overlay scrollers. I get the later result. The clipview is placed underneath the ruler, even though my NSScrollView subclass implements this : -(void)awakeFromNib     [self setHasVerticalRuler:YES];     [self setRulersVisible:YES];     self.automaticallyAdjustsContentInsets = NO;     self.contentInsets = NSEdgeInsetsMake(0, 0, 0, 0); } If I specify positive insets (for example 10 instead of zeros), the scrollers are moved from the edges, which means the above code is executed. I can override the -tile command to get the tiling I want, but then the scrollview would scroll the document view too far (showing the srollview background at the left) to make sure that no content is hidden by the ruler (which cannot happen with my custom tiling). Any ideas?