Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: Performance regressions in SwiftUI apps on macOS Sequoia
11 points by nhubbard 48 days ago | hide | past | favorite | 3 comments
Hello all! I'm a macOS and iPadOS developer-in-training. I've written a sorting visualization app and published it to the App Store a while back [0]. It was an excellent trial-by-fire to help me learn Swift and SwiftUI.

It runs quite well on macOS Sonoma, and when macOS Sequoia came out, I started testing it with the new Xcode 16 beta. Unfortunately, there seems to have been some underlying changes to SwiftUI performance -- which are for the better -- but they are causing my app to lag fiercely.

I've run almost 50 different Instruments traces looking for issues between Sonoma and Sequoia, but nothing stands out to me. There's no unexplained spikes in GPU use, no unusual CPU behavior, and no noticeable flame graph changes that I could discern.

I've filed two separate bugs on Feedback Assistant (first FB14025421, then FB14562780), but neither bug has received any response from Apple engineers. I've posted on the Swift forums, but my post was (in retrospect, rightfully) marked private because it involves an Apple-owned framework [1]. I've posted on the Apple Developer forums, but received no response there [2]. I even signed up for office hours on the Apple developer portal, but my appointment was declined by Apple.

I included all of the traces I created, videos demonstrating the issue on Sequoia and the expected behavior on Sonoma, and a reproducer project in both of the bugs I've filed. I'm honestly at a loss, because I can't find any documentation or mention of changes that could be causing these issues.

So, I'm making this post as a "hail mary". If you're an Apple engineer that works with the SwiftUI or Mac Catalyst teams, or are experiencing a similar performance degradation with your app, please reach out. I'm grateful for any form of assistance that anyone can provide. Thank you in advance!

[0] https://apps.apple.com/us/app/sort-symphony/id6477886990

[1] Notably, one of the moderators said that it was an excellent question about a genuine concern, but that I should have posted on the Apple Developer forums since it was a private framework owned by Apple.

[2] https://developer.apple.com/forums/thread/758904




Good move, SwiftUI and MacOS performance can't tolerate any more performance degradation. The Settings app for example opens a separate process for each tab and keeps it around until you quit Settings; I'm not sure if this is why it's so slow, but it is like wading through ketchup. If you click on the first item below your profile photo and then press the down arrow to the bottom, it will open a new process for all of them.

In my experience building a similar app that I haven't launched, NavigationSplitView ended up causing a few hitches when switching or recycling views, it was distracting enough that I kind of lost momentum on it for now.

It's a bit frustrating that it's such a black box and we have to wait a full year for announcements and updates, nothing happens in the open and we're entirely dependent on their feedback system.


Update: Apple got back to me! It turns out that my code had a silent bug: my conformance to the Equatable protocol wasn't considering the current color of the rectangles drawn on screen, and one of the performance improvements in macOS Sequoia/iPadOS 18 is that ForEach elements don't re-draw if they aren't changed.


As part of your yearly developer membership fee, Apple offer 3 incidents of code level support. This sounds like an appropriate situation where you'd want to use the service.

https://developer.apple.com/support/technical/




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: