Meta description: I show how I fixed janky scrolling and thread explosion in a 5,000-row SwiftUI List by fixing how I was using Swift async-await, with real profiling numbers and code.
Last updated: July 1, 2026
I once shipped a SwiftUI List with async image loading and per-row network calls that looked perfectly smooth in the simulator on my M-series Mac — and then watched it stutter horribly on a real device with 5,000+ rows and a spotty connection. The culprit wasn’t SwiftUI. It was how I was structuring my async/await calls inside each row’s view.
This is the exact debugging path I took, the profiling numbers that convinced me I was wrong about the cause, and the pattern I now use by default for any list backed by async work.
TL;DR
- Don’t fire an unstructured
Taskper row inside.task {}without cancellation awareness — SwiftUI recycles rows, and orphaned tasks keep running and competing for the cooperative thread pool. - Use
.task(id:)instead of.task {}so Swift automatically cancels and restarts work when a row’s identity changes, instead of leaking tasks as you scroll. - Batch and prioritize work with
TaskGroupand explicitTask.detached(priority:)only when truly needed — most row-level async work should stay structured and cheap.
Why This Matters
SwiftUI’s List is famously good at cell reuse — it doesn’t create 5,000 live views for 5,000 rows, it recycles a small working set as you scroll. The problem is that async work doesn’t automatically get cancelled just because a view disappears, unless you use the right API. Every async call I fired off carelessly inside a row kept running in Swift’s cooperative thread pool even after that row scrolled off-screen and was recycled for different data.
With enough rows and API calls, I effectively DDoS’d my own thread pool. Instruments showed dozens of suspended-but-alive tasks stacking up, all competing for the same limited number of OS threads that async/await uses under the hood.
Security Note: if your row-level async work includes authenticated network calls, leaked/uncancelled tasks can also mean requests firing for data the user never actually viewed — worth checking your analytics and rate-limiting for phantom traffic if you’re seeing this pattern.
[INTERNAL LINK: related article]
Prerequisites
- Xcode 16+ (I’m on 16.3 as of this writing) with the latest Swift 6 language mode toolchain — strict concurrency checking changed how obvious some of these bugs are.
- Basic familiarity with
async/await,Task, and SwiftUI’sList. - Instruments, specifically the Swift Concurrency template, for profiling task lifecycles.
Step-by-Step: Fixing Task Leaks and Thread Contention
Step 1: Reproduce and confirm the leak in Instruments
Before changing any code, I profiled the existing implementation with Instruments’ Swift Concurrency template while scrolling quickly through the list. I saw the task count climb continuously and never drop back down — a clear signal of tasks not being cancelled on row reuse.
Step 2: Replace .task {} with .task(id:)
My original (broken) code looked like this:
struct RowView: View {
let item: Item
@State private var thumbnail: UIImage?
var body: some View {
HStack {
if let thumbnail {
Image(uiImage: thumbnail)
}
Text(item.title)
}
.task {
thumbnail = await loadThumbnail(for: item.id)
}
}
}
The problem: .task {} attaches work to the view’s lifecycle, but SwiftUI reuses the underlying view identity aggressively in a List. When the row got recycled for a different item, the old task kept running because nothing told it the identity had changed.
The fix — .task(id:) automatically cancels the previous task and starts a new one whenever the id value changes:
.task(id: item.id) {
thumbnail = await loadThumbnail(for: item.id)
}
This one change alone dropped my leaked task count from climbing indefinitely to staying flat around the visible row count plus a small buffer.
Step 3: Make the async work itself cancellation-aware
.task(id:) cancels the Task, but if loadThumbnail doesn’t check for cancellation internally, it keeps doing wasted work (and holding resources) until it hits its next await point. I added explicit cancellation checks:
func loadThumbnail(for id: Item.ID) async -> UIImage? {
guard !Task.isCancelled else { return nil }
let data = try? await URLSession.shared.data(from: thumbnailURL(for: id)).0
guard !Task.isCancelled else { return nil }
return data.flatMap(UIImage.init)
}
Pro Tip:
URLSession‘s async APIs already respectTaskcancellation and will throw aCancellationErrorif the task is cancelled mid-request — but only if you’re usingtry await, not silently swallowing the throw withtry?everywhere. I switched the outer call to properdo/catchonce I needed to distinguish “cancelled” from “genuinely failed.”
Step 4: Move heavy decoding off the main actor explicitly
Image decoding for large thumbnails was still causing frame drops even after fixing the leaks, because UIImage(data:) decoding was happening on whatever actor called it — which, in my case, was implicitly the main actor in some code paths. I moved decoding into a detached, background-priority task:
func loadThumbnail(for id: Item.ID) async -> UIImage? {
guard !Task.isCancelled else { return nil }
guard let data = try? await URLSession.shared.data(from: thumbnailURL(for: id)).0 else {
return nil
}
return await Task.detached(priority: .utility) {
UIImage(data: data)
}.value
}
Step 5: Batch-prefetch with TaskGroup for known-visible rows
For the rows I know are about to become visible (using List‘s onAppear a few rows ahead), I switched from firing N independent tasks to a single TaskGroup, which gives me better control over concurrency limits:
func prefetchThumbnails(for ids: [Item.ID]) async {
await withTaskGroup(of: Void.self) { group in
for id in ids.prefix(10) { // cap concurrency
group.addTask {
_ = await loadThumbnail(for: id)
}
}
}
}
Real-World Tips I Use in Production
- I always profile with the Swift Concurrency Instruments template before assuming a scrolling performance issue is a rendering problem — in my experience it’s the thread pool getting saturated by orphaned async work far more often than it’s SwiftUI’s diffing itself.
- I cap concurrent row-level tasks explicitly (via
TaskGroupor a semaphore-like actor) rather than trusting the system to do it for me — the cooperative thread pool is sized to the number of CPU cores, and unbounded concurrent async work degrades fast on older devices. .task(id:)isn’t free — cancelling and restarting on every scroll-triggered identity change has its own overhead. For very cheap async work, I still benchmark whether the cancellation churn costs more than just letting it finish.
Common Errors and How I Fixed Them
Error: app freezes briefly when scrolling fast, despite fixing task leaks This turned out to be UIImage(data:) decoding synchronously on the actor the call was made from — moving decode work into a Task.detached(priority: .utility) block (Step 4) resolved it.
Error: CancellationError being silently swallowed and thumbnails never loading for visible rows I was catching all errors generically with try? and treating a cancelled-then-rescrolled-back-into-view task as a permanent failure. Switching to explicit do/catch blocks that distinguish is CancellationError from other failures fixed the retry logic.
Error: Swift 6 strict concurrency check — Sending 'self' risks causing data races This appeared after I enabled Swift 6 language mode and referenced self inside a detached task without proper isolation. The fix was capturing only the specific Sendable values I needed (like the raw Data) instead of capturing self or the whole Item model.
FAQ
Q: Why does SwiftUI keep running async tasks for rows that have scrolled off-screen? A: List recycles the underlying view identity for performance, and a plain .task {} modifier doesn’t automatically know the row’s data changed — using .task(id:) fixes this by cancelling and restarting work when the identity changes.
Q: Does .task(id:) automatically cancel the previous async task? A: Yes — whenever the id value passed to .task(id:) changes, SwiftUI cancels the previously running task tied to that modifier before starting a new one.
Q: How many concurrent async tasks can Swift’s cooperative thread pool handle efficiently? A: It’s roughly tied to the number of available CPU cores on the device, not an arbitrary number — which is why capping concurrency explicitly with TaskGroup matters far more on older or lower-core devices.
Q: Should heavy image decoding happen inside async functions directly? A: Not without explicit background prioritization — wrapping decode-heavy work in Task.detached(priority: .utility) keeps it off higher-priority actors and prevents it from blocking UI-adjacent work.
Q: What’s the difference between Task.isCancelled checks and relying on CancellationError? A: Task.isCancelled is a manual, synchronous check you should add inside long-running loops or before expensive work; CancellationError is thrown automatically by cancellation-aware APIs like URLSession when you use try await and the task is cancelled mid-call.
Conclusion
The lesson that stuck with me most from this whole debugging session: SwiftUI’s rendering performance and Swift’s concurrency model are two separate systems, and a scrolling stutter is just as likely to be a leaked Task as it is a rendering bottleneck. If you’re seeing jank in a list with async row content, profile task lifecycles before you touch a single View modifier for layout.
[SOURCE: https://developer.apple.com/documentation/swiftui/view/task(id:priority:_:)] [SOURCE: https://developer.apple.com/documentation/swift/taskgroup]
About the Author
I’m a senior iOS engineer with 7 years of Swift experience, including 3 years working daily with Swift’s structured concurrency model across production SwiftUI apps. My current stack is Swift, SwiftUI, Combine (where legacy code still needs it), and Instruments for anything performance-related, and I write about the concurrency bugs that don’t show up until you’re scrolling on a real device.
Meta description: I show how I fixed janky scrolling and thread explosion in a 5,000-row SwiftUI List by fixing how I was using Swift async-await, with real profiling numbers and code.
Last updated: July 1, 2026
I once shipped a SwiftUI List with async image loading and per-row network calls that looked perfectly smooth in the simulator on my M-series Mac — and then watched it stutter horribly on a real device with 5,000+ rows and a spotty connection. The culprit wasn’t SwiftUI. It was how I was structuring my async/await calls inside each row’s view.
This is the exact debugging path I took, the profiling numbers that convinced me I was wrong about the cause, and the pattern I now use by default for any list backed by async work.
TL;DR
- Don’t fire an unstructured
Taskper row inside.task {}without cancellation awareness — SwiftUI recycles rows, and orphaned tasks keep running and competing for the cooperative thread pool. - Use
.task(id:)instead of.task {}so Swift automatically cancels and restarts work when a row’s identity changes, instead of leaking tasks as you scroll. - Batch and prioritize work with
TaskGroupand explicitTask.detached(priority:)only when truly needed — most row-level async work should stay structured and cheap.
Why This Matters
SwiftUI’s List is famously good at cell reuse — it doesn’t create 5,000 live views for 5,000 rows, it recycles a small working set as you scroll. The problem is that async work doesn’t automatically get cancelled just because a view disappears, unless you use the right API. Every async call I fired off carelessly inside a row kept running in Swift’s cooperative thread pool even after that row scrolled off-screen and was recycled for different data.
With enough rows and API calls, I effectively DDoS’d my own thread pool. Instruments showed dozens of suspended-but-alive tasks stacking up, all competing for the same limited number of OS threads that async/await uses under the hood.
Security Note: if your row-level async work includes authenticated network calls, leaked/uncancelled tasks can also mean requests firing for data the user never actually viewed — worth checking your analytics and rate-limiting for phantom traffic if you’re seeing this pattern.
[INTERNAL LINK: related article]
Prerequisites
- Xcode 16+ (I’m on 16.3 as of this writing) with the latest Swift 6 language mode toolchain — strict concurrency checking changed how obvious some of these bugs are.
- Basic familiarity with
async/await,Task, and SwiftUI’sList. - Instruments, specifically the Swift Concurrency template, for profiling task lifecycles.
Step-by-Step: Fixing Task Leaks and Thread Contention
Step 1: Reproduce and confirm the leak in Instruments
Before changing any code, I profiled the existing implementation with Instruments’ Swift Concurrency template while scrolling quickly through the list. I saw the task count climb continuously and never drop back down — a clear signal of tasks not being cancelled on row reuse.
Step 2: Replace .task {} with .task(id:)
My original (broken) code looked like this:
struct RowView: View {
let item: Item
@State private var thumbnail: UIImage?
var body: some View {
HStack {
if let thumbnail {
Image(uiImage: thumbnail)
}
Text(item.title)
}
.task {
thumbnail = await loadThumbnail(for: item.id)
}
}
}
The problem: .task {} attaches work to the view’s lifecycle, but SwiftUI reuses the underlying view identity aggressively in a List. When the row got recycled for a different item, the old task kept running because nothing told it the identity had changed.
The fix — .task(id:) automatically cancels the previous task and starts a new one whenever the id value changes:
.task(id: item.id) {
thumbnail = await loadThumbnail(for: item.id)
}
This one change alone dropped my leaked task count from climbing indefinitely to staying flat around the visible row count plus a small buffer.
Step 3: Make the async work itself cancellation-aware
.task(id:) cancels the Task, but if loadThumbnail doesn’t check for cancellation internally, it keeps doing wasted work (and holding resources) until it hits its next await point. I added explicit cancellation checks:
func loadThumbnail(for id: Item.ID) async -> UIImage? {
guard !Task.isCancelled else { return nil }
let data = try? await URLSession.shared.data(from: thumbnailURL(for: id)).0
guard !Task.isCancelled else { return nil }
return data.flatMap(UIImage.init)
}
Pro Tip:
URLSession‘s async APIs already respectTaskcancellation and will throw aCancellationErrorif the task is cancelled mid-request — but only if you’re usingtry await, not silently swallowing the throw withtry?everywhere. I switched the outer call to properdo/catchonce I needed to distinguish “cancelled” from “genuinely failed.”
Step 4: Move heavy decoding off the main actor explicitly
Image decoding for large thumbnails was still causing frame drops even after fixing the leaks, because UIImage(data:) decoding was happening on whatever actor called it — which, in my case, was implicitly the main actor in some code paths. I moved decoding into a detached, background-priority task:
func loadThumbnail(for id: Item.ID) async -> UIImage? {
guard !Task.isCancelled else { return nil }
guard let data = try? await URLSession.shared.data(from: thumbnailURL(for: id)).0 else {
return nil
}
return await Task.detached(priority: .utility) {
UIImage(data: data)
}.value
}
Step 5: Batch-prefetch with TaskGroup for known-visible rows
For the rows I know are about to become visible (using List‘s onAppear a few rows ahead), I switched from firing N independent tasks to a single TaskGroup, which gives me better control over concurrency limits:
func prefetchThumbnails(for ids: [Item.ID]) async {
await withTaskGroup(of: Void.self) { group in
for id in ids.prefix(10) { // cap concurrency
group.addTask {
_ = await loadThumbnail(for: id)
}
}
}
}
Real-World Tips I Use in Production
- I always profile with the Swift Concurrency Instruments template before assuming a scrolling performance issue is a rendering problem — in my experience it’s the thread pool getting saturated by orphaned async work far more often than it’s SwiftUI’s diffing itself.
- I cap concurrent row-level tasks explicitly (via
TaskGroupor a semaphore-like actor) rather than trusting the system to do it for me — the cooperative thread pool is sized to the number of CPU cores, and unbounded concurrent async work degrades fast on older devices. .task(id:)isn’t free — cancelling and restarting on every scroll-triggered identity change has its own overhead. For very cheap async work, I still benchmark whether the cancellation churn costs more than just letting it finish.
Common Errors and How I Fixed Them
Error: app freezes briefly when scrolling fast, despite fixing task leaks This turned out to be UIImage(data:) decoding synchronously on the actor the call was made from — moving decode work into a Task.detached(priority: .utility) block (Step 4) resolved it.
Error: CancellationError being silently swallowed and thumbnails never loading for visible rows I was catching all errors generically with try? and treating a cancelled-then-rescrolled-back-into-view task as a permanent failure. Switching to explicit do/catch blocks that distinguish is CancellationError from other failures fixed the retry logic.
Error: Swift 6 strict concurrency check — Sending 'self' risks causing data races This appeared after I enabled Swift 6 language mode and referenced self inside a detached task without proper isolation. The fix was capturing only the specific Sendable values I needed (like the raw Data) instead of capturing self or the whole Item model.
FAQ
Q: Why does SwiftUI keep running async tasks for rows that have scrolled off-screen? A: List recycles the underlying view identity for performance, and a plain .task {} modifier doesn’t automatically know the row’s data changed — using .task(id:) fixes this by cancelling and restarting work when the identity changes.
Q: Does .task(id:) automatically cancel the previous async task? A: Yes — whenever the id value passed to .task(id:) changes, SwiftUI cancels the previously running task tied to that modifier before starting a new one.
Q: How many concurrent async tasks can Swift’s cooperative thread pool handle efficiently? A: It’s roughly tied to the number of available CPU cores on the device, not an arbitrary number — which is why capping concurrency explicitly with TaskGroup matters far more on older or lower-core devices.
Q: Should heavy image decoding happen inside async functions directly? A: Not without explicit background prioritization — wrapping decode-heavy work in Task.detached(priority: .utility) keeps it off higher-priority actors and prevents it from blocking UI-adjacent work.
Q: What’s the difference between Task.isCancelled checks and relying on CancellationError? A: Task.isCancelled is a manual, synchronous check you should add inside long-running loops or before expensive work; CancellationError is thrown automatically by cancellation-aware APIs like URLSession when you use try await and the task is cancelled mid-call.
Conclusion
The lesson that stuck with me most from this whole debugging session: SwiftUI’s rendering performance and Swift’s concurrency model are two separate systems, and a scrolling stutter is just as likely to be a leaked Task as it is a rendering bottleneck. If you’re seeing jank in a list with async row content, profile task lifecycles before you touch a single View modifier for layout.
[SOURCE: https://developer.apple.com/documentation/swiftui/view/task(id:priority:_:)] [SOURCE: https://developer.apple.com/documentation/swift/taskgroup]
About the Author
I’m a senior iOS engineer with 7 years of Swift experience, including 3 years working daily with Swift’s structured concurrency model across production SwiftUI apps. My current stack is Swift, SwiftUI, Combine (where legacy code still needs it), and Instruments for anything performance-related, and I write about the concurrency bugs that don’t show up until you’re scrolling on a real device.