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.