The book's overall structure

Broadly speaking, the book can be thought of as consisting of three parts:

1. The first few chapters will make sure that the basics have been covered, albeit very concisely. Less experienced readers may find it advisable to take these chapters slowly and possibly that some extra work is necessary to get up to speed.
2. The second part concerns topics that are very much tied to programming for Apple devices in general, and macOS in particular, making use of native code provided by Apple through the Cocoa application programming interface. The chapters don't necessarily need to be read sequentially.
3. The third part of the book moves beyond writing the code, to look at how to handle some of the challenges involved in producing robust and maintainable code in an up-to-date and practice-oriented context, and the tools that are available to make that easier.

How Unix, macOS, Cocoa, and AppKit fit together

In the beginning, there was Unix, developed by AT&T in the 1970s and initially intended for use inside the Bell system. Toward the end of that decade, the University of California, Berkeley, released a modified--and free--version of it, called Berkeley Software Distribution (BSD).

Darwin

Apple released the Darwin operating system in 2000. It was derived from BSD and a number of other sources, including NextStep (which is why the Cocoa class names are generally prefixed with the letters NS), and contains the I/O Kit device driver API that saves you ever having to worry about getting keyboard or mouse input into the computer, and a million other things.

Info about Darwin is available at puredarwin.org, and if device drivers are your thing, Apple's I/O Kit documentation starts here: https://developer.apple.com/library/mac/documentation/DeviceDrivers/Conceptual/IOKitFundamentals/Introduction/Introduction.html.

macOS

Strictly speaking, macOS, like OS X before it, is a platform built on the Darwin operating system, although we generally think of it as being the OS itself (hardly surprising given the name), and it provides a collection of frameworks, a large group of which comprise Cocoa, which turn what is basically Unix into something that is basically much more than Unix.

Cocoa

All the shiny stuff, all those browser windows, sliders and buttons, movies, animations, sounds, file access (this list could get very long), what Cocoa does. Cocoa is what you use to create apps, mixed in with some logical organization and design. If devs were portrait painters, then Cocoa would be a cupboard full of brushes and tubes of paint.

Cocoa itself breaks down into different layers, including what Apple refers to as the Cocoa umbrella framework, made up of the AppKit, Foundation, and Core Data frameworks.

AppKit is part of the Cocoa application layer, and is made up of 125 classes and protocols, providing macOS with its user interface; event handling, drawing, menus, views, tables, text and fonts, printing, file system access, and so on are all to be found in AppKit.

Foundation provides us with the lower-level stuff such as data storage, arrays, dates, notifications and such, as well as abstract data classes that are not used directly, but from which many other classes are derived.

Core Data, as we will see in Chapter 9, Getting More from Interface Builder, provides us with a powerful framework for the management of persistent data.

The term Cocoa is very fluid; even at Apple it gets used in a more general sense to mean the whole range of frameworks, at many levels, available to you, the developer. And does it matter? I would argue that it does not. Whether a framework belongs to AppKit or Foundation, or some other layer, is going to make very little difference to your ability to craft engaging and useful software.

Harnessing that power

Cocoa is basically many, many lines of code, written by Apple's own developers, for use on its own platforms. How many lines? I'd love to know, too, but I don't see Cupertino releasing that kind of information anytime soon. Suffice to say, drawing a window on a screen starting with nothing but 1s and 0s is far from trivial, and you should be glad you don't need to do it yourself. Apple has done it for you, millions of times. Despite the fact that drawing such a window involves as much logic as a small Xcode project itself, all you need to do is write a couple of lines of code and there it is, ready for you to add the sexy stuff. All the detail, all that boilerplate, has been abstracted away for you. And the same goes for countless other blocks of repetitive but superbly tweaked code that you will likely never see (and quite possibly never think about again).

All you need to do to make use of this mountain of tested, optimized, and field-hardened code is issue the correct instructions to the libraries, which means knowing the Cocoa API. It's a very large API, to be sure. And nobody--nobody at all, not even at Apple--knows all of it. Some parts you may have learned inside and out already; others you certainly will learn. But for as long as you write Cocoa apps, you will be looking things up in Apple's documentation, or searching Stack Overflow and other developer forums for help and advice.

In case you don't know it (yet), Stack Overflow frequently abbreviated to SO, is one of the most valuable resources on the Web. You can search and read the site without membership, but once you're signed up, you can post questions and, indeed, answer them. The rules are quite strict, and the levels of discipline and respect are very high. Seriously, if you're into development, you'll love SO. It can be found here: http://stackoverflow.com.

The various Cocoa frameworks presented in the second section of this book are those that are likely to be of relevance to a majority of readers. A firm grounding in these topics will provide you with a solid fundament on which to mold Apple's huge repository of code into apps of a professional standard, and with experience of one set of frameworks, you'll find it ever easier to get to grips with new ones, even to the extent that you will often be able to make an educated guess rather than consulting the docs. The Cocoa APIs have been updated to work more expressively with Swift, which in turn means it becomes easier to recognize the patterns being used in the frameworks you use, as the interface between Cocoa and the Swift language itself become more consistent.