1. 21
Hi Folks,

I’m trying to get back into macOS application development. I used to know the basics of Objective-C and Cocoa stuff back on the early days of Mac OS X with big cat names. At the time, I got a lot of value from the Cocoa Programming book from Big Nerd Ranch.

These days, it seems that every book about programming for Apple platforms is focused on iOS. Don’t get me wrong, I love my iPad, but I’d rather develop desktop apps.

It appears to me that the documentation site has been neglected, and that the search engine algorithms favour returning videos and quick tutorials over books. Anyway, I’m having a hard time figuring out a good recent book about developing desktop apps for macOS. I don’t care if it is Swift or Objective-C, I like both.

Can someone here point me in a good direction?


    1. 3

      I’m still quite new to it, but Paul Hudson’s Hacking With Swift series looks good. He does have Hacking with macOS to cover macOS.

    2. 3

      I second the recommendation for objc.io’s books; despite the name, most of them are on Swift.

      Right now things in Mac dev are in flux between three UI frameworks: you can be mainstream and use AppKit, you can be iOS-centric and use UIKit and then use Catalyst to adapt the app to macOS, or you can use the newish SwiftUI which works with either platform.

      If you use AppKit (or UIKit) you also use InterfaceBuilder, which has changed since the early days. Springs-and-struts layout was replaced with constraint-based layout, which was in theory much cleaner and more flexible, but which I found to be fiddly and complex, esp. the IB Ui for configuring it.

      SwiftUI is a very cool modern reactive/immediate-mode framework inspired by React, Elm, etc. You implement the UI in code, but the GUI preview pane is real-time and editable, with changes being reflected in the code. I prototyped a small app with it last year and it was really smooth.

      The word is that SwiftUI is still a bit rough for deploying full apps, but it’s clearly the future and keeps improving. If I started on a real app today I’d definitely choose it over AppKit. (Actually it’s not either/or: SwiftUI uses AppKit views, and you can build your own NSViews and put them in a SwiftUI app.)

    3. 3

      Honestly, if you’ve got OpenStep-era experience then a new book probably won’t help much. There are basically three significant things that have changed in AppKit since 1993:

      • ARC is a huge change for Objective-C in terms of programmer experience and a small change in terms of semantics (with ARC, you have safe zeroing weak references). If you were using GNUstep-style ASSIGN macros before, then ARC really just means that you don’t need them anymore.
      • CoreAnimation. Even ignoring all of the pretty effects, the big change here is that individual NSView instances can now render to a texture (CALayer). This means that they won’t always have -drawRect: called for each frame (not observable in code that isn’t doing evil things) and that they can now render in parallel with other views. The latter change is important. It’s opt-in behaviour, but if your model / controller objects support concurrent reads then your views can update in parallel (I believe it’s done from a libdispatch concurrent work queue).
      • NSCell is deprecated in old collection views, gone in new ones. NSCell was an optimisation from when 1 MiB of RAM for an application was a lot that placed a lot of burden on the programmer. Now, all of the things that took NSCells and required you to explicitly configure them before drawing can take full NSView instances and maintain state through them. For example, an NSTableView can just ask you for a row of cells when one becomes visible and not need anything else when the user scrolls it. This also interacts with the point above: all of these NSView instances may opt into parallel rendering and so your table view can update all of the cells in parallel, given enough cores.

      Beyond that, pretty much everything else is small incremental changes.

      That said, if you want to jump into SwiftUI, that’s quite a different paradigm and a book would probably help.

      1. 1

        I would say classic NIBs/XIBs to Storyboards has been a fairly big but mostly UI-side transition. There’s some tricks you can only do with the Storyboard-only (at least according to IB) NSSplitViewController that isn’t in the classic NSSplitView, like the Big Sur unified sidebar. Not without some “fun” hacks, anyways.

    4. 2

      Books by Objc.io are great. Also whilst not a book, Composable Architecture seems like a nice way to develop cross platform (iOS/macOS) apps.

      I saw CodeEdit posted recently that seems to have nice code.

    5. 2

      I’d really find it useful too - I’ve been getting into Mac development by resuscitating an old AppKit app, and while I find the toolkit reasonable and refactoring makes sense, I find it hard to do new things - i.e., I’m still a bit confused on making my own outlets, controllers, etc. There’s a lot of reference documentation, but it doesn’t make as much sense without context.

    6. 1

      Thanks a lot for the replies folks. It seems that there is no comprehensive recent macOS development book out there. Best bets appear to be Hacking With Swift series and objc.io series, both of which are heavily iOS focused and have macOS as a cool addition. I was not expecting this at all. From one point-of-view, I’m relieved, for I was questioning my own search skills, pondering why couldn’t I find a recent macOS development book. From another point-of-view, this is quite worrisome because macOS is damn great and deserves better.

      Last time I did any native macOS development, I used Objective-C/Cocoa, I have no experience with using AppKit and Swift. I went through the small tutorial at Apple site about SwiftUI, it is really cool but I have a feeling that AppKit might be more useful. I might just get some 10-year-old book on AppKit and Hacking With Swift, and try to get up to date by combining both. It will be more recent than my current knowledge, anyway.