I am not interested in API documentation or how-to recipes. I am looking for explanations that will help me build a conceptual understanding of macos UI development. What is the equivalent of the event loop under macos? Do events bubble up through the hierarchy? What is the right way to persist user configuration?
In the windows era there was a very famous book called "Programming Windows" by Charles Petzold. I am hoping that I can find similar book for macOS programming.
Please do point me to the resources that have helped you.
I am not interested in non-native frameworks like Electron or PyQt. If I am developing an app for myself I don't want to deal with daily irritation of working with a non native framework.
https://forums.bignerdranch.com/c/cocoa-programming-for-os-x...
They also have a Swift book, but I haven't personally read it. They also have an Advanced Mac OS X book, but it's also old and isn't on their website anymore.
As others have said, SwiftUI is the future and you might want to instead look at that if you can find a decent guide to it -- a lot of what's on the web is very badly obsolete already. It's a very different model.
Folks, there will come a point where new UI features don't ship anymore for AppKit. Telling people not to learn SwiftUI is extremely counterproductive.
If you want to make Mac apps, learn AppKit. You can use AppKit from Swift just fine, there's no need to use Objective C. Some of the text APIs are a bit cumbersome to use with Swift because of the different string semantics, but for the most part writing AppKit code in Swift is pretty sweet.
More crucially, I'd be curious what people's thoughts are on why the MacOS development community doesn't have newer resources like this.
Is there a macOs equivalent of the Windows Internals [0] books?
I recently came across ImGui [1] which uses C++. I assume that cross platform software from Adobe, Microsoft, etc have C++ at their core and would love to find more in the way of resources for C++ on mac. Anyone?
[0] https://www.amazon.com/Windows-Internals-Part-architecture-m...
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 :)
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.
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/
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.
Sure, but it does have tradeoffs to the end user around bloat/performance. Not worth dismissing, but also not always the clear winner.
I’m not sure that I can recommend starting with SwiftUI, yet. The tech is still quite green, and quite different from AppKit (the current MacOS framework). The documentation also … leaves something to be desired …
But it also depends on how soon you want to be shipping software.
It might be a great idea to start with SwiftUI, if you think you’re still a couple of years from releasing stuff. I’m sure it will mature rapidly.
Of course, you could also learn a cross-platform system, like Electron, or React Native. I can’t make any suggestions, there.
Source: Been shipping native Mac software for over 30 years.
It's Apple's future for cross platform (ios/macos/watch) applications. Hardcore longtime mac devs find it frustratingly unable to do some complex things they want to do (and yay that they do!) to take advantage of the mac OS. But you don't want that; you just want to interact with your own code. And SwiftUI will let you do the basic stuff easily...and likely just (well, almost just) recompile your program for your iphone or ipad.
Presumably in a few more years the wrinkles will be ironed out of SwiftUI, but right this instant is unfortunately a crummy time to start out with Mac development. I would also agree that you should start with SwiftUI, but just with the awareness that it sucks ass and that you'll have to throw out most of what you write over the next few years.
More significantly, SwiftUI introduces a new declarative paradigm - very different from what was before. It makes a lot of previously laborious things, easy.
So, yes - SwiftUI is the way to go, and it's ready to use now.
There's also some things, particularly on macOS, that you're going to need to drop down into AppKit to do, which is possible thanks to NSViewRepresentable/UIViewRepresentable, but a bit frustrating is necessary.
Personally speaking I'm still limiting usage of SwiftUI to views that are either simple or don't have much in the way of user interaction. It's decent at that, but for most other things I'm using plain old AppKit/UIKit. SwiftUI is still green compared to AppKit/UIKit's multi-decade legacy, so hopefully it will improve in the coming years.
I started with one of the Big Nerd Ranch books many years ago. I spent a few evenings reading it, and then spent a few hours dabbling with Objective C in XCode. I then got frustrated and put it down for a few years until I took a job that involved some Objective C. (This was over a decade ago.)
It's surprisingly easy to learn the details of system calls by Googling and looking at stack overflow. Yes, the semantics are different, but the general theory is the same. There's a main thread that's often referred to as the main run loop. Accessing your UI outside of the main run loop (thread) is a big no-no.
As much as I want to vouch for learning Swift, (it's really easy if you have a Java / C# background,) there's also a good reason to be proficient in Objective C: It's just a layer on top of C. It's very easy to wrap C APIs in Objective C and then call them from Swift. This is important, because if you're trying to do something low-level, you will need to interact with a C API. (Although, Swift fixes a lot of the weirdness of Objective C if all you want is something that's like Java / C#.)
FWIW: There are some semantic differences that can take some time to adjust to. In Objective C, sending a message to a null object is a no-op instead of a runtime exception. Swift appears memory safe, but I've done things with timers that cause surprise crashes.
FWIW: One of the things I really appreciated in Objective C was that I could use real C when working with a C library. It wasn't something I did often, though. But, IMO, it's definitely something that someone who wants to do low-level Mac programming should learn. Sometimes it's just easier to work with a library in C.
> What is the equivalent of the event loop under macos?
NSRunLoop / CFRunLoop. You rarely need to interact with it directly. Typically only the main run loop on the main thread is important, if you want to do something on a different thread you typically use dispatch queues (GCD=grand central dispatch) instead of run loops.
> Do events bubble up through the hierarchy?
Yes, most events go up the responder chain, which is typically view -> superviews -> window -> app. You typically respond to events by implementing methods defined in a protocol (like "keyDown" or "insertTab") or by implementing delegate methods ("windowWillClose"). Sometimes you also have to listen for notifications from NotificationCenter.
> What is the right way to persist user configuration?
NSUserDefaults for everything that can be serialised into a number/string/dictionary easily, and the application support directory for anything you want to store in files.
I would say it is a decent place to learn how to get started with macOS app developing using either SwiftUI or AppKit. For somebody with no knowledge of macOS app development it will put you in a good position to be able to work from Apple's documentation and further learn the platform.
However it is not anywhere near as in depth as something like Petzold's Windows programming books. Although it isn't meant to be anything like Petzold's books so comparing is kinda pointless anyway :)
I bought Paul's books in a decent value (to me) sale a few years ago and I rate them quite highly overall. Much higher than most other self-published programming books.
SwiftUI is new future according to Apple, easy to start, but also unpolished compared to Cocoa. Cocoa is old and polished, but maybe eventually a legacy technology. I'm personally still in Cocoa world, but parts of SwiftUI are interesting.
I expect SwiftUI to stay pretty high-level so don’t expect nitty gritty details. But Apple seems to be putting a lot of effort there so you might want to check it out.
https://developer.apple.com/documentation/technologies
There are dozens of entrypoints depending on the framework (e.g. SwiftUI, Cocoa, CoreFoundation etc. ) , Platform & Application you are interested in .
I recommend starting with an application in mind (e.g. a MenuBar Utility, Notification Bar Widget, Standalone App, CLI utility, etc) and then digging through Apple's own framework documentation .
That will give you the e2e experience covering all the tools & frameworks needed to finish the task. Then repeat with a more complicated app or one in a different domain.
It requires a little bit of effort to extract and use them. This tweet is what got me in the right direction:
The Apple-provided documentation assumes you already know many of the ins and outs of C/C++ build arcana, and on top of that does a terrible job of explaining what parts XCode adds or subtracts to the process. I never came across a resource for this information that was even passable, and wound up getting most of my answers from IRC.
Despite the name, it’s quite fast to get through.
Apple also has really great videos on life cycles etc https://developer.apple.com/wwdc21/10022 that go over the underpinnings
Why this instead of a book? MacOS X UI is the result of many years of experiment and technologies. Going over the historical view gave me time to build a mental framework to work on instead of pushing things as they are today. MacOS is also changing so much that the documentation gap only gets worse with time.
Storyboards, SwiftUI, iOS, UIKit are noisy in that sense because they solve problems that you might not understand from the get go.
Understanding Objective-C is also crucial because besides SwiftUI, the backbone was made with Objective-C characteristics in mind. But this one I don’t have good references for besides Smalltalk books and Clang documentation.
[1] http://www.nextcomputers.org/NeXTfiles/Docs/NeXTStep/3.3/nd/
Once you grok iOS, you'll be at home with macOS since they follow the same patterns.
Stick with storyboards, don't bother with SwiftUI (no, really, don't do it) and try to use as much default out of the box behaviour as possible, instead of wondering 'how do I do that X thing I did on platform Y'.
Citation needed. Even on Apple silicon, I'm not even sure Live Preview can crash faster than Interface Builder and it has no shortage of practice.
> lead beginners to adopt bad patterns like Massive View Controllers rather than composable/testable SwiftUI components
There is no requirement at all on how big a storyboard is and allowing things to occupy the same *.storyboard where they would have to separate XIB files is an imporvement where it is useful.
> Not to mention its horrendous XML format
Where it does not come at other costs, standard formats (XML) are easier to operate with external tools over bespoke formats (turing complete Obj-C or Swift code). The properties in those files were more numerous than their SwiftUI counterparts, but they served a purpose.
Working with SwiftUI and the bonanza of implied default behaviors required to achieve its terseness add new salience to the idea "it is better to be explicit than implicit".
It's filled with the specific type of knowledge you're looking for.
[1] https://developer.apple.com/design/human-interface-guideline...
My advice is don't be attracted by the shiny toy that is SwiftUI. It's a steaming pile to dung, unless you just want some basic forms/tables/text.
What’s the value in talking about SwiftUI being incapable when you don’t mention what you can’t do in it.
If you want to go for the typical macOS look & feel stick with AppKit.
Resources: barely any
Apparently you’re either not interested in macOS development or you’re way too experienced to need help.
If you're interested but not sure which project to start with, I recommend looking at NetNewsWire[1]. It's a very nice codebase with experienced Mac and iOS developers on the team. It's cross platform (iOS, macOS, ipadOS), uses the latest technologies, and has speed and stability as design priorities.
It's the opposite of an Electron wrapper around a web app.
Usually a good primer for any topic you want to dive into.
https://www.udemy.com/course/professional-macos-programming/
