A Solution: It appears that setNeedsDisplay has changed. My family tree is drawn in 2 passes: pass 1 calculates size of each tree cell. When that is done, tree cells (which are subviews in the main NSView) are moved to fill space by various options. Pass 2 then redraws all cells in their new proper locations. My code called setNeedsDisplay on the main NSView after subviews are repositioned. Before Sequoia, this caused the entire view to redraw, but in Sequoia, only the main view gets redrawn. All subviews remain as they were draw during pass 1. The fix was to explicitly call setNeedsDisplay for every subview as well. I see setNeedsDisplay is deprecated, but it seems to have changed now too. I still see subview cells drawing in reverse order compared to prior MacOS versions. Because I move cells to avoid overlap, it is not a problem in my window. It seems like that change would affect any application where subviews might overlap (and therefore drawing order would matter).

Embarrassingly, I found a solution. Instruments was indeed correct about a leak, but not much help it finding why. After looking at the same code for long time I found I had misspelled dealloc as delloc so it was never called (as the code suggested it should). After correcting the spelling, that leak (as several others too) went away. I suppose I should convert from non-ARC to ARC, but the thought if converting over 20 years of (legacy) coding, sounds like a lot of work. I might try when I retire next year.

I read through NSSavePanel, but I don't see any access to the default panel object that gets created by runModalSavePanelForSaveOperation to get the result? I just found that my problem was caused by a recent change to my code where I wanted to know when the default save panel was done (for scripting options). I did that by using the documented selector of document:didSave:contextinfo It works in Ventura. In Somoma the selector always gets called after panel is done (for delete, cancel, or save), but it seems to prevents standard actions from happen such as closing a deleted file or even closing a file that was saved after clicking a close box. If I removed calls to that selector all is working as expected. Seems I need a new way to hear when default panel is done? It is easy for saves, but how to hear if the panel save was cancelled?

In Big Sur when created tool bar item programmatically (from a view in Interface Builder), I get that warning when I use setMinSize and setMaxSize. The problem is that if I don't set them, Big Sur does not display them correctly in the customize tool bar sheet for the window (setting them fixes that but causing warnings). One "solution" above said to set "size" of Tool bar item to "Automatic", but I don't see a programmatic option to set "size" property of a NSToolBarItem?

No was has replied to your question and maybe you solved it yourself, but I am having the same problem and the problem continues in XCode 12.2 (on Mac with 10.15.7). The problem is intermittent. I have three separate XCode projects. Two of them respond as expected. The third one, which seems to have the identical build settings, however, refuses to do an arm64 build. It is set for "Standard Architectures", but that setting is ignored and it does only x86_64 (and build active architecture only is set to "No"). Also, I get no error message explaining why it refuses to do the build. Is there some other setting that could interfere with getting both builds? The one that fails is the oldest project, but I have updated the poject settings whenever recommended. If the build can't be done, it would be nice if XCode would explain why it was skipped?