Join Simon Allardice for an in-depth discussion in this video What is Cocoa?, part of Cocoa Essential Training.
- View Offline
Cocoa is a term that could be used informally or formally, and it has a few different meanings worth exploring here. Informally, I can just say Cocoa Development as a generic phrase that means developing applications for Mac OS X, and everything that entails. The world of creating apps that run on the Mac, the tools, the language, the available libraries and frameworks, the runtime, the ideas we use when doing this, just everything. Now, what we call Cocoa began in the late 1980s with NeXTSTEP, the operating system created at NeXT Computing when Steve Jobs left Apple.
And when he rejoined Apple in the mid-90s, NeXTSTEP was used as the basis for Mac OS X, and a lot of the classes, the libraries, the ideas we use in Cocoa now, come from those original NeXTSTEP days, which is why the letters NS still permeate so much of what we do in Cocoa 25 years after NeXTSTEP. Now, Apple's own official documentation sometimes use the word Cocoa for both Mac OS 10 development, and iPhone and iPad development. Although they often use the term Cocoa Touch to refer to the specific area of developing apps for iOS.
But if I am talking to someone at a conference and they tell me they're a Cocoa developer, I assume they build apps for the Mac. I have never actually had anyone introduced themselves as a Cocoa Touch developer. They're much more likely to just say they're an iOS developer instead. So that's the kind of informal use of the word Cocoa. Now, Cocoa is technically not the only option for developing Mac apps, but it is the recommended way. You might also occasionally hear the term Carbon used when talking about Mac development.
Carbon was a set of APIs provided by Apple to allow Mac OS 8 and OS 9 apps to run on OS X. It's only 32-bit, has been fading for years, most of Carbon is officially deprecated in Mountain Lion. And it's not something you should be looking at, unless you have to officially support or migrate much older legacy Mac applications. Now, Objective-C is the language we use for creating Cocoa apps. There are projects like MacRuby, RubyCocoa, and pi Object-C that make it technically possible to use Ruby or Python to write these Cocoa applications, but we're not going to use those here.
And even though I am very fond of both Ruby and Python, I don't really recommend using them for Cocoa. Cocoa is built on Objective-C, this is not an arbitrary choice, and picking another language does not remove Objective-C from the picture, it simply puts another layer between you and Objective-C, which you'd have to learn anyway. If you are a Cocoa developer, you know Objective-C, end of story. Now, as soon as you start using Objective-C as a language--even for simple command line apps without a user interface--you're going to be using the Foundation Framework, a collection of basic useful classes, things like NSString, NSDate, NSArray.
Over a 100 classes are written and compiled together into the Foundation Framework, and you can't practically right an Objective-C program without linking to this Foundation Framework. In the simplest of Xcode projects, like this command line tool, if I look at Frameworks, we're already linking to it, and we can have all the different headers of those classes that exist in that Foundation Framework. But great as the Foundation Framework is, it isn't enough for us now.
We need classes that represent user interface elements, like windows and buttons and menus and fonts and cursors. We also need functionality that can control what's different about a visual application over a command line application. When we write a command line app, it should just run through as fast as possible and finish. But with a visual application, we need it to stay running, and to continually respond to being moved or minimized or clicked on, to continually respond to events, until we explicitly quit the app. What's referred to as the event loop.
Well, I don't want to have to write all that code myself, and of course, I don't have to. Apple has already written that functionality--classes dealing with alerts and buttons and fonts and menus and the application idea itself--and it has compiled these together into another framework. And that framework is called Application Kit, or AppKit. Now, there is an equivalent framework for iOS development containing the iOS versions of these classes, and that's called UIKit, but every Cocoa application will use at least Foundation and AppKit frameworks.
Now, there are many other frameworks available to us when developing Cocoa apps, but all the other frameworks are optional choices, you use them if you need them. There are frameworks for working with audio or video, talking to Bluetooth or USB for security or networking, or working with QuickTime. And we'll see a few of them in this course, but we will always need Foundation and AppKit in Cocoa. Now interestingly, there's a difference between what Cocoa is officially and what Cocoa is technically. Here is Apple's official documentation.
They formally state that for OS X development you need, quote, "Foundation and AppKit frameworks, all other frameworks are secondary and elective." But it's interesting to see that what they say and what they actually do is a little different, because technically in Xcode when you make a Cocoa project, you get three existing frameworks-- not just two--and let me show you that. A moment ago I showed that in a typical out of the box command line application, that is with no UI, not a Cocoa application, we link to one framework, the Foundation Framework.
Well, in a typical right out of the box Cocoa application--like the HelloWorld one I just created--we also link to one framework called Cocoa. Well, okay, what is that? Well, it's not really anything, it contains no classes, no actual code. If I expand the header file, what I see is one thing, Cocoa.h. I click that, I find that all we're doing is linking to three other frameworks: Foundation, AppKit, and CoreData.
Even if you don't need it, even if I unselected CoreData as a check box when I made this Cocoa project, it's there. Apple consider CoreData to be a very important framework--and I agree it is important--but important is not the same as necessary, which is why CoreData for us will be a separate course, but we will always be using Foundation and AppKit. So Cocoa has an official definition, it has a technical meaning, but when I use the word Cocoa in this course, I am going to use it the informal way most developers refer to it. The world of creating apps for Mac OS X.
- Installing the tools
- Creating your first app
- Adding basic interactions
- Understanding the Cocoa application life cycle
- Creating custom controller classes
- Creating alerts
- Understanding delegation
- Working with buttons, text fields, sliders, and more
- Using layout and data views
- Adding and editing toolbars
- Using key-value coding
- Binding objects
- Debugging code
- Distributing an application
- Creating icons and full-screen apps