Production Mac app becomes progressively unusable in Issues workspace; Mac_Dev remains fast

For folks to help, you might consider providing more code-level context about the issue, for example, what Apple APIs you use and how you use them, how you trigger the issue, and what error message you get. See tips on writing forums posts, if necessary.

Best,
——
Ziqiao Chen
 Worldwide Developer Relations.

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:

1. 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.

1. 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.

1. 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.

1. 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?