Code is the engine of an application. The user sees the interface, but that interface only shows up on the screen and responds to user actions because of the underlying code.

Being a Cocoa programmer means taking a concept and figuring out how it can be expressed in code. In most cases, code for a Cocoa application is written in Objective-C.

If you're new to programming, you might wonder what code is. It's simply a collection of instructions. In fact, writing code for a computer is similar to writing instructions for people. For example, take a look at the following driving directions.

If this was Objective-C code, it might look more like the example below:

When you write instructions for a person, you can leave certain details out because they're obvious. Programming languages are more strict. You must be explicit and consistent.

This table shows how the structure of the code can be broken down into smaller pieces:

There are three parts to each line of code in this example: an object, a message, and an input value. Not all Objective-C code is exactly like this. Some actions have no input, for example.

Most of this tutorial focuses on practical examples instead of theory, but there are a few ideas that need an explanation before we dive in.

A variable is simply a label for a container. It holds a value, and the value can change at any time. A variable can hold any type of data, such as text, images or numbers.

For example, a variable called milesPerGallon might have an initial value of 22. That same variable could be changed to another value. An example of that is shown here:

In Objective-C, variables must be declared before they are used. Here are some simple examples:

Each of these lines declares a new variable, prefixed by a type. The type states what kind of data the variable can hold. The variable milesPerGallon is declared as an int, which is an integer number.

The id type can hold any object. If you don't know what an object is, don't get stuck on it now. We'll learn more about that soon.

There are many variable types defined by Cocoa itself, and you can create your own. For this tutorial, we're only going to use the generic id type.

An assignment is a line of code that assigns a value to a variable, just like in algebra. For example, here we assign a line of text to a variable called order.

The @ symbol in front of the text is an Objective-C convention, which we're not ready to get into the details of just yet.

Methods are a list of instructions for the computer to perform. The list is given a name, so that the same list of instructions can be performed over and over.

For example, the list of instructions from the first section could be grouped as one method called driveToWork, shown below:

The code to call the method in Objective-C looks like this:

Calling the driveToWork method is essentially the equivalent of calling all of those other lines of code individually. It's not just to save space. If you need to change the contents of a method later, you can do it in just one place.

Methods can have both input and output, though neither is required. Output from one method can be used as input for another. Here are some simplistic examples:

We use assignments to store the method output in variables. For example, the currentSpeed method returns a value which we assign to the speed variable.

When writing code, things that may seem trivial can actually be very important. Even leaving out a single character or putting particular parts of code in the wrong order can cause errors.

When Xcode sees incorrect code, it can typically only display an error because it doesn't know what your intentions are. It's up to you, as the programmer, to fix the error. It's important to understand some basic formatting rules.

The spacing between words in code might seem strange. In English, an instruction to exit the freeway looks like this:

In Objective-C, it looks like this:

It's easier for the computer to understand the code if certain words are grouped together. Not all methods are spaced exactly like this. You'll learn more about this as you go.

In English, a period (.) marks the end of a sentence. In Objective-C, each instruction ends with a semicolon.

If you leave it out, you'll get error messages. Some instructions span multiple lines. In those cases, you put a semicolon at the end of the final line only:

You can put these multiple-line instructions on one line if you like. Formatting them across multiple lines is just meant to make the code easier to read.

Many things in Cocoa are presented to developers as classes. For example, a number is represented by the class NSNumber. A class describes either a real-world object or an abstract concept by giving it specific attributes and methods.

There are whole books on the theories of classes and their design, but we don't need all of that to get started. We're going to focus on practical basics.

To write an application which manages photos, you might start by creating a Photo class. Each photo has variables which define unique attributes about the item, such as the ones listed below:

These variables are called instance variables, or simply attributes. Here's a photo Objective-C class with the attributes from above:

The @interface statement begins the Photo class definition. It inherits from NSObject, which means it has all of the same functionality as that class. Again, we're not going to get too stuck on the details of what that means yet.

The next several lines list the attributes of a Photo, each one prefixed with id. This is how Objective-C knows that these are attributes. Not all attributes are id, but we can do it for simplicity here. The class definition ends with @end on the final line.

In addition to attributes which store information, classes also have methods, which perform actions. For example, you might want to do the follow things with a photo:

We can express these as methods in our Photo class:

The methods are declared after the brackets, but before the @end statement. Each instance method is prefixed with a single dash. These methods don't do anything yet, we've just stated that they exist.

This pattern of starting with basic class name, then adding attributes and methods is the basis for all object-oriented programming.

A class is just an abstract description. In most cases, you need to make an instance of the class to do useful things with it. An instance of a class is called an object.

Consider the schematics for an apartment complex. You can't live in the schematics. Somebody has to take the schematics and create an actual building from them. In fact, you can create many instances of the building in different locations using the same set of plans.

Below is an example of how to make two photo objects in Objective-C. Again, keep in mind that this code is simplified to focus on the concepts rather than the rules.

Both photo1 and photo2 are objects. Specifically, they're instances of the Photo class. Any attributes we add to the Photo class will become available to these objects. Let's see how we would go about using the methods we declared in the Photo class:

Since these are two separate photo objects, the actions performed on each are specific to that object. In other words, if we use -desaturate on photo1, the photo2 object is unaffected. In fact, we can delete photo1 without having any impact on photo2 at all.

Now, to be fair, the above code wouldn't work because we haven't defined what each of these methods actually does. That would be fairly complicated at this point, so we're going to move onto other basic concepts.

A header file provides an overview of a class. It lists the variables and methods that the class offers, but doesn't contain the details of how those things work. It's somewhat like a table of contents.

First, we're going to add a variable. In fact, it's a special kind of variable, called an IBOutlet, which is short for Interface Builder Outlet. This variable holds a connection to a user interface item, such as a text field. The connection is wired up visually using Interface Builder.

With that connection in place, you can send instructions to the user interface item. For example, you could enable or disable it, move it, or change its appearance. You can also use IBOutlets for objects which don't appear onscreen.

Double-click on AppController.h to open it in an editor window. Make sure you open AppController.h, not AppController.m. Edit the contents of the file to look like this:

Most of the text was probably filled in by Xcode. In most cases, you should only have to add the IBOutlet line. This line says that AppController will have a connection to something called textView. It's literally an outlet — you plug the text view into it.

The lines that start with a double slash are comments, and have no affect on how the application works. They're just there as notes to yourself and anyone else who may see your code.

Next, we're going to add a method. Remember, a method is a list of instructions which are grouped together. Change the contents of the file to look like this (the comments are not shown):

An IBAction is a special kind of method which, much like an outlet, can be wired up in Interface Builder. This method will be used with a button.

Double click AppController.m, which is the implementation file. The implementation file contains all of the details about how the class behaves. It's the counterpart to the header file.

Change the file to look like the code below, adding the clearText method:

Note that the method does not end with a semicolon. Because this is the implementation of the method, the method name is followed by a pair of brackets. Add the following code between the brackets:

The textView outlet will be connected to an object. Specifically, an NSTextView object. Since it's an object, we can call methods on it, just like we did with photo1 and photo2 earlier.

In this case, we're calling the setString: method, which changes the contents of the text field. The input for this method is @" ", which amounts to a single blank space. In context, it should look like this:

At this point, you might be a bit confused. It's okay, that's normal. We could try to explain how all of this works, but the explanations will make much more sense after you see the final result in action.

So let's wire everything up in the user interface first, then try it out in a working application. You can always come back and look at the details of this code more closely. For now, save AppController.m and close it.