Did some profiling of my real app instead of this contrived example, and while these modifiers are a factor, there's something else related to my chart slowing down the navigation transition. Digging into TimeProfiler shows AttributeGraph being the slowest. Will followup if I figure out what the problem is.

I'm seeing similarly on Beta 4, though I didn't seem to see this on the earlier betas. Same scenario as the folks above though with regard to using nested NavigationLinks within a NavigationStack and also Core Data. Seems to be doing what the warning says and calling that destination over and over, until the app freezes.

I'm working with a slightly different architecture now, and I'm still seeing performance problems. In summary, I have: A NavigationStack A list 7 charts in that list Each chart has a variable amount of data points, but on average about 2000. If I tap a navigation destination, the app hangs for 1-2s. I've noticed a correlation, where if I whittle down my data points on each chart, the app hang shortens as well. Even down to less than 100 data points, my hang is more than 0.5s, so there's still clearly something wrong or inefficient going on. Still not confident if it's my code that's inefficient or if there's a problem with Charts or NavigationStack, but I figured I'd journal my latest findings. Edit: Actually after both reducing samples, and removing my chart modifiers, my hang is almost not noticeable. So I think it's a combination of both samples + the modifiers I'm using on the charts. So somewhere with that is the problem....but why does it slow down navigation so much?