Working with the Code

Mac OS and iOS apps are written using the Objective-C language. Right there, some people might panic and throw up their hands, but do not worry. As pointed out previously, you write very little code from scratch. Much of the code that you run is already written for you using Objective-C; that code is in the Cocoa and Cocoa Touch frameworks that support everything from animation to native platform appearance and the Core Data and various table view classes that are the topic of this book. (Cocoa Touch is the version that runs on iOS; unless otherwise noted, references to Cocoa include Cocoa Touch in this book, just as references to iPhone include iPod touch.)

When you're working inside the Cocoa framework and the other components of iOS and Mac OS, most of your work consists of calling existing methods and occasionally overriding them for your own purposes. Xcode 4 provides a new development environment that is heavily graphical in nature. You will find yourself drawing relationships in your data model and, in the interface, drawing connections between objects on the interface and the code that supports them.

This hour provides an overview of Objective-C. It provides some comparisons to other object-oriented languages such as C++, but its focus is on Objective-C and, particularly, in the ways in which it differs from object-oriented languages you might already know. You can find many introductions to object-oriented programming on the Web and in bookstores, so if you are unfamiliar with that basic concept, you might want to get up to speed on the basics.

Objective-C 2.0

First announced at the 2006 Worldwide Developers Conference and released in Mac OS X v.10.5 (Leopard) in October 2007, Objective-C 2.0 is now the standard implementation. It is fully supported in Xcode 4. The primary changes from the original version of Objective-C include the addition of automatic garbage collection, improvements to runtime performance, and some syntax enhancements. Those syntax enhancements are fully reflected in this book (after all, this book is written more than five years after the announcement of Objective-C 2.0). Some legacy software still uses old syntax, and there is generally no problem with that.

Objective-C 2.0 is often referred to as modern, while the previous version is referred to as legacy. The modern version is not to be confused with Objective-C modern syntax, a project in the late 1990s that changed the presentation of its syntax and which was ultimately discontinued.

As a general rule, legacy Objective-C code runs without changes in the Objective-C environment (there are some exceptions). Much of the sample code for Mac OS X on developer.apple.com is from the legacy period and, with few exceptions, it compiles and runs well. During the transition period, developers often continued to use legacy syntax. This meant that for shared code (and for sample code), developers did not have to worry about whether the code would be compiled or run in the modern or legacy system—it would generally work.

Today, there is no reason to write legacy code because the tools are all updated to Objective-C 2.0. It is safe to write code that will not compile or run in the legacy environment because people are not (or should not be) still using it.

This is particularly relevant to declared properties, which are discussed later in this hour in the "Using Declared Properties" section, p. 68.

What You Do Not Have to Worry About

You do not have to worry about designing an entire program in most cases. You are writing code that will be a part built on a template, the behavior of which is known by users, so what you have to do is to fit in. You need to write the code that is specific to your app, but you do not have to worry about implementing an event loop.

In fact, if you decide to develop the app's infrastructure yourself, you might find that users are disappointed at its unfamiliarity and—more important to many people—your app might not find a place in the App Store.

Instead of writing code from scratch, much of what you will do is to investigate the code that you have in the Xcode templates or in Apple's sample code. You need to explore what is written and how it has been designed so that you can understand how and where your functionality will fit in. It is a very different process than writing it from scratch.

Introducing Objective-C

Objective-C is built on C; in fact, if you write ordinary C code, you can compile it with an Objective-C compiler (that includes Xcode). The main extension to C that Objective-C provides is its implementation of objects and object-oriented programming.

Today, object-oriented programming rates a big yawn from many people; that is the kind of programming that most people are used to. When Simula 67, the first precursor of Objective-C and all modern object-oriented languages, was developed, this was a new notion, and many people were not certain it was worth the extra effort (not to mention the time it took to learn what then was a new and not fully formed technology). It is against this background that the extensions to C needed to implement Objective-C were created. One of the goals was to prove that very little was needed to be added to C to implement object-oriented programming.

Basically, what was added to C was a messaging and object structure based on Smalltalk. Over the years, additional features such as protocols and delegates as well as categories and blocks were added to the language. Some other features were added. Some of them are not as important to developers writing for iOS or Mac OS X, while others of them simply never caught on with developers at large. Thus, this section provides an overview of the major components that are in use today in the context of iOS and Mac OS X.

At the same time as additional features were being added, the use of the language was refined particularly in the environments of NeXT, Apple, Mac OS X, and iOS. These refinements include conventions such as naming conventions and even code formatting conventions. They are not part of the language itself, but they represent best practices that are followed by the vast majority of Objective-C developers.