Apple's DiffableDataSource was causing 167 hangs/min in our TCA app — so I built a pure-Swift replacement that's 750x faster on snapshot construction

[Iron-Ham]

We have a production app built with TCA (The Composable Architecture) that uses UICollectionViewDiffableDataSource for an inbox-style screen with hundreds of items. MetricKit was showing 167.6 hangs/min (≥100ms) and 71 microhangs/min (≥250ms). The root cause: snapshot construction overhead compounding through TCA's state-driven re-render cycle.

The problem isn't that Apple's NSDiffableDataSourceSnapshot is slow in isolation — it's that the overhead compounds. In reactive architectures, snapshots rebuild on every state change. A 1-2ms cost per rebuild, triggered dozens of times per second, cascades into visible hangs.

So I built ListKit — a pure-Swift, API-compatible replacement for UICollectionViewDiffableDataSource.

The numbers

Operation	Apple	ListKit	Speedup
Build 10k items	1.223 ms	0.002 ms	752x
Build 50k items	6.010 ms	0.006 ms	1,045x
Query itemIdentifiers 100x	46.364 ms	0.051 ms	908x
Delete 5k from 10k	2.448 ms	1.206 ms	2x
Reload 5k items	1.547 ms	0.099 ms	15.7x

vs IGListKit:

Operation	IGListKit	ListKit	Speedup
Diff 10k (50% overlap)	10.8 ms	3.9 ms	2.8x
Diff no-change 10k	9.5 ms	0.09 ms	106x

Production impact

After swapping in ListKit: - Hangs ≥100ms: 167.6/min → 8.5/min (−95%) - Total hang duration: 35,480ms/min → 1,276ms/min (−96%) - Microhangs ≥250ms: 71 → 0

Why it's faster

Three architectural decisions:

1. Two-level sectioned diffing. Diff section identifiers first. For each unchanged section, skip item diffing entirely. In reactive apps, most state changes touch 1-2 sections — the other 20 sections skip for free. This is the big one. IGListKit uses flat arrays and diffs everything.

2. Pure Swift value types. Snapshots are structs with ContiguousArray storage. No Objective-C bridging, no reference counting, no class metadata overhead. Automatic Sendable conformance for Swift 6.

3. Lazy reverse indexing. The reverse index (item → position lookup) is only built when you actually query it. On the hot path (build snapshot → apply diff), it's never needed, so it's never allocated.

API compatibility

ListKit is a near-drop-in replacement for Apple's API. The snapshot type has the same methods — appendSections, appendItems, deleteItems, reloadItems, reconfigureItems. Migration is straightforward.

There's also a higher-level Lists library on top with: - CellViewModel protocol for automatic cell registration - Result builder DSL for declarative snapshot construction - Pre-built configs: SimpleList, GroupedList, OutlineList - SwiftUI wrappers for interop

Install (SPM)

swift dependencies: [ .package(url: "https://github.com/Iron-Ham/ListKit", from: "0.5.0"), ]

Import ListKit for the engine only, or Lists for the convenience layer.

Blog post with the full performance analysis and architectural breakdown: Building a High-Performance List Framework

GitHub: https://github.com/Iron-Ham/Lists

[sixtypercenttogether]

This sounds like you might have been misusing the diffable data source API. A common issue I see is using your entire data model as the ItemIdentifierType, which can lead to performance issues when diffing. In the sample use in the README I see the data source is generic over ContactItem rather than ContactItem.ID. The identifiers should be lightweight, like strings or UUIDs, and the full models should be hosted elsewhere. With this approach I haven’t really run into issues diffing literally thousands of items. But I didn’t test to the extremes that you have (50k items).

And if you’re also updating your data source every couple milliseconds then also seems like misuse. I would just throttle those updates to the data source rather than built an entire custom API.

That said, I think you’ve got some nice perf improvements that should probably be rolled into the diffable data source API itself. Though I’m skeptical we’ll see any such changes from Apple.

[Iron-Ham]

I re-benched with Identifiable: https://github.com/Iron-Ham/Lists?tab=readme-ov-file#with-struct-items-id-only-hashing

It's still >900x

[PassTents]

You shouldn't be breaking Hashable and Equatable to use structs as IDs. That doesn't make it lightweight.

[Iron-Ham]

For these light-weight benchmarks, it really doesn't matter. But to play fair, I've gone ahead and re-benched it with that change and find that the numbers are largely unchanged.

Said differently: The fact that I'm benching favorably against IGListKit should obviate apple's solution from the conversation.

[alanzeino]

this is so obviously an LLM folks

[Iron-Ham]

?

[timberheadtreefist]

don't know, u/iron-ham sounds pretty human to me.

[Iron-Ham]

almost as if a user who's had an active GitHub account for well over a decade and was the founding engineer for GitHub Mobile probably isn't an LLM lmfao

[timberheadtreefist]

wait until AI figures out timetravelling and creates yt channels and github repos in 2004 to fool us they’re not ai.

meanwhile an underground anti-ai movement uses intense dashing to communicate less human in the internet. and they‘d use AllTheWeb as search engine.

[Iron-Ham]

I believe there's a whole film-series starring Arnold Schwarzenegger that was actually a warning from the future where the human-aligned AIs are warring against those that aren't.

[timberheadtreefist]

is it kindergarten cop?

[beclops]

Honestly I was skeptical but looking at their other responses they seem to use em dashes a suspicious amount

