They appear to be launching each settings screen as a separate app and retaining it until Settings is quit. How many resources this requires, or how much this contributes to the lag, I don't know, but...
Open Activity Monitor, and type in System Settings into the search. Then open the Settings app and press the down arrow key through all of the menus. You'll notice that each one of them appears as their own line item in Activity Monitor until you quit Settings, and if you keep going up and down through the menus, it'll (probably) get slower and slower; it seems like there's a memory leak or something going on there, and my hunch is that each old settings menu was thinly wrapped in a SwiftUI view and gets launched as soon as you click its nav item.
SwiftUI is not swift. It's about framework not language. But even that doesn't matter
I think Apple has decent QA for low level stuff (remember how they quietly converted every iphone to APFS and back just to test that it will work later) but bad QA for final GUI.
Most of cocoa/objc stuff was written long ago and back when QA was better. If this was cocoa and objective c today it would be equally buggy.
> SwiftUI is not swift. It's about framework not language.
True, imo.
> But even that doesn't matter
> Most of cocoa/objc stuff was written long ago and back when QA was better. If this was cocoa and objective c today it would be equally buggy.
I don't think I agree about this entirely. Although you can write unperformant code in any language and framework, SwiftUI is a different world of heavy abstraction. Writing a list view in AppKit using the documentation available allows for and encourages much more deliberate implementation in such a way that it'll be an almost night and day difference compared to the likely NavigationSplitView they're using in Settings. It's an inverse relationship with performance that SwiftUI takes; efficiency of piecing together the high level details first, and little to no control or clarity on how you'd optimize for performance.
My hunch is that with Settings, they're using a NavigationView or NavigationSplitView and not letting each view be recreated on selection, so they're sticking around in memory. However, if they were recreating each pane on selection, it seems like the render of the view waits for some kind of I/O, maybe reading their .plist or interacting directly with a system level CLI, which is why there's a delay before the UI renders.
Another possibility is a combo of both, they're retaining the views in memory AND triggering I/O immediately on selection, so the reads and threads accumulate quickly without being released
Open Activity Monitor, and type in System Settings into the search. Then open the Settings app and press the down arrow key through all of the menus. You'll notice that each one of them appears as their own line item in Activity Monitor until you quit Settings, and if you keep going up and down through the menus, it'll (probably) get slower and slower; it seems like there's a memory leak or something going on there, and my hunch is that each old settings menu was thinly wrapped in a SwiftUI view and gets launched as soon as you click its nav item.