I was facing the same issue with very poor performance and narrowed the issue down to the XAxis. After implementing windowing for displaying data to reduce the amount being drawn in the chart, I also applied the same technique to AxisMarks to get acceptable performance. I basically observe the scroll position and provide the data and marks in an area around that position, while keeping chartXScale and chartXVisibleDomain constant.

I found myself asking exactly the same questions, about how the layout process works with UILabel and how I could use this for my own views. Ultimately I didn't get further than OP, other than figuring out that UILabel.preferredMaxLayoutWidth has been set before the second call to intrinsicContentSize. Since this is a property of UILabel this all leads me to believe, whatever is happening here is internal behavior we can't make use of. It's also very strange that calls to systemLayoutSizeFitting do not cascade down the view hierarchy. Therefore you don't get any chance to provide size information other than intrinsicContentSize which, as stated earlier, should not depend of the views frame. Not to mention that AutoLayout doesn't make use of this method at all. The solution for me seems to go back to frame based layout...

There's also a setting in Xcode 16: Editor > Canvas > Use Legacy Previews Execution This allowed me to use iOS 18 simulators for previews.

Facing the same problem. For us it seems to be related to the Project setup using Kotlin Multiplatform. Just downloading the example project from https://kmp.jetbrains.com/#newProject using native SwiftUI causes the same error. Maybe this has something to do with dynamic frameworks?