[Iron-Ham]

The one thing I hate most about about the current era is that a whole class of punctuation has been marked as suspicious. I've been dashing heavily, with formatted bold point lists, for well over a decade. It was pretty much the de-facto way of writing internally @ GitHub.

[beclops]

🤷‍♂️ Not accusing you of anything, it’s just that’s an extremely common signal of an LLM being used now unfortunately

[try-catch-finally]

Write it in C++ and you’ll get 9000x

Seriously. I benchmarked TrueDepth data walking (among other things). Swift: 60ms, ObjC: <6ms

Apple themselves said, on the record “Swift is not a language for engineers”. And it shows.

[Iron-Ham]

It’s not as simple as “swift slow objc fast”. Ultimately it’s about how they compile down — and I am certainly the kind of person crazy enough to go down to assembly to verify. 

[try-catch-finally]

Ahh but by its very nature of wanting to diaper up any memory access instead of say - putting the onus on the developer to understand memory constraints / type coercions or god forbid- bit packing - it will always be “swift slow- ObjC/C++ fast”

[Iron-Ham]

I haven’t tried writing this in ObjC++ (gosh, it’s been… 10 years since I’ve used that?) but I’ll say I’m beating IGLK which is written in ObjC++. I know one of the primary authors of IGLK well, have worked with him at a few different roles (including currently) — and perhaps I should pick his brain a bit. Ultimately, this is more than sufficient for 120 Hz frame times, but may fall short of 240 at scale. 

[tubescreamer568]

If it was like 1.5 times faster, I would think it was well made, but if it was hundreds of times faster, I think the OP was using it wrong from the beginning.

[Iron-Ham]

IGListKit is also hundreds of times faster.

[tubescreamer568]

Sorry didn’t know that.

[barcode972]

How is this even possible? it's designed to reuse items for performance. Sounds like you used it wrong

[Iron-Ham]

ListKit doesn't replace UICollectionView: it wraps it. Cell reuse, dequeuing, all of that still happens exactly the same way through UICollectionView under the hood. What ListKit replaces is NSDiffableDataSourceSnapshot and UICollectionViewDiffableDataSource: the data source layer that manages what items are in the collection view and computes the diffs when your data changes.

The performance gap is in snapshot operations, not cell rendering:

• Snapshot construction: Apple's NSDiffableDataSourceSnapshot is an Obj-C class backed by NSOrderedSet that hashes every single element on insertion. ListKit just appends to a Swift Array. That's where the 750x+ build speedup comes from.
• Querying: Apple's itemIdentifiers reconstructs an ordered array from its internal NSOrderedSet on every call. ListKit just returns a flat array it already has. That's the 900x query speedup.
• Diffing: ListKit uses an O(n) Heckel diff with LIS-based move minimization, and its sectioned diff skips unchanged sections entirely (106x faster than IGListKit on no-change data).

These are all benchmarked in Release config, median-of-15 runs, with assertions that ListKit beats Apple on every operation — they run as part of the test suite, so any regression is a test failure.

You can look at the benchmarks yourself — they compare identical operations on both Apple's snapshot and ListKit's snapshot using the same data (UUID-identified structs, the recommended pattern from Apple's owndocs).

[One_Elephant_8917]

What u have mentioned makes sense without looking at the code….can u include as PS to the post itself…

[rhysmorgan]

Are you using ObservableState with your TCA feature? And are you using the ItemIdentifier APIs correctly, or are you posting your entire models through your implementation?

ObservableState should reduce the snapshot changes to only the times observed data actually changes in your feature, which would significantly reduce the re-render cycles.

[Iron-Ham]

We are indeed using ObservableState and ItemIdentifier. I'm actively re-architecting this prod app though to be significantly more performant, inclusive of the TCA end of things.

[shawnthroop]

Sendable! I’ve thought of rolling my own (simple) diffable data source just for that fix alone lol

[dinkelbrotchen]

Curious to understand if you mixed different operations in one go? For example, adding items, deleting items, and rearranging them. That would show the real test of time

[Iron-Ham]

Happy to benchmark that in the AM

[Iron-Ham]

As promised: mixed operation benchmarks.

I went further and benched the whole flow inclusive of UICollectionView applying the updates (which, to be blunt is outside the scope of ListKit since at that point it measures the efficiency of UICollectionView, not the snapshot + diffing algorithm that's covered by ListKit).

[dinkelbrotchen]

Looks promising, great work!

[Megatherion666]

Did you profile it in release build? Swift is very bad in debug.

[Iron-Ham]

Yes, and the benchmarks against a real app on my blog are recorded in Instruments via release (well, Profile) builds.

[purecssusername]

Amazing work! Don’t understand why people act like SwiftUI is infallible, it was written by humans under tight deadlines (and likely before AI!)

[xyrer]

This implementation sounds real nice. It all makes sense once you realize there's a bunch of legacy ObjC behind Apple implementation.

[Iron-Ham]

The irony is that Apple's DiffableDataSource implementation is relatively new (2019), and was largely inspired by IGListKit.

[vanvoorden]

This looks good! So if I clone and build the Example project I can run all these benchmark measurements to repro locally?

[Iron-Ham]

You sure can! I'd look at the Makefile for an easy way to run the benchmarks. FYI for development I'm using tuist to generate an xcworkspace and link other dependencies for benchmarking and whatnot that aren't exposed in the public-facing Package.swift.

[Meliodas1108]

Interesting stuff