Here is more concrete context.
Platform / tools
Target: macOS app
Language / frameworks: Swift, SwiftUI, SwiftData
Cloud sync: SwiftData with CloudKit mirroring in the production configuration
Xcode: 26.4 (17E192)
Test OS: macOS 26.4 (25E246)
What I’m seeing
In the macOS app, issue board scrolling can become inconsistent or very slow.
Changing an issue status from detail view can be very slow.
Scrolling the status menu itself can be slow.
Typing in issue description/notes fields can become sluggish.
The problem is much more noticeable with my full production-sized dataset than with a small dev dataset.
What I’ve tested so far
I compared a small dev dataset vs a much larger production-sized dataset.
With a small dataset, the same UI feels fast and smooth.
With the large dataset, the same UI becomes noticeably slower.
I also tested a local-only copy of the production dataset with CloudKit disabled. That improved some behavior, but it did not remove the lag entirely.
When I reduced the local test dataset from ~1136 issues to ~500 issues, the app became much closer to the small dev build in responsiveness.
Why I think this is SwiftUI / SwiftData invalidation or scaling related
The current app structure has a few hot paths that seem important:
An issue board/list view derives filtered/grouped board sections from a live full-issues query.
The board and list are backed by the full issue dataset.
Grouping, filtering, sorting, and section building are derived repeatedly from that live array.
With a large dataset, small mutations like a status change appear to trigger broad recomputation.
The issue detail view also depends on broader issue/project/milestone data than it really needs.
A local edit to one issue appears to invalidate more of the issue graph than expected.
This is especially visible when changing status or typing in notes.
Project views compute issue-derived counts/statistics from the full issues set.
Project rows/details derive counts from issue data.
With a large issue dataset, this contributes to lag.
On macOS, board scrolling uses competing scroll behavior.
There is horizontal scrolling for the board and vertical scrolling inside columns.
On macOS this can make scrolling feel inconsistent when the view is already under load.
Data sizes
Full dataset: about 1136 issues
Reduced test dataset: about 500 issues
Small dev dataset: about 97 issues
What seems important
Disabling CloudKit alone did not fully fix the issue.
Reducing the dataset size did make a large difference.
That makes me suspect the main problem is broad SwiftUI/SwiftData invalidation and repeated derived work against large live query results, with CloudKit only amplifying it in production.
What I’d like to understand
Are there recommended SwiftUI / SwiftData patterns for large macOS datasets where board/list/detail views all depend on shared live query results?
Are there known macOS-specific performance pitfalls with nested scroll views plus large SwiftData-backed SwiftUI views?
Is there recommended guidance for reducing invalidation fanout when one model mutation should not cause broad recomputation across the whole dataset?
Topic:
App & System Services
SubTopic:
iCloud & Data
Tags: