Layout recursion error message

Question

-dp OP

Created 1d

Replies 3

Boosts 0

Participants 2

Hi all,

when I launch my macOS app from Xcode 16 on ARM64, appKit logs me this error on the debug console:

It's not legal to call -layoutSubtreeIfNeeded on a view which is already being laid out. If you are implementing the view's -layout method, you can call -[super layout] instead. Break on _NSDetectedLayoutRecursion(void) to debug. This will be logged only once. This may break in the future.

_NSDetectedLayoutRecursion doesn't help a lot, giving me these assembly codes from a call to a subclassed window method that looks like this:

-(void) setFrame:(NSRect)frameRect display:(BOOL)flag {
    if (!_frameLocked) [super setFrame:frameRect display:flag];
}

I have no direct call to -layoutSubtreeIfNeeded from a -layout implementation in my codes. I have a few calls to this method from update methods, however even if I comment all of them, the error is still logged...

Finally, apart from that log, I cannot observe any layout error when running the program. So I wonder if this error can be safely ignored?

Thanks!

Boost

Answer 1

Etresoft OP

1d

There's no easy answer here. I wouldn't necessarily ignore the error. There may be one or more UI interactions that you simply haven't tried yet.

For example, I recently discovered that if I minimized a window and then restore it, I would get some auto layout errors. I fixed those. But the point is that the window/view controller/view/layout architecture is extremely complicated.

These kinds of errors may indicate that you're doing something in the wrong sequence, or doing something else that's invalid in some way. You're running on Xcode 16. It might not work on Xcode 26 or macOS 26. Or maybe macOS 26.1 or 26.2 breaks it.

Are you subclassing NSWindow? That is the kind of thing that will get you into trouble. Apple's APIs aren't like Perl. There isn't "more than one way to do it". Rather, on average, there's about 0.92 ways to do it.

0

Answer 2

-dp OP

1d

Thanks for your answer. Yes I'm subclassing NSWindow: the method -setFrame:display: reproduced above is one of the NSWindow methods specialized by this subclass. But, apart of that, the subclass doesn't interfere with the layout system in no way.

You're right about new macOS versions, I definitely intend to test macOS 26 before publishing a new version of the app (I'm developing on Xcode16 because my deployment target is macOS 10.13).

0

Answer 3

Etresoft OP

1d

But it does interfere. It blocks the operation if _frameLocked == true. I understand this seems pretty simple, but there's no way to know what the impacts of that might be. There are many different setFrame variants. I'm not implying that this is a problem, or in any way related to the message you're asking about. It's just example of the risks of interfering in a really fragile architecture.

There are just so many possible causes, it's not reasonable to try to guess. The more you do with Auto Layout, the greater the risk of this kind of message.

If you have specific requirement to deploy to 10.13, that's fine. But macOS 13 is really the oldest reasonable deployment target for most apps.

0