4 ms·
Always great to see native macOS apps! Is there a reason you aren’t using SwiftUI for the whole thing and that you opted for Core Data instead of Swift Data?
by _mlbt 1y ago
Always great to see native macOS apps! Is there a reason you aren’t using SwiftUI for the whole thing and that you opted for Core Data instead of Swift Data?
- wpm 1y agoSwift Data is CoreData in a wrapper. Also, not OP, but I’m glad it’s written in AppKit vs SwiftUI purely; AppKit just feels better on the desktop. I can always “smell” a SwiftUI app just like I can an Electron app.
- drcongo 1y agoIf the Settings app on current macOS is SwiftUI, then I can too. It's horrible.
- sgt 1y agoNever thought of that. Is that why the Settings app is so slow? If I click on one of the menu items on the left, it takes half a second or more to load the screen.
- tough 1y agoSearch is also broken af raycast saves me from going mad
- galad87 1y agoSwiftUI doesn't help, but each panel is a separate process. The previous version of System Preferences hid the delay by showing an animation, the new one doesn't.
- zerkten 1y agoWhy is a separate process necessary here?
- pvg 1y agoYou don’t want login settings, cursor blink rate settings and random app settings running in the same process
- kstrauser 1y agoWhy? Is there a mechanism by which one of those would be able to interfere with another?
- pvg 1y agoYes, the mechanism of “memory access”.
- sgt 1y agoI still think they could easily load quicker though. Even switching between the different menu items in Settings takes long, when going back to ones that you already used earlier. They don't seem to be doing a lot of caching. At least they could keep those processes running for a while. Unless it's actually SwiftUI taking time to render that UI, which would be bizarre. As a macOS user I am so used to everything happening in the blink of an eye, so this is something that stands out. It's really not a big problem, 300-400ms.
- kstrauser 1y agoOk, let me rewind a little. Are preference panes actually running apps? I imagined them more conceptually similar to an HTML form that System Settings displayed and processed and then wrote the results back to a plist or whatever. And in that model, there wouldn’t be a clear advantage to having separate processes. Was I imagining that wrong?
- pvg 1y agoYes they are more applike than UI-definition-like.
- anosidium 1y agoThanks! I’m glad to hear that. It’s an AppKit-first app — I’ve used SwiftUI in parts where it fits well, but I’ve avoided relying on it entirely because it’s still maturing, especially on macOS. In certain areas, it can compromise the native look and feel, or introduce unexpected behaviour. As for Core Data, it’s a proven and robust framework that already does everything I need. Swift Data is still relatively new and doesn’t yet offer the same level of flexibility or stability for more advanced use cases.
- aegypti 1y agoTowards the end of COVID lockdowns I wrote a small, native macOS replacement for Zotero and ended up having to go with AppKit. Bit disappointing to hear the look and feel of a Mac assed mac app still hasn’t been replicated in SwiftUI. Do you write about your experience with macOS dev at all? I would love to hear about it. I still look back fondly on that experience and toss around the idea of revisiting it, Documentation Archive and all.