[mysticllama]

"I am looking for explanations that will help me build a conceptual understanding of macos UI development."

it depends on your learning style of course, but if you like lecture / course-style learning, i highly recommend paul hegarty's CS193P, it will definitely give you the in-depth, conceptual explanations you're describing.

while it is an iOS dev course (taught at stanford, lectures are freely offered online), the newest lectures are using swiftUI for UI, so pretty much all of it will translate to doing macOS dev.

paul is a cs prof at stanford and worked at NeXT and then on the objc lang many, many years ago, so he's been doing this a while and knows a thing or two :)

https://cs193p.sites.stanford.edu/

[saagarjha]

> while it is an iOS dev course (taught at stanford, lectures are freely offered online), the newest lectures are using swiftUI for UI, so pretty much all of it will translate to doing macOS dev.

They absolutely will not. SwiftUI on macOS and SwiftUI on iOS are very different beasts. For the latter, it is at the point where you can actually kind of make a good app in it with the majority of your code only using the framework. On the other hand making a good macOS app using only SwiftUI is pretty much impossible. There’s a lot of stuff that is broken, or looks wrong, or there’s controls missing or customization that’s not exposed. I would go as far as to say that you should ignore SwiftUI’s existence if you want to learn how to write a Mac app today, get familiar with the platform, then dip your toe in by trying some of the limited situations in which it actually works.

[CharlesW]

> On the other hand making a good macOS app using only SwiftUI is pretty much impossible.

How recent was your experience with it? I'm assuming your characterization is accurate, but since SwiftUI is being used for notable bits of Ventura, I'm curious what OS version it reflects. https://troz.net/post/2022/swiftui-mac-2022/

[kybernetyk]

Apple has always the joker card of being allowed to use private APIs. They have also a lot of money an can waste developer time on rewriting their SwiftUI applets constantly.

If you don’t have that kind of resources it would be wise to use the tried and true stack and switch over to the shiny new thing once it’s actually stable.

[saagarjha]

Pretty recent, I check it every once in a while to see what’s going on. Of course, with macOS generally most of the changes happen around WWDC ;)

SwiftUI on macOS is currently ok for a few usecases. One is little document apps. Emphasis on little, this is going to be things that wrap an image or a text file or something. The API is reactive so it’s not really designed for complex/partial file formats. Another good usecase is just pure drawing/animation. This code will look identical on macOS and iOS and is very easy to write with SwiftUI. Finally, the last thing that mostly works is just lists of content. Not table views, those aren’t very good yet. I’m talking about Twitter-like content, as in a media viewer in list form.

What doesn’t work well is anything that has to do with controls (either they look very ugly, the control doesn’t exist, or SwiftUI has no concept of some significant portion of the control). If you want to do like focus loops or right clicks or anything complicated, forget it. (Some of these are getting fixed piecemeal, but AppKit has like a thousand little things that make good apps and it’ll be a while before they are all fixed.)

By way of example, I actually have some small apps that show this off well. https://github.com/saagarjha/EffectivePower is a little view-only document shoebox style app. It’s 100% SwiftUI, has one main screen that is a hand-drawn graph, and some auxiliary UI. This makes it about as good as it could be for using the framework. Making the graph was a delight. Making it perform well was a little bit of work but not too bad. The document abstraction mostly works except SwiftUI expects me to be able to create new documents and I’m just a viewer app so I need to crash if you try to make a new document. The sidebar is a List, which is fine, but I actually wanted it to be a Table. However Table selection asserts right now if you update its selection faster than the NSTableView that backs it animated. Of course in SwiftUI there is no concept of animation duration so you can’t really stop this from happening. You can also zoom the graph in the app. On Monterey if you tried to zoom a couple of times the system magnification gesture just stopped working silently. On Ventura I believe they have fixed this, or at least it isn’t trivially broken anymore. This is common for SwiftUI.

By way of contrast, https://github.com/saagarjha/VirtualApple is also pretty simple but it’s 100% AppKit. I had originally written it in SwiftUI but it’s just not possible to make it be a good Mac citizen. It is “document based” but because it deals with multi-gigabyte VMs I can’t actually let it do the default document based behavior, which includes making hidden revisions whenever the files update (which means you get a dozen secret copies of the VM). In AppKit I can just turn this all off and still look identical to any other system app. (Caveat: if I want the recent files menu and don’t want to use a storyboard, this is actually not available even in AppKit without SPI). Also, I have a little configuration screen which is all buttons and checkboxes. AppKit lets me align it precisely how I want so it looks nice. In SwiftUI it would look pretty awful.

[CharlesW]

Thanks! I really appreciate that you shared your experience.

[jb1991]

How about using SwiftUI on Mac via Catalyst?

[saagarjha]

It's (how good SwiftUI is on iOS) * (how good Catalyst is on macOS), which is about (not too bad)^2≈passable.

[cjk]

I can't vouch for any of the more recent versions of CS193P, but the original incarnation on iTunes U in ~2008 was my introduction to Objective-C and C, and I found it invaluable. I remember Loren Brichter's guest lecture on the development of Tweetie being really insightful.

Personally, I'd skip Swift / SwiftUI until you have a decent understanding of the Objective-C frameworks underpinning the vast majority of the macOS/iOS SDKs.

[the_gastropod]

+1. I just finished up going through this course, and found it very well-taught. Bonus points, the projects are actually pretty fun and cover quite a lot of ground.

[semireg]

+1 as well. This helped me finally build my first app, and things learned translated very easily between apple platforms. Although, I don’t agree with dismissing Electron. It’s what I eventually pivoted to in order to create a desktop software business. For me, electron is the best of all worlds, literally.

[daveidol]

> For me, electron is the best of all worlds, literally

Sure, but it does have tradeoffs to the end user around bloat/performance. Not worth dismissing, but also not always the clear winner.

[semireg]

Emphasis on “for me” aka, the indie developer, and in terms of sales (a measure of value) for this particular use case, electron was the foundational enabling technology.