Post

Replies

Boosts

Views

Activity

Reply to Production Mac app becomes progressively unusable in Issues workspace; Mac_Dev remains fast
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?
Apr ’26
Reply to Camera layout within a sheet in iOS26
Here's the relevant code: @State private var selectedItem: PhotosPickerItem? @State private var selectedPhoto: Data? @State private var isShowingPhotoSourceDialog = false @State private var isShowingPhotoLibraryPicker = false @State private var isShowingCameraCapture = false @State private var isShowingCameraUnavailableAlert = false // Photo Button Button { isShowingPhotoSourceDialog = true } label: { Label( selectedPhoto == nil ? "Add Photo" : "Change Photo", systemImage: "photo" ) .foregroundColor(.white) .padding() } .frame(maxWidth: .infinity) .background(Color.accent) .listRowInsets(EdgeInsets()) .confirmationDialog("Add Photo", isPresented: $isShowingPhotoSourceDialog, titleVisibility: .visible) { Button("Take Photo", systemImage: "camera") { if UIImagePickerController.isSourceTypeAvailable(.camera) { isShowingCameraCapture = true } else { isShowingCameraUnavailableAlert = true } } Button("Choose from Library", systemImage: "photo.on.rectangle") { isShowingPhotoLibraryPicker = true } Button("Cancel", role: .cancel) { } } .photosPicker(isPresented: $isShowingPhotoLibraryPicker, selection: $selectedItem, matching: .images) .onChange(of: selectedItem) { Task { if let data = try? await selectedItem?.loadTransferable(type: Data.self), let image = UIImage(data: data) { selectedPhoto = image.jpegData(compressionQuality: 0.5) } } } .sheet(isPresented: $isShowingCameraCapture) { CameraCaptureView { image in selectedPhoto = image.jpegData(compressionQuality: 0.5) } } .alert("Camera Unavailable", isPresented: $isShowingCameraUnavailableAlert) { Button("OK", role: .cancel) { } } message: { Text("This device does not have an available camera.") }
Feb ’26
Reply to List View within a Scrollview
That worked! Not sure what I was doing wrong. List { VStack (alignment: .leading, spacing: 24) { HeaderView() Picker("Filter", selection: $selectedFilter) { Text("One").tag("One") Text("Two").tag("Two") } .pickerStyle(.segmented) } .listRowSeparator(.hidden) if selectedFilter == "One" { ForEach(0..<10) { index in NavigationLink(destination: DetailView()) { RowView() } } } } .listStyle(.plain)
Topic: Design SubTopic: General Tags:
Jul ’25
Reply to Production Mac app becomes progressively unusable in Issues workspace; Mac_Dev remains fast
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?
Replies
Boosts
Views
Activity
Apr ’26
Reply to Camera layout within a sheet in iOS26
Here's the relevant code: @State private var selectedItem: PhotosPickerItem? @State private var selectedPhoto: Data? @State private var isShowingPhotoSourceDialog = false @State private var isShowingPhotoLibraryPicker = false @State private var isShowingCameraCapture = false @State private var isShowingCameraUnavailableAlert = false // Photo Button Button { isShowingPhotoSourceDialog = true } label: { Label( selectedPhoto == nil ? "Add Photo" : "Change Photo", systemImage: "photo" ) .foregroundColor(.white) .padding() } .frame(maxWidth: .infinity) .background(Color.accent) .listRowInsets(EdgeInsets()) .confirmationDialog("Add Photo", isPresented: $isShowingPhotoSourceDialog, titleVisibility: .visible) { Button("Take Photo", systemImage: "camera") { if UIImagePickerController.isSourceTypeAvailable(.camera) { isShowingCameraCapture = true } else { isShowingCameraUnavailableAlert = true } } Button("Choose from Library", systemImage: "photo.on.rectangle") { isShowingPhotoLibraryPicker = true } Button("Cancel", role: .cancel) { } } .photosPicker(isPresented: $isShowingPhotoLibraryPicker, selection: $selectedItem, matching: .images) .onChange(of: selectedItem) { Task { if let data = try? await selectedItem?.loadTransferable(type: Data.self), let image = UIImage(data: data) { selectedPhoto = image.jpegData(compressionQuality: 0.5) } } } .sheet(isPresented: $isShowingCameraCapture) { CameraCaptureView { image in selectedPhoto = image.jpegData(compressionQuality: 0.5) } } .alert("Camera Unavailable", isPresented: $isShowingCameraUnavailableAlert) { Button("OK", role: .cancel) { } } message: { Text("This device does not have an available camera.") }
Replies
Boosts
Views
Activity
Feb ’26
Reply to List View within a Scrollview
That worked! Not sure what I was doing wrong. List { VStack (alignment: .leading, spacing: 24) { HeaderView() Picker("Filter", selection: $selectedFilter) { Text("One").tag("One") Text("Two").tag("Two") } .pickerStyle(.segmented) } .listRowSeparator(.hidden) if selectedFilter == "One" { ForEach(0..<10) { index in NavigationLink(destination: DetailView()) { RowView() } } } } .listStyle(.plain)
Topic: Design SubTopic: General Tags:
Replies
Boosts
Views
Activity
Jul ’25