Oops, it turns out that I implement a faulty cursorUpdate method in my view... 😅 EDIT: actually, that wasn't the issue. Still investigating... (Dang, I can't invalidate my answer.)

Ok, it turns out that if I send the last two messages above to the clipView with self.contentView.automaticallyAdjustsContentInsets = NO; self.contentView.contentInsets = NSEdgeInsetsMake(0, 0, 0, 0); AppKit no longer tries to scroll the view too far. But the clipView still shows behind the rulers, as opposed to what the documentation says. At least, I can do my custom tiling.

I can't get a clear answer to this, but as online stuff describes how to implement undo in core data with code and does not appear to mention automatic undo, I'm coming to the conclusion that core data apps simply no longer support this ("automatic" as in "you don't have to code anything"). Can anyone confirm that I have to implement undo support with code? It would help if I got an answer to this instead or looking for how to make this work as it used to.... Thanks.

In case anyone is interested in the solution: I failed to do basic checks, i.e., that the managed object context I used had an undo manager that is not nil. In older macOS versions, a new context used to come with an undo manager by default. This must have changed with a macOS update.

I'd like to know if anyone else has this issue.

Is anyone else experiencing issues with tracking rectangles in Ventura?

I'm getting this warning on an Obj-C Mac App using an NSOutlineView. This not specific to SwiftUI. This appears to happen when I ask the outline view to load several "parent" rows that are not visible (they extend below the visible rect). Hence, this only happens when I load a certain number of rows (or more), be it with -reloadData or -insertItemsAtIndexes:inParent:withAnimation:. The total height of the rows that are loaded appears to be a factor, since I get this waning when I load fewer rows if rows are taller. It may happen with only 5 rows. It seems I only get the warning if the rows that are loaded have child rows (i.e., they represent parent items with children). When I load only "child" rows (with -insertItemsAtIndexes:inParent:withAnimation: and inParent is not nil), I don't get this warning, even if I load many, many children. I don't like this. I didn't get the warning before I update to Ventura/Xcode 14.2.

I'm seeing the same messages during debug of my objective-c Mac app. This started appearing after some macOS/Xcode update.

I'm getting the same message when I quit my App during a debug session. That started occurring after some macOS/Xcode update. This message isn't associated with any issue and I confirm that it is posted even when quitting a bare-bones template Mac app.

Ok, I first thought that all projects were affected, but it turns out that only one was. I just deleted the caches and indexing works again. The issue may not have been related to the Ventura update.

I no longer see this warning posted on the console after updating to Xcode 15. I'm still using Ventura.

I no longer see these log messages after updating to Xcode 15 / macOS 13.6.

Of note: preparedContentRect is called, but a call to super within the method returns NSZeroRect, which contradicts the documentation where it is said that the rectangle always includes the visible portion of the view. Returning the view's bounds from this method doesn't change anything. No overdraw appears to be performed, the visible rectangle is redrawn at each scroll step. Setting the layerContentsRedrawPolicy to NSViewLayerContentsRedrawNever does nothing to the scrolling behaviour. Again, the visible rectangle is redrawn at each scroll steps. I wonder how appkit does it btw, because with this setting, setNeedsDisplay does not redraw the view (which is expected). To sum up: whatever I do, appkit wants to redraw the visible rectangle during scrolling. This is a regression from macOS 10.0, which at least had copiesOnScroll to avoid doing unnecessary calculations to redraw only the part of the view that becomes visible.

Strangely, general scrolling performance has not decreased, at least not on my MacBook Pro.

Hi. In case you're still around, I'd like to know what solution you've found to your problem. I too need to draw curves on a view that can be very wide, and a single CALayer cannot handle it (even if drawing is constrained to a small rectangle). My current solution is to use several contiguous CALayers, which is less than ideal...