Ask HN: Resources to Learn macOS Development?
90 comments
I would suggest Cocoa Programming for Mac OS X, even though it's based on Objective-C and the book is old. That means it's based upon older versions of Xcode and Mac OS (like ~10 years old). Conceptually it's a good book, but because of it's age the code examples, etc are outdated. The publisher does have forums which can be helpful:
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.
https://bignerdranch.com/books/
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.
https://bignerdranch.com/books/
This is the best answer for hobby Mac programming for AppKit in Objective-C.
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.
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.
SwiftUI is not usable yet on the Mac. I can't talk about its state on iOS, but on the Mac you will run into deal breaking limitations even for the most basic apps.
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.
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.
This. You can also use SwiftUI inside NSHostingView. So you can do parts of your app in swift ui (preferences panel would be a good place to start).
But for more involved stuff this is not production ready yet (except you want to do major reworks with each new SwiftUI revision).
But for more involved stuff this is not production ready yet (except you want to do major reworks with each new SwiftUI revision).
I made a few simple Mac apps in Objective-C during the pandemic in 2020, and I was struck by how hard it was to find tutorials and examples on how to do anything in Objective-C. It's possible I was looking in all the wrong places, but it seems like everyone assumes you're using Swift at this point. I would advise against learning Mac development with Objective-C except to people who have a specific interest in it or need for it. I also think most people accustomed to newer programming languages would probably find it arcane in some areas and tedious in many others (although I personally like it for what it is and don't regret the time I spent with it, I definitely felt like I was making things harder on myself by using it).
There are three reasons for using Objective-C:
- Performance: Sometimes the automatic conversion between Objective C and Swift types causes performance issues. Using Objective-C for some hot paths can be a lot faster. Sometimes just using NSString instead of String in Swift can also do the trick.
- Legacy code: For most projects, there is no point in converting 100s of legacy Objective C classes to Swift. Just leave the old parts in Objective C, and call them from Swift. Rewriting just risks breaking stuff.
- Interface with C/C++ code. Swift has some nice bridging that make calling C code easy (such as automatic conversion of swift strings), but some APIs like socket() are close to unusable in Swift, because they require complicated casts that are impossible to understand. Easier to write those parts in Objective C.
- Performance: Sometimes the automatic conversion between Objective C and Swift types causes performance issues. Using Objective-C for some hot paths can be a lot faster. Sometimes just using NSString instead of String in Swift can also do the trick.
- Legacy code: For most projects, there is no point in converting 100s of legacy Objective C classes to Swift. Just leave the old parts in Objective C, and call them from Swift. Rewriting just risks breaking stuff.
- Interface with C/C++ code. Swift has some nice bridging that make calling C code easy (such as automatic conversion of swift strings), but some APIs like socket() are close to unusable in Swift, because they require complicated casts that are impossible to understand. Easier to write those parts in Objective C.
> based upon older versions of Xcode and Mac OS (like ~10 years old).
More crucially, I'd be curious what people's thoughts are on why the MacOS development community doesn't have newer resources like this.
More crucially, I'd be curious what people's thoughts are on why the MacOS development community doesn't have newer resources like this.
2nded.
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...
[1] https://github.com/ocornut/imgui
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...
[1] https://github.com/ocornut/imgui
I would second this recommendation. This book is how I originally learned Objective-C and macOS development 20 years ago. It walks you through the fundamentals and provides a very good foundation for digesting the (archived) documentation from Apple.
"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/
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/
> 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.
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.
> 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/
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/
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.
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.
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.
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.
Thanks! I really appreciate that you shared your experience.
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.
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.
+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.
+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.
> 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.
Sure, but it does have tradeoffs to the end user around bloat/performance. Not worth dismissing, but also not always the clear winner.
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.
I had great luck with the Big Nerd Ranch books[0].
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.
[0] https://bignerdranch.com/books/
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.
[0] https://bignerdranch.com/books/
If you're not writing command line programs (99% of what I do) I suggest adopting SwiftUI for your interface.
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.
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.
Yeah, macOS development is in a tricky spot at the moment: Apple has signaled that SwiftUI is the future, and so starting out with ObjC/Cocoa is making yourself obsolete right from the get-go, but SwiftUI is not production-ready yet and doing anything serious with it is difficult if not impossible.
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.
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.
I wouldn't worry too much about AppKit going anywhere any time soon. It's probably in a similar position to where Objective-C is, where it's not receiving a whole lot of additions/iterations, but it'll stick around for years to come because of how much of the OS and how many third party apps still rely on it. It's a good idea to become familiar with SwiftUI but I think Cocoa is in a much better position than say Carbon was several years ago.
It's possible to wrap UIKit in SwiftUI (using UIViewRepresentable and UIViewControllerRepresentable), to do the things that SwiftUI can't yet do by itself. Those deficiencies will slowly be filled out, of course - there's no reason to stay exclusively with UIKit any more.
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.
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.
On iOS. The situation is very different on macOS, which is what was being discussed here.
These APIs exist for NSView (AppKit) as well:
https://developer.apple.com/documentation/swiftui/nsviewrepr... https://developer.apple.com/documentation/swiftui/nsviewcont...
Or is that not what you meant?
https://developer.apple.com/documentation/swiftui/nsviewrepr... https://developer.apple.com/documentation/swiftui/nsviewcont...
Or is that not what you meant?
Yeah, I mean that it’s not ready to go.
What sort of complex things are they unable to do? Is there any recourse? Can you use SwiftUI for the majority and dip into something lower level when needed?
SwiftUI's weakness on macOS and to a lesser degree iOS is that it's difficult to fine-tune things to the extent that many longtime Apple platform devs traditionally have. It can usually meet the base case but it makes honing in on the fine details and achieving a high level of polish cumbersome.
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.
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.
To give a quick example: in swiftui for ios, you can not change the spacing between list sections
Was looking at making something that would interact with SystemConfiguration.framework and registers itself on the DynamicStore's callback (something akin to dns-heaven[1]). From the introductory tutorials included with xcode I have no idea what is the equivalent to applicationDidFinishLaunching() where this kind of things would be put.
It looked like maybe BackgroundTask is what I'm looking for, but it seems arbitrarily limited on macOS to an urlsession, whatever that is ?
[1]: https://github.com/greenboxal/dns-heaven/
[1]: https://github.com/greenboxal/dns-heaven/
Just do it.
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.
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.
Swift interops with C directly so there’s no need to wrap in Objective-C.
I just skimmed an article about that. That's quite nice.
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.
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.
I assume those questions are rhetorical, but let me try to answer them in a very terse form just so you have some terms to search the docs for. Assuming you want to use AppKit.
> 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.
> 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.
Paul Hudson has a decent book on macOS programming using SwiftUI and AppKit. It isn't perfect but it is a decent place to start https://www.hackingwithswift.com/store/hacking-with-macos
Is it as in depth as OP appears to be looking for? I've found Paul's content to be good for quick references to high level concepts, and brief how-tos for beginners, but I've not found it to be good for deeper explorations. That said, I haven't read this book, only his free content.
Good question. It, like all of Paul's books, is more of a series of tutorials than a reference.
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.
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.
Here’s a tutorial from Apple on creating a Mac app with the latest declarative framework: https://developer.apple.com/tutorials/swiftui/creating-a-mac....
One thing to decide maybe before specific books is if you want to do SwiftUI programming or more traditional Cocoa programming. They both have advantages, and they can be mixed, but if you are just learning probably best to focus on one approach to start.
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.
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 recently did the SwiftUI tutorials that had a chapter on macOS (from the context of adding macOS as a target alongside iOS). https://developer.apple.com/tutorials/swiftui
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.
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.
Apple's Own Developer Documentation is Exceptional ranging from Cookbook-style guides to Reference Documentation.
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.
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.
The old docs that explain the fundamental concepts about the frameworks are also still available. I prefer them to the current crop of docs because they go deeper conceptually and are more information dense.
It requires a little bit of effort to extract and use them. This tweet is what got me in the right direction:
https://twitter.com/dmartincy/status/1393629254227832838
It requires a little bit of effort to extract and use them. This tweet is what got me in the right direction:
https://twitter.com/dmartincy/status/1393629254227832838
I totally agree – here is the legacy archive search engine
https://developer.apple.com/library/archive/navigation/
https://developer.apple.com/library/archive/navigation/
Nice! I didn't know this search UI still existed. Filtering by platform and typing "programming guide" returns all the good stuff.
Also seek out similar apps on Github, then "reverse engineer" those into frameworks and read Apple's documentation on the framework
In a past life I spent a lot of time developing for iOS, and the one incredibly sore spots in terms of documentation was the build process. Particularly, what are all the things I need to know to effectively build my app, and debug the process.
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.
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.
To get started, I'd Protocol Oriented Programming from WWDC. Not a tutorial or how-to, but more of a look into the philosophy behind Swift.
https://developer.apple.com/videos/play/wwdc2015/408/
https://developer.apple.com/videos/play/wwdc2015/408/
Ah yes, the video that launched a thousand unnecessary abstractions ;) It’s a good exercise to expand your horizons on how you might approach architecting your app but in general the answer to the question of “do I need a protocol here” will still be “no”.
I recommend starting with 100 days of SwiftUI. https://www.hackingwithswift.com/100/swiftui
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
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
This might not be a popular opinion but it was what worked for me:
- Research a little about PostScript and the display version.
- NextStep Developer Documentation [1]
- Apple older documentation (it is archived, but covered a lot of stuff)
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/
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/
[deleted]
Do a little iOS dev since that has 100x more learning resources.
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'.
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'.
Storyboards are slow compared to Live Preview, and lead beginners to adopt bad patterns like Massive View Controllers rather than composable/testable SwiftUI components. Not to mention its horrendous XML format.
> Storyboards are slow compared to Live Preview
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".
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".
Go where the puck is going, not where it’s been. It’s obvious that Apple is heavily investing in SwiftUI to implement their vision for multiplatform app support. Did you see a single storyboard in WWDC22? 21? SwiftUI examples were ubiquitous. You can argue for Storyboards until you’re blue in the face, but they are destined for the dustbin.
A couple years ago I wrote a blog post "Resources for learning Objective-C and AppKit". I wouldn't say it's comprehensive, but it may be useful. https://lapcatsoftware.com/articles/learning.html
Apple Developer Documentation Archive. https://developer.apple.com/library/archive/navigation/
It's filled with the specific type of knowledge you're looking for.
It's filled with the specific type of knowledge you're looking for.
I second this. Apple's official documentation, while suffering from a decrease in quality over the last decade, is still as good as any "tutorial" you'll find.
I find that you have to find the right bit of documentation, which is not always easy on Apple's site. I often find API documentation that doesn't have enough info to just start using it (it's great for reference, though). You need to find the long-form descriptive documentation they have, which isn't always found by your favorite search engine. (And Apple keeps rearranging their documentation meaning that once you have found it, if you don't bookmark it, finding it again can be nearly impossible.)
Agreed. The “guides” are great. The API docs are not.
It's four years out of date and missing the information OP would need for writing apps today.
There are articles in there that don’t go “out of date.”
Highly recommend beginning with Swift and using SwiftUI for UI development. Dive into AppKit and Obj-C when (if) necessary. As an additional companion, check out the HIG [1] or Human Interface Guidelines. It's a great starting point for introducing a feature "the Apple way", and it'll make knowing what to reach for in SwiftUI much more straight forward.
[1] https://developer.apple.com/design/human-interface-guideline...
[1] https://developer.apple.com/design/human-interface-guideline...
I'm just finshing up my first macOS app. I went with SwiftUI because I was new and didn't want to learn an "old" tech. The reality is outside of very basic stuff, SwiftUI is not capable of doing a lot of stuff, so I ended up have to learn not only AppKit as well, but how to fuse AppKit into SwiftUI and fuse SwiftUI into AppKit.
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.
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.
It’s probably more productive to mention what about SwiftUI is a “steaming pile of dung”. For most mobile UI, you can spit out a working design faster than w/ AppKit. It doesn’t even have to be one or the other, you can meld both.
What’s the value in talking about SwiftUI being incapable when you don’t mention what you can’t do in it.
What’s the value in talking about SwiftUI being incapable when you don’t mention what you can’t do in it.
It doesn’t support a lot of what you can do in AppKit at the moment. There are also many bugs in it where it will throw asserts or stop working or draw incorrectly.
Started a new app last year using Stotyboards and AppKit and haven’t regretted it for a second. I use SwiftUI on iOS devices on a daily basis and I don’t have to dip into UIKit very often anymore, but AppKit on macOS was always more mature than UIKit let alone SwiftUI. Plus SwiftUI still has rough spots on macOS.
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 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.
The other responses have some great answers, but I learn best by breaking something that is already working, and so this list may have useful sources of code to poke around in: https://github.com/serhii-londar/open-source-mac-os-apps
That list is an invaluable resource, but it's huge and a bit daunting.
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.
[1] https://github.com/Ranchero-Software/NetNewsWire
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.
[1] https://github.com/Ranchero-Software/NetNewsWire
Perfect, you've provided exactly what I was fishing for - one of the list that was a quintessential perfect example of proper coding.
Be aware any application you distribute must be signed now, or gatekeeper will not allow it to run. This means you must pay the $100 yearly apple developer fee, apple wants to make sure you're not economically disadvantaged. There are no exceptions even for students or open source. Only a licensed nonprofit may be able to waive it.
It's really too bad there isn't a modern equivalent of the Inside Macintosh books. Those were amazing.
[deleted]
Apple has tons of videos on their developer portal.
https://developer.apple.com/videos/all-videos/
Usually a good primer for any topic you want to dive into.
Usually a good primer for any topic you want to dive into.
There is a lot of excellent documentation on Apple's website, but it's all in the “documentation archive” and is at least five years out of date. Please read it anyway! There's great conceptual introductions to every topic you could imagine in there.
I found this course with great ratings while browsing on Udemy this weekend:
https://www.udemy.com/course/professional-macos-programming/
https://www.udemy.com/course/professional-macos-programming/
Building macOS apps is a lot easier with SwiftUI now. This book has quite a few good examples - https://www.amazon.com/dp/B0BP5P9H31
[deleted]
I found the books about Apple technologies by this collective to be very good: https://www.objc.io/
I found Paul Hudson's "Hacking with Swift" products quite useful.
https://www.hackingwithswift.com
https://www.hackingwithswift.com
The most bang for your buck is to watch the latest WWDC videos. Use SwiftUI to hit the road and fill the gaps later. Declarative UI is too powerful and removes a lot of the excuses people had before in UI development. There’s different technologies you’re going to encounter that are the same as Windows-land, but has the Apple branding.
shamelessly off-topic but if anyone here is already good at Objective-C development for macOS and looking for remote work, please drop us a line at: [email protected]
[deleted]
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.