swiftui list drops to 41 fps with 2,000 rows and asyncimage on an iphone 12 performance

Once images are handled, the next tier of things that cost frames in a List row:

• AnyView anywhere in the row. It erases the type, so the diffing machinery cannot tell that the structure is unchanged and re-evaluates more than it needs to.
• Formatters constructed in body. A DateFormatter created per row per redraw is genuinely expensive - hoist it to a static.
• Deeply chained modifiers, particularly stacked .frame, .padding and .background combinations that each add a layout pass.
• Any computed property on your model that does real work and is read in body.

Measure with the SwiftUI template in Instruments rather than guessing. The "View Body" track shows you which view's body is slow and how often it runs, and "Long View Body Updates" points at the specific offender. It is a much better use of an hour than shotgunning modifiers.

60x60 on screen is not 60x60 in memory. That is the whole problem.

AsyncImage does no caching beyond the URL loading system's default behaviour, which means as rows recycle it re-requests, re-decodes and re-downsamples the same images repeatedly. A 1200x1200 JPEG decoded to a bitmap is somewhere around 5.7MB of memory regardless of the frame you draw it in, and the decode itself is the expensive part - it happens on a scroll frame, and it blows your budget.

What to do:

• Downsample at decode time, not with .resizable(). Use ImageIO with kCGImageSourceThumbnailMaxPixelSize set to your display size in pixels, and kCGImageSourceCreateThumbnailFromImageAlways. You get a small bitmap out and never materialise the full one.
• Cache the decoded result, keyed by url plus target size, in an NSCache. The second appearance of a row should be a dictionary lookup.
• Do it off the main thread and hand the finished image back.

Either adopt a library that does all three or write about 60 lines. Both are fine. What is not fine is AsyncImage in a long scrolling list - it is a convenience for a detail screen, not a feed component.

2,000 rows is not your problem. 2,000 full-size decodes is.

Good instinct moving to List. Worth knowing why it helped, because it tells you when to use which.

List is backed by a real reusing collection view. Cells are recycled and views for offscreen rows are torn down. LazyVStack in a ScrollView is lazy about creation but does not recycle - everything you have scrolled past is still there. On a 2,000 row feed that difference is memory that keeps growing and a scroll that gets worse the longer you use it.

Rule of thumb: long or unbounded, use List. Short and heterogeneous where you want full control of the layout, LazyVStack is fine.

Long lists with images are the case where SwiftUI still is not there. Wrap a UICollectionView with UIViewRepresentable and you get proper prefetching and cell reuse. Fighting the framework on this costs more time than the bridge does.

Also check whether your row is doing any work in onAppear. It is easy to put a "mark as seen" network call or an analytics event there and then fire 2,000 of them during a fling. Debounce anything in onAppear on a list row, or move it to a visibility threshold.

Every performance thread eventually arrives at "you are decoding a photo of a mountain to draw a thumbnail the size of a postage stamp